Las metodologías de «desarrollo ágil» hacen muchas cosas mejor, pero también pueden llegar a hacer otras cosas (algunas muy importantes) peor. En este post pasamos revista a las bajas colaterales que puede provocar en entornos de desarrollo de productos una agilización mal entendida.

En la primera parte de este post hablábamos de que las que se suelen vender como metodologías de “desarrollo ágil” tienen grandes ventajas pero no se pueden considerar una solución completa para el desarrollo de nuevos productos para un mercado (algo muy diferente al desarrollo a medida para un cliente específico).

En esta segunda parte abundamos en la opinión -que puede resultar herética para algunos- de que Agile no es la nueva panacea universal y que, si bien hace muchas cosas mejor (fiabilidad, velocidad, calidad…), implementado “según el manual” puede llegar a hacer otras cosas (algunas muy importantes) peor. Aquí tenéis algunas de las bajas colaterales provocadas por una agilización mal entendida:

• Análisis de la oportunidad de mercado y conocimiento profundo de los clientes. El feedback de los clientes durante la implementación es muy valioso, pero no puede sustituir a un conocimiento del mercado y a unos customer insights previos -y continuos- que nos van a permitir detectar y definir oportunidades rompedoras. Por ejemplo, el Product Owner típico de Scrum debe estar continuamente disponible para el equipo de implementación y por ello puede no disponer del suficiente tiempo de contacto con los clientes o de análisis de los competidores como para entender el mercado. Frecuentemente el resultado es un producto que satisface literalmente las solicitudes de mejora expresadas por uno o dos clientes particulares (los últimos que hablaron con el Product Owner), pero lamentablemente el cliente voluntarioso/colaborador no representa al cliente típico.
• Estrategia de producto, visión a largo plazo y roadmap. Un excesivo énfasis en ciclos de desarrollo cortos y en la priorización continua de las features puede hacernos perder de vista dónde querríamos estar a medio y largo plazo -en términos de mercados y oferta- y qué camino debemos seguir para llegar allí. Por no hablar de cierta afición a priorizar features por ROI (desde mi punto de vista, algo en general ilusorio y contraproducente). Agile no debe ser una excusa para carecer de estrategia de producto y para cambiar constantemente de visión y vagar sin rumbo fijo.
• Feedback temprano y frecuente. Agile promueve el feedback de los clientes durante todas las iteraciones de la implementación. Sin embargo, confiar la validación inicial de la solución a esas primeras iteraciones es un error ya que para entonces puede ser demasiado tarde. Este feedback se debería haber recogido durante las fases previas a la implementación -definición y diseño-  y no mediante un producto real (aunque incompleto) sino utilizando prototipos rápidos y desechables. Los prototipos pre-implementación son los únicos que nos permiten recoger la opinión de los clientes con la rapidez, velocidad de iteración, fidelidad y bajo coste necesarios para asegurarnos de que no empezamos a construir algo que el mercado no quiere.
• Diseño de la solución (especialmente en lo relacionado con la experiencia de usuario). Una experiencia integrada y consistente no “emerge a trozos” de una construcción incremental sino que debe ser fruto de una concepción holística y -al menos en sus grandes líneas- de un diseño deliberado previo. Este diseño integral (siempre iterativo) es el que realmente permite descubrir modelos innovadores de interacción con el usuario, que elevan el nivel de la experiencia de uso. Por su parte, el refinamiento iterativo durante la implementación puede optimizar interfaces e interacciones, pero se trata a menudo de una mejora incremental. Las metodologías ágiles se están extendiendo para conjugar un diseño holístico con una implementación incremental, hasta el punto de que el “Agile UX” es uno de los temas de actividad en la comunidad (al que dedicaremos un próximo post).
• Arquitectura. Un excesivo foco en las features puede llevar a postergar a un segundo plano la especificación técnica. Y, sin embargo, la arquitectura es primordial para garantizar que durante la construcción vamos a poder iterarlo y “pivotarlo” fácilmente y que el producto final va a ser replicable, fiable, escalable, evolucionable y adaptable a varios segmentos de clientes (a través de “productos derivados”). La arquitectura es otro de los aspectos del producto que requieren un enfoque holístico y en implementaciones desafortunadas de Agile puede acarrear una gran «deuda técnica».
• Puestos con funciones claras y no redundantes. Las metodologías Agile van evolucionando y extendiéndose más allá de la implementación, entrando en los terrenos de la estrategia, la visión y la definición del producto. Sin embargo, en las empresas ya existen puestos que tienen la responsabilidad sobre esos temas (llámense estos Chief Product Officer, Product Manager, Business Analyst o Technical Product Manager) lo que puede crear conflicto con alguno de los puestos o roles propios de Agile, especialmente el del Product Owner. Incluso ha habido intentos de describir un “Agile Product Manager” como una especie de Súper-Product Owner aunque en mi opinión las responsabilidades y actividades que le asignan son incompletas y las técnicas que les recomiendan son demasiado rudimentarias. También hablaremos de ello en otro post.

