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