¿Es Agile perjudicial para el desarrollo de nuevos productos? (2)

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

Categorías: desarrollo ágil, desarrollo de producto