Con todo esto no quiero decir que cualquier implementación del desarrollo ágil vaya necesariamente a acarrear estos problemas, sino identificar áreas de posible disfuncionalidad donde hay que poner un especial cuidado.

La decisión de aplicar o no Agile no puede tomarse por modas, sino que depende del tipo de producto, mercado, tecnología y organización. Si los riesgos de cliente/mercado/tecnológicos son bajos, los costes de iteración son altos, y  el equipo de implantación muestra buen rendimiento, coordinación y comunicación puede no ser necesario migrar a Agile ya que los costes incrementales del cambio pueden ser superiores a los beneficios. La realidad en las empresas más avanzadas es que controlan un repertorio de metodologías de implantación, desde el ágil más radical a la cascada más ortodoxa, pasando por enfoques mixtos “Agile Waterfall”, y aplican una u otra según lo que más convenga en cada escenario.

Este post en ”Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

Las metodologías ágiles se vienen presentando como la solución a los problemas del desarrollo de productos. Pero aunque sin duda pueden aportar mejoras en las actividades de construcción y conseguir que las características del producto se implementen adecuadamente, por sí solas no son suficiente para asegurar que esas características son las adecuadas para conquistar el mercado.

La filosofía y las metodologías ágiles se están proponiendo como solución a los retos del desarrollo de productos en escenarios de alta incertidumbre y velocidad. Por ejemplo, Steve Blank y Eric Ries incorporan el Agile Development como una de los pilares de su Startup Stack, junto a Customer Development y Business Model Canvas. En este blog hemos hablado de desarrollo ágil en varias ocasiones y tal vez vale la pena recordar algunas ideas:

• Las filosofías de desarrollo flexible de nuevos productos llevan aplicándose desde los pasados años ochenta en diversos sectores, entre ellos el software y otros. Se trata de enfoques basados en la iteración, el feedback de los clientes y la experimentación en el mercado, que se aplican en las diversas actividades del desarrollo de productos (desde la identificación de necesidades de mercado hasta el lanzamiento del producto) y que son ejecutados por equipos interdepartamentales y autoorganizados . Específicamente en el campo del software, las mejores empresas de producto llevaban aplicando metodologías ligeras e iterativas de desarrollo desde mucho antes que el término Agile llegara a popularizarse como “marca paraguas” (inicialmente en el campo de los proyectos a medida).
• Lo que desde los primeros años de este siglo se está comercializando como “desarrollo ágil” consiste básicamente en un conjunto de metodologías iterativas e incrementales (Scrum, XP…) que nacieron para la gestión y desarrollo de proyectos a medida de un cliente, fundamentalmente en el campo del software, y enfocadas en aumentar el throughput y la calidad de lo que se entrega.

