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.

Build the features right vs. build the right features

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