La historia secreta de la innovación ágil
Se oye hablar mucho de la «innovación ágil» en estos días. Los equipos que utilizan métodos ágiles hacen las cosas más rápido que los equipos que utilizan procesos tradicionales. Mantienen más contentos a los clientes. Disfrutan más de su trabajo. Agile ha transformado indiscutiblemente el desarrollo de software, y muchos expertos creen que ahora está listo para expandirse mucho más allá de IT.
Irónicamente, ahí es donde empezó, fuera de IT.
Algunas trazan metodologías ágiles que se remontan a la articulación del método científico de Francis Bacon en 1620. Un punto de partida más razonable podría ser la década de 1930, cuando el físico y estadístico Walter Shewhart de Bell Labs comenzó a aplicar los ciclos de Plan-Do-Study-Act (PDSA) a la mejora de productos y procesos. Shewhart enseñó esta metodología de desarrollo iterativo e incremental a su aprendiz, W. Edwards Deming, quien la utilizó ampliamente en Japón en los años posteriores a la Segunda Guerra Mundial. Toyota contrató a Deming para formar a cientos de gerentes de la empresa, y finalmente capitalizó su experiencia para desarrollar el famoso Sistema de Producción Toyota, la principal fuente del pensamiento «esbelto» de hoy. Los métodos de desarrollo iterativo e incremental también contribuyeron de manera importante a la creación exitosa del jet hipersónico X-15 en la década de 1950.
En 1986, uno de nosotros (Takeuchi) y el coautor Ikujiro Nonaka publicaron un artículo en Harvard Business Review titulado «El nuevo juego de desarrollo de nuevos productos». Al estudiar fabricantes que lanzaban innovaciones exitosas mucho más rápido que la competencia, los autores identificaron un enfoque orientado al equipo que cambió el proceso de diseño y desarrollo de productos como las fotocopiadoras de Fuji-Xerox, los motores de automóviles de Honda y las cámaras de Canon. En lugar de seguir los métodos convencionales de desarrollo de productos de «carrera de relevos», en los que un grupo de especialistas funcionales traspasa su fase completa a la siguiente etapa funcional, estas compañías estaban utilizando lo que Takeuchi y Nonaka llamaron un enfoque de «rugby», «donde un equipo intenta recorrer toda la distancia como una unidad, pasando el balón hacia adelante y hacia atrás».
En 1993, otro de nosotros (Sutherland) nos enfrentamos a lo que parecía una tarea imposible: Easel Corporation, una empresa de software, necesitaba desarrollar un nuevo producto para reemplazar sus ofertas heredadas en menos de seis meses. Sutherland ya tenía una sólida experiencia en metodologías como el desarrollo rápido de aplicaciones, diseño orientado a objetos, ciclos PDSA y skunkworks. Esperaba crear una cultura de skunkworks en medio de las sedes corporativas, combinando los beneficios tanto de la separación como de la integración organizacional. Así que comenzó aprendiendo todo lo que pudo sobre cómo maximizar la productividad organizacional. Leyendo cientos de artículos y entrevistando a los principales expertos en gestión de productos, se encontró intrigado por varias ideas provocativas.
Uno vino de un artículo de Bell Labs sobre el equipo Borland Quattro Pro, lo que sugiere que las breves reuniones diarias del equipo aumentaron la productividad del grupo de forma espectacular. Pero el concepto culminante de Sutherland fue el descubrimiento del enfoque de rugby de Takeuchi y Nonaka, aunque se centró en la fabricación más que en el software. Tomando prestadas muchas de las ideas clave del artículo de HBR y rellenar prácticas operativas específicas, Sutherland creó una nueva forma de desarrollar software; honrando las imágenes del rugby, bautizó su enfoque como «scrum». Los métodos Scrum le permitieron terminar su proyecto aparentemente imposible a tiempo, por debajo del presupuesto y con menos errores que cualquier versión anterior. Luego colaboró con su antiguo colega Ken Schwaber para codificar el enfoque, y en 1995 la pareja presentó scrum al público por primera vez.
Por supuesto, Sutherland y Schwaber no estaban solos en su búsqueda de métodos innovadores. La era de la información estaba explotando. Las tecnologías disruptivas aterrorizaban a los competidores lentos. Tanto las Startups como las empresas tradicionales buscaron mejores formas de adaptarse al entorno desconocido y turbulento. El software se estaba convirtiendo en una parte integral de casi todas las funciones empresariales, y muchos desarrolladores de software creativos estaban trabajando arduamente en mejores métodos de programación para aumentar la adaptabilidad.
En 2001, 17 desarrolladores que se autodenominaban «anarquistas organizacionales» se reunieron en Snowbird, Utah, para compartir sus ideas. Sutherland y otros defensores del scrum estaban entre ellos. Pero el grupo incluía a defensores de varios enfoques competitivos, como la programación extrema (XP); el cristal; el desarrollo de software adaptativo (ASD); el desarrollo basado en funciones (FDD); y el método de desarrollo dinámico de sistemas (DSDM). Todos estos enfoques se conocían a menudo como marcos «ligeros» porque utilizaban menos reglas y sencillas para permitir una adaptación más rápida a entornos que cambian rápidamente. No muchos de los asistentes encontraron halagadora la terminología «ligera».
Aunque no estuvieron de acuerdo en muchas cosas, el grupo finalmente decidió un nuevo nombre para el movimiento: ágil. La palabra fue sugerida por un asistente que había estado leyendo el libro Competidores ágiles y organizaciones virtuales: estrategias para enriquecer al cliente. El libro ofrece 100 ejemplos de empresas, entre ellas ABB, Federal Express, Boeing, Bose y Harley-Davidson, que estaban creando nuevas formas de adaptarse a mercados más turbulentos. Nombre en mano, los asistentes forjaron un consenso sobre una llamada a las armas denominada «Manifiesto para el desarrollo ágil de software», que enunciaba cuatro valores clave en los que todos estaban de acuerdo. Más adelante en la reunión, y continuando durante los próximos meses, desarrollaron 12 principios operativos, llamados «Principios detrás del manifiesto ágil». A partir de 2001, todos los marcos de desarrollo alineados con estos valores y principios se conocerían como técnicas ágiles.
Una vez que la reunión de Snowbird había canonizado el credo de la innovación ágil, el movimiento ágil se extendió rápidamente. Los firmantes publicaron su documento en línea e invitaron a otros a añadir sus nombres como partidarios. La mayoría de los miembros del grupo original, junto con varios nuevos adherentes, volvieron a reunirse a finales de año para discutir formas de difundir los principios ágiles. Todos acordaron escribir y hablar sobre el tema. Varios asistentes querían formar un grupo de trabajo más permanente; así que crearon una organización sin fines de lucro llamada Alianza ágil para apoyar el movimiento. Hoy en día, la Alianza ágil ha cerca de 30.000 miembros y suscriptores.
Mientras tanto, las metodologías ágiles siguieron evolucionando. A finales de la década de 1980 y principios de los 90, los investigadores del MIT habían comenzado a estudiar los sistemas de fabricación japoneses, especialmente el sistema de producción Toyota. Acuñaron el término «lean» para describir los métodos del sistema para mejorar la productividad mediante la eliminación de los residuos («muda») mediante la reducción de los flujos de trabajo desiguales («mura») y la sobrecarga destructiva («muri»). Aunque las metodologías lean no se presentaron como marcos ágiles en Snowbird, los sistemas formales de desarrollo de software lean y kanban surgieron durante la década de 2000. Al principio, algunos puristas ágiles se negaron a reconocer estos enfoques como metodologías ágiles. Pero los defensores de lean intensificaron su enfoque en la colaboración con los clientes y, finalmente, los profesionales más ágiles llegaron a aceptar lean, kanban y sus híbridos (como scrumban y lean scrum) como aplicaciones legítimas de valores y principios ágiles.
El éxito tiene muchos padres, y la innovación ágil tiene una herencia colorida. Si bien el complejo árbol genealógico de Agile provoca a veces debates apasionados entre los profesionales ágiles, hay dos cosas claras: en primer lugar, las raíces de la metodología ágil se extienden mucho más allá de la tecnología de la información y, en segundo lugar, las ramas de Agile seguirán extendiéndose para mejorar los procesos de innovación en casi todas las funciones de cada industria.
Loading...— Escrito por Darrell Rigby, Hirotaka Takeuchi Darrell Rigby,