Pero las diferencias entre ambos escenarios son enormes: desarrollar un producto que satisfaga a un mercado va mucho más allá del desarrollo de un proyecto a la medida de un cliente específico. La gestión y desarrollo de productos consiste fundamentalmente en entregar productos repetibles a un mercado de clientes y ello requiere inicialmente de una identificación de las necesidades de dicho mercado, una validación de la oportunidad que representa y una comprensión profunda de los requisitos esenciales de los clientes. Las metodologías de “desarrollo ágil” cubren las actividades de implementación o construcción de la “unidad 0” de un nuevo producto y por tanto entran en acción cuando ya se ha decidió que se va a construir algo, pero no fueron pensadas para evaluar una oportunidad de mercado o para definir el tipo de solución a proporcionar. No podemos confundir una parte (la construcción del producto) con todo el proceso de desarrollo y mucho menos con la gestión estratégica de productos.

Personalmente soy un convencido de los beneficios de las filosofías flexibles/ágiles de desarrollo de nuevos productos, especialmente en escenarios de alta incertidumbre. Y sin duda la flexibilidad y la iteración centrada en el usuario que aportan las metodologías Agile benefician enormemente al proceso de desarrollo. Pero una aplicación “de manual” de algunas metodologías a escenarios para los que no fueron creadas puede traer efectos secundarios indeseables.

Por su enfoque principalmente táctico y orientado al proyecto, Agile puede aportar grandes mejoras en el propio proyecto (o proyectos) de construcción de un nuevo producto: programación predecible de releases, menos features incompletas, mayor usabilidad… pero puede relegar la visión más estratégica del producto a un segundo plano. Agile puede acelerar el desarrollo y mejorar la calidad de las features individuales, pero lo hace a menudo a expensas de otros trabajos más importantes y costosos que aportan un valor para el cliente y una diferenciación competitiva reales, p.ej., una comprensión profunda y una priorización de los problemas a resolver o un diseño holístico (al menos en sus líneas generales) de la funcionalidad y la experiencia de usuario.

Desde luego que una  implementación ágil puede mejorar muchos aspectos del producto, pero esas mejoras son a menudo incrementales. Esencialmente, Agile asegura que se va a poder “entregar algo aceptable rápidamente”, pero ¿ese “algo” nos va a servir para vender más en un mercado? Mi opinión es que las metodologías ágiles por sí solas son insuficientes para asegurar que se construyen las features adecuadas para satisfacer a unos clientes heterogéneos y desconocidos.

Cuando Agile se implanta “a ciegas” su cadencia y sus prácticas llegan a apropiarse del proceso de desarrollo de producto y la vorágine de la implementación absorbe a toda la organización. Resulta difícil pensar estratégicamente cuando se está sometido a las demandas constantes del corto plazo. La urgencia por “alimentar a la bestia” de los procesos de Agile nos puede impedir prestar atención a algunas otras cosas realmente importantes. Para evitarlo, estas metodologías han tenido que ir adaptándose y extendiéndose de modo que fueran más adecuadas a un escenario de desarrollo de productos y no de proyectos a medida.

En la segunda parte de este post pasaremos revista a algunas “bajas colaterales” de un agilismo mal entendido. Mientras tanto ¿cuál ha sido vuestra experiencia en el desarrollo de productos aplicando metodologías ágiles?

Este post en ”Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

¿Es Agile válido para algo más que el desarrollo de software a medida? ¿Sirve para desarrollar productos no software?

En la segunda parte de este post hablamos de cómo las metodologías Iterativas y ligeras se vienen aplicando con éxito en la construcción de productos software… incluso desde mucho antes de la actual “fiebre Ágil”. ¿Quiere esto decir entonces que cualquier empresa de producto software se beneficiaría de Agile? ¿Nos deberíamos administrar todos la típica “receta Scrum+XP” (o la que esté de moda)?

