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.]