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