Pues no necesariamente. Como ya sabemos, la flexibilidad de Agile no es gratis. Algunos factores a tener en cuenta:

• Si los clientes, requisitos y tecnologías son conocidos y estables, las metodologías lineales siguen siendo una opción.
• Si el equipo humano ya dispone de unos buenos mecanismos de gestión, coordinación y comunicación, el introducir algunas prácticas “extremas” de Agile puede resultar disruptivo y contraproducente.
• Con su énfasis en codificar y en desarrollar features, algunas metodologías de Agile minimizan (o eliminan) aspectos cruciales como el análisis significativo del mercado, la visión del producto o el diseño de una experiencia integral de usuario, lo que puede llevar a innovaciones incrementales y a productos poco atractivos.

De todos modos, el papel de de Agile en el desarrollo de productos software sigue siendo objeto de debate: en un próximo post discutiremos algunas de sus limitaciones. Y esto nos lleva a la última cuestión que vamos a considerar en esta serie de posts.

¿Se puede aplicar Agile a productos no software?

La respuesta es “sí y no”. Trasplantar a otros sectores los aspectos más ligados al software (p.ej., el pair programming de XP) probablemente no tiene sentido ni es posible. Pero es evidente que muchas industrias se beneficiarían de la filosofía y los principios de Agile en cuanto que pueden aportar  flexibilidad ante un entorno cambiante, mayor velocidad y calidad en el desarrollo y equipos humanos coordinados e involucrados.

En realidad, algunos elementos de la filosofía Agile están tomados de los enfoques de fabricación y calidad de productos de Edward Demming y del Lean Manufacturing System de Toyota. Particularmente Scrum, la metodología de gestión de proyectos más ligada a Agile, se inspiró en algunas ideas sobre el desarrollo de productos (por cierto, no software) de los años ochenta.  En efecto, en su famoso artículo de 1986 “The New New Product Development Game”, H. Takeuchi e I. Nonaka argumentan que el enfoque secuencial tradicional del desarrollo de productos, que denominan “carrera de relevos”, colisiona con los actuales imperativos de velocidad y flexibilidad.

En su lugar proponen un enfoque holístico, que asimilan al deporte del rugby, donde los miembros del equipo interactúan constantemente y recorren juntos el proceso de principio a fin “desplazando la melé” (por cierto, melé en inglés se dice scrum ;- ). Los autores analizar los proceso de desarrollo de diversos productos de éxito en los sectores de las fotocopiadoras, los automóviles, los ordenadores y las cámaras fotográficas y descubren que esos procesos se caracterizan por el solapamiento entre las fases del desarrollo, la autoorganización, comunicación y multidisciplinariedad del equipo y un enfoque iterativo y dinámico de prueba y error. Algunos pioneros de Scrum, como J. Sutherland y K. Schwaber, han reconocido en numerosas ocasiones la influencia de estas ideas en su pensamiento.

Resumiendo, y teniendo en cuenta que muchos de los enfoques y prácticas de Agile provienen del mundo de los productos no software, la pregunta de si Agile puede aplicarse en ese campo no deja de ser algo retórica. Un punto crucial radica en el papel de la iteración en el proceso: en la primera parte de este post argumentamos que en el caso de desarrollos a medida en sectores intensivos en materiales (como por ejemplo la construcción de edificios, naves, etc.), los elevados costes de los cambios durante el desarrollo pueden limitar las posibilidades de iterar, ya que al tratarse de un proyecto singular se le deberían repercutir todos los costes de las iteraciones y el presupuesto podría incrementarse exageradamente.

Sin embargo, cuando se trata de desarrollar un producto (es decir, construir su “unidad 0”, que luego habrá que replicar en el proceso de fabricación) los costes de las iteraciones durante el desarrollo son menos relevantes ya que pueden ser repercutidos sobre un número mayor de unidades. El prototipado, la búsqueda del feedback de los clientes y la iteración se ha convertido en una constante en el desarrollo de productos materiales debido a la influencia del “pensamiento de diseño” y a la disponibilidad de tecnologías como la simulación, la realidad virtual o la impresión 3D que permiten generar, explorar y validar múltiples alternativas incluso en las fases de conceptualización y diseño, sin necesidad de esperar a la construcción propiamente dicha.

En un próximo post hablaremos de las limitaciones y problemas de Agile en el desarrollo de productos.

Este post en «Marketing & Innovación».

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

¿Es Agile válido para algo más que el desarrollo de software a medida? ¿Sirve para desarrollar productos?

En la primera parte de este post nos planteábamos si Agile sirve para proyectos singulares/desarrollos a medida más allá del software. Ahora nos preguntamos si se puede aplicar en el desarrollo de productos, tanto software como no.

Y antes que nada conviene aclarar una cuestión terminológica. Cuando la gente de Desarrollo/Tecnología Software habla de un “desarrollo a medida” o un “desarrollo de producto” se suele referir a lo que constituye el núcleo de su labor: a lo que -dependiendo de la metodología- cubre desde la captura de requisitos hasta la prueba final (pasando, obviamente, por el diseño técnico y la programación) del proyecto. En definitiva, estamos hablando de la “construcción” del sistema a medida o de la “unidad 0” de un producto.

Por el contrario, cuando la gente de Negocio habla del Desarrollo de un Nuevo Producto (NPD, New Product Development) se está refiriendo a un proceso más amplio, que incluye a la propia “construcción”, pero que también abarca desde la generación de ideas y detección de oportunidades hasta la prueba de mercado y el lanzamiento. Dependiendo de las características en cuanto a incertidumbre, velocidad y grado de innovación del producto/mercado serán aconsejables para el NPD unos enfoques y metodologías u otros, por ejemplo:

• En casos de necesidades conocidas, mercados estables e innovaciones incrementales puede ser más eficiente utilizar un proceso lineal y faseado como por ejemplo el Stage-Gate clásico (siguiente figura)

• Con necesidades emergentes, requisitos de cliente inestables, mercados nuevos o en evolución e innovaciones radicales resulta más eficaz aplicar un proceso iterativo (en el que las fases están interrelacionadas y se solapan) que facilite la involucración temprana y constante de los clientes. Estos procesos -cuyo objetivo primordial es descubrir espacios de mercado y validar nuevos modelos de negocio– están menos asentados y formalizados que los lineales.  Y probablemente el que más atención está recibiendo últimamente es la combinación de Customer Development y -precisamente- Agile Development propuesta por Steve Blank y Eric Ries.

Por lo tanto, desde ese punto de vista la pregunta correcta no es si Agile constituye una solución o respuesta completa al Desarrollo de Nuevos Productos, sino si Agile es una herramienta útil para dicho proceso. En realidad, si bien las metodologías de Agile originalmente no cubren todas las actividades de estos procesos en los últimos tiempos se han ido extendiendo, llegando a abarcar algunas de las funciones de la Gestión de Productos más estratégica. Incluso se ha llegado a asimilar el papel del Product Owner de Scrum con el del Product Manager: hablaremos de ello en otro post.

¿Se puede aplicar Agile a productos software?

Este es un asunto bastante actual y polémico porque en los últimos años se ha vendido la filosofía Ágil (especialmente Scrum y XP) como la panacea para el desarrollo de productos software, eliminando la rigidez y la burocracia del modelo en Cascada. Pero vamos a revelar un pequeño secreto: las empresas de productos software de éxito llevaban aplicando metodologías de desarrollo incrementales/iterativas/en espiral/de prototipado rápido etc. desde antes de que se acuñara el término Agile y de que su uso se popularizara en los proyectos de software a medida.

Las metodologías más pesadas y rígidas fueron relegadas muy pronto del desarrollo de productos software para mercados innovadores y competitivos. ¿Por qué? Pues porque ese sector es el paradigma de clientes desconocidos, requisitos complejos y cambiantes, volatilidad competitiva y tecnológica… y todo ello con la imperiosa obligación de ganar dinero.  Y en esa situación las metodologías ligeras pueden ayudar. Personalmente doy fe de que a principios de los años 2000 eso era así incluso en el sector de las aplicaciones corporativas (ERP, CRM, SCM…) ya que en aquella época trabajé en un par de multinacionales estadounidenses en ese campo. Y si quieres competir contra SAP -a eso es a lo que nos dedicábamos- más te vale introducir una absoluta flexibilidad en todo lo relacionado con el desarrollo de producto (empezando por su propia arquitectura).

Es evidente que desde principios de los pasados años noventa las empresas de producto software vienen aplicando filosofías de desarrollo iterativo y flexible. Por ejemplo, en su libro de 1995 “Microsoft Secrets”, M. Cusumano y R. Selby describen el proceso “Sync-and-Stabilize” usado en Microsoft. Posteriormente, un estudio realizado en 2000-2001 por M. Iansiti, R. Verganti y A. MacCormack sobre el volátil sector del software para Internet consiguió identificar las características que poseían los procesos de desarrollo aplicados en los productos con más éxito en el mercado. En “Product-Development Practices That Work: How Internet Companies Build Software” A. MacCormack analiza dichas prácticas de éxito, que se basan en un enfoque evolutivo del desarrollo:

• Poner lo antes posible en manos de los clientes una versión preliminar del diseño, e ir evolucionando
• Incorporar diariamente nuevo código software y conseguir un feedback  rápido sobre los cambios en el diseño
• El equipo humano debe poseer una amplia experiencia en la realización de proyectos diversos
• Invertir en el diseño de la arquitectura del producto

En definitiva, las metodologías Iterativas y ligeras se vienen aplicando con éxito en la construcción de productos software desde antes de la “fiebre Ágil”. ¿Quiere esto decir entonces que cualquier empresa de producto software se beneficiaría de Agile? ¿Nos deberíamos administrar todos la típica “receta Scrum+XP”? Trataremos de responder en la tercera parte de este post.

Este post en Marketing & Innovación.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

El Desarrollo Ágil se ha venido postulando como la solución a todos los problemas del desarrollo de productos. Pero ¿es Agile válido para algo más que el desarrollo de software a medida?

En el transcurso de los últimos diez años, Agile se ha convertido en un enfoque practicado por muchos departamentos de TI y Desarrollo: en la encuesta Global Developer Technographics publicada por Forrester y Dr. Dobbs, casi el 39% de los profesionales de TI consultados afirmaba seguir un método Agile (con Scrum, Agile modeling y Test-driven development a la cabeza). Y con esta explosión del Desarrollo Ágil uno de los temas de debate es si sus principios y metodologías son válidos en entornos diferentes al del software a medida, que es donde nació. ¿Funciona en desarrollos a medida no software? ¿En desarrollo de productos software? ¿Y en productos no software?

Dejemos a un lado la obviedad de que el Agile Manifesto se refiere exclusivamente al software y analicemos si su filosofía y principios y las diversas metodologías asociadas con Agile (Scrum, XP…) se pueden aplicar en otros entornos.  Y vamos a empezar sintetizando las diferencias entre estos diversos escenarios:

Por resumir, las diferencias entre un desarrollo a medida y uno de producto es que el primero es un desarrollo más o menos singular, definido para resolver el problema de un cliente dado. Por el contrario el desarrollo de producto va dirigido a resolver las necesidades –a veces latentes– de un mercado de clientes en general desconocidos (individual y, muchas veces, colectivamente). Además, lo que se conoce como Desarrollo de Nuevos Productos (NPD, New Product Development) abarca varias fases previas a (o concurrentes con) su “construcción”, que incluyen el descubrimiento de la oportunidad, la comprensión del mercado, la identificación de necesidades, la validación del modelo de negocio o la elaboración del caso de negocio. Finalmente, la vida de un producto abarca esas fases previas y otras posteriores como su lanzamiento, comercialización, evolución o retirada del mercado (generalmente a través de una sustitución ordenada mediante nuevos productos de la empresa)… lo que tradicionalmente constituye el área de Product Management y Product Marketing.

En cuanto a las diferencias software – no software, la más evidente es la posibilidad de replicar (“fabricar” y “entregar”) unidades adicionales de un producto software a coste prácticamente cero. Pero desde el punto de vista de desarrollo de un proyecto singular o de la primera unidad de un producto, una diferencia vital es que los costes de realizar cambios a mitad del proceso son mucho más bajos en el software que en otro tipo de industrias más intensivas en materiales y equipamiento. Esto hace viables los enfoques iterativos de desarrollo.

Finalmente, entre un desarrollo a medida de software y un producto software aplican las diferencias generales entre desarrollos a medida y producto, pero además en un desarrollo a meda lo importante es la cobertura funcional mientras que en un producto (especialmente en B2C) adicionalmente resultan clave aspectos como la experiencia de usuario y otras medidas de calidad.

¿Se puede aplicar Agile a desarrollos a medida más allá del software?

Por desarrollo a medida entendemos un proyecto nuevo y diferente que se ejecuta para cubrir una necesidad identificada de un cliente dado -no la replicación de un desarrollo previo- por ejemplo, la construcción/ elaboración de un edificio, un barco, un informe de consultoría… o un coche de Formula 1.

Por supuesto que algunos principios de Agile y aspectos de sus diferentes metodologías pueden beneficiar a proyectos de muy diversa naturaleza. De hecho, marcos de gestión de proyectos como Scrum no nacieron ligados inicialmente al software. Por otra parte es obvio que metodologías específicamente de programación como XP (con su pair programming y otras prácticas) no van a encontrar un acomodo fácil en otros ámbitos.

Los principios básicos de Agile (iteración, desarrollo incremental, feedback continuo de cliente…) proporcionan los mejores resultados en escenarios donde existe gran incertidumbre e incógnitas que deben ir despejándose durante el proyecto, en los que es imposible recabar todos los requisitos del cliente al principio o estos no son estables y donde el coste de realizar cambios durante el desarrollo no es prohibitivo. Pero ya sabemos que la flexibilidad que aporta Agile no es gratis: si no se dan las anteriores circunstancias es menor aplicar una gestión “predictiva” (no evolutiva) basada en definir-planear-ejecutar.

Por ejemplo, con el estado actual de la tecnología no podemos de manera eficiente “iterar” durante la construcción de un edificio, so pena de que un presupuesto de 27 millones se convierta en 110 (aunque si el cliente es la administración pública y quien paga es el contribuyente todo es mucho más “flexible”, como bien sabemos en nuestro país). Por contra, sí que es más sencillo iterar y aprovechar la flexibilidad de Agile en proyectos más inmateriales, como los relacionados con contenidos digitales. No obstante las tecnologías de simulación, prototipado rápido, realidad virtual, etc. pueden facilitar el feedback y la iteración desde la fase de diseño en muchos tipos de desarrollos a medida, sin necesidad de esperar a la construcción.

En la segunda y tercera partes de este post analizaremos si Agile es útil para el desarrollo de productos, tanto software como no software.

Este post en «Marketing & Innovación».

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

En la primera parte de este post anterior hablamos de cómo las características particulares de la tecnología software y el tipo de problemas que resuelve fueron abonando el terreno para la aparición de metodologías de desarrollo ligeras e iterativas, en un intento de mejorar las metodologías pesadas y por fases -influidas por las técnicas del desarrollo de proyectos en otros campos- que habían predominado hasta entonces.

En febrero de 2001 diecisiete expertos en desarrollo de software publicaron el “Manifesto for Agile Software Development”, que dio un nombre, una carta de naturaleza y una “marca” a todos esos métodos. Básicamente el Manifiesto consta de cuatro puntos en los que se da prioridad a los individuos y las interacciones, al software que funciona, a la colaboración con el cliente y a la respuesta ante el cambio frente a aspectos como los procesos, la documentación y los planes, que son prioritarios en otros enfoques. Como complemento incluye los doce principios básicos de Agile, entre los que se cuentan la satisfacción del cliente, la entrega temprana y continua de software que funciona, la cooperación y la autoorganización.

Es importante señalar que cuando se habla de Agile se suele hablar en realidad de alguna de las metodologías precursoras que mencionábamos en nuestro post anterior, y en particular de dos que son las más aceptadas (y que son anteriores al Manifiesto):

• Scrum (1995), un marco iterativo e incremental para la gestión de proyectos, inicialmente propuesto para proyectos de desarrollo de productos y cuyo uso se ha centrado en proyectos de desarrollo de software.
• XP (Extreme Programming, 1996) una metodología iterativa de desarrollo de software que aboga por entregas frecuentes de software en ciclos de desarrollo cortos y que recibe ese nombre por su énfasis en llevar al extremo esas buenas prácticas.

En realidad muchos de los principios de Agile (como por ejemplo incrementar la flexibilidad o la comunicación) son ideas de sentido común pensadas para enmendar el mal funcionamiento de las metodologías tradicionales en ciertos escenarios y para arreglar equipos de proyecto disfuncionales. Pero adicionalmente las metodologías Agile incorporan una serie de prácticas, roles y “valores” (daily scrums, war rooms, programación en parejas, retrospectivas, Scrum Masters, Product Owners…) y un énfasis en el funcionamiento del equipo de desarrollo que crean una “liturgia” y contribuyen a fomentar la identificación y la involucración, a veces casi religiosa, de sus practicantes. Lamentablemente, algunas organizaciones encuentran difícil implantar Agile en toda su extensión -con el cambio de cultura que requiere- y se quedan en sus prácticas superficiales, lo que no deja de ser un caso más de “cerdo con lápiz de labios”.

Los beneficios en cuanto a flexibilidad, adaptación, comunicación y coordinación que Agile aporta en escenarios inciertos y volátiles son evidentes. Sin embargo, en estos años se han alzado voces críticas con esta filosofía debido a posibles limitaciones como las siguientes:

• Está muy enfocada en la captura de requisitos y el desarrollo, pero pone un foco escaso en el diseño y en la experiencia global del usuario de la solución
• Falta de estructura y documentación
• Puede aumentar el riesgo de una expansión incontrolada del alcance del proyecto
• Solo funciona bien con desarrolladores experimentados
• Requiere reuniones muy frecuentes con los clientes, con el consiguiente coste
• Dificultad para escalar a proyectos grandes y con personal distribuido geográficamente

Por eso algunos dicen que, si bien Agile tiene cosas buenas y originales, “las cosas buenas no son tan originales y las cosas originales no son tan buenas”… Ese es también el motivo por el que las prácticas de Agile llevan años evolucionando para solucionar sus carencias y ser aplicables en escenarios más generales. En cualquier caso, es evidente que la flexibilidad que aporta Agile no es gratis y a veces sus costes pueden superar a sus beneficios.

Hasta aquí esta introducción a Agile. En próximos posts iremos abriendo el debate sobre preguntas como las siguientes:

• ¿Se puede aplicar Agile más allá del desarrollo de software a medida: proyectos no software, productos software, productos no software?
• ¿Qué beneficios y limitaciones tiene Agile en el desarrollo de productos?
• ¿Cuáles son las relaciones entre Product Manager y Product Owner?
• ¿Cómo implantar un Agile Product Management?

Este post en Marketing & Innovación.