La historia secreta de la innovación ágil

Hoy en día escucha mucho sobre la «innovación ágil». Los equipos que utilizan métodos ágiles hacen las cosas más rápido que los equipos que utilizan los procesos tradicionales. Hacen que los clientes estén más contentos. Disfrutan más de su trabajo. La agilidad ha transformado indiscutiblemente el desarrollo de software y muchos expertos creen que ahora está a punto de expandirse mucho más allá de la TI.

Irónicamente, ahí es donde empezó, fuera de la TI.

Algunos rastrean las metodologías ágiles hasta 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 los Laboratorios Bell comenzó a aplicar los ciclos de planificación-hacer-estudiar-actuar (PDSA) a la mejora de los productos y los 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 directivos de la empresa y, finalmente, aprovechó su experiencia para desarrollar el famoso sistema de producción de Toyota, la principal fuente de la forma de pensar «ajustada» actual. Los métodos de desarrollo iterativos e incrementales también contribuyeron en gran medida a la exitosa creación del jet hipersónico X-15 en la década de 1950.

En 1986, uno de nosotros (Takeuchi) y el coautor Ikujiro Nonaka publicamos un artículo en Harvard Business Review titulado «El nuevo juego del desarrollo de nuevos productos». Al estudiar a los 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 «carreras de relevos», en los que un grupo de especialistas funcionales pasa su fase completa a la siguiente fase funcional, estas empresas utilizaban lo que Takeuchi y Nonaka denominaron un enfoque de «rugby», «en el que un equipo trata de recorrer toda la distancia como una unidad, pasando la pelota de un lado a otro».

En 1993, otro de nosotros (Sutherland) se enfrentó a lo que parecía una tarea imposible: Easel Corporation, una empresa de software, necesitaba desarrollar un nuevo producto para reemplazar su oferta anterior en menos de seis meses. Sutherland ya tenía una sólida formación en metodologías como el desarrollo rápido de aplicaciones, el diseño orientado a objetos, los ciclos de PDSA y Skunkworks. Esperaba crear una cultura similar a la de Skunkworks en medio de la sede corporativa, que combinara los beneficios de la separación y la integración organizacionales. Así que empezó por aprender todo lo que pudo sobre cómo maximizar la productividad organizacional. Al leer cientos de artículos y entrevistar a importantes expertos en gestión de productos, se sintió intrigado por varias ideas provocadoras.

Uno venía de un artículo de Bell Labs sobre el equipo Borland Quattro Pro, lo que sugiere que las breves reuniones diarias de equipo aumentaron drásticamente la productividad del grupo. Pero el concepto final de Sutherland fue el descubrimiento del enfoque de rugby de Takeuchi y Nonaka, a pesar de que se centraba en la fabricación más que en el software. Basándose en muchas de las ideas clave del artículo de HBR y rellenando prácticas operativas específicas, Sutherland creó una nueva forma de desarrollar software; haciendo honor a la imagen del rugby, llamó a su enfoque «scrum». Los métodos de scrum le permitieron terminar su proyecto aparentemente imposible a tiempo, por debajo del presupuesto y con menos errores que cualquier otra versión anterior. Luego colaboró con su antiguo colega Ken Schwaber para codificar el enfoque y, en 1995, ambos presentaron el 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 empresas emergentes como las tradicionales buscaron mejores formas de adaptarse a un entorno turbulento y desconocido. 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 hacían llamar «anarquistas organizacionales» se reunieron en Snowbird, Utah, para compartir sus ideas. Sutherland y otros defensores del scrum estuvieron entre ellos. Pero el grupo incluía a defensores de varios enfoques competitivos, como la programación extrema (XP), Crystal, el desarrollo de software adaptativo (ASD), el desarrollo basado en funciones (FDD) y el método de desarrollo de sistemas dinámicos (DSDM). Todos estos enfoques se conocían a menudo como marcos «ligeros» porque utilizaban menos reglas y más simples para permitir una adaptación más rápida a los entornos que cambiaban rápidamente. No muchos de los asistentes encontraron halagadora la terminología «ligera».

Aunque no estaban de acuerdo en muchas cosas, el grupo finalmente se decidió por un nuevo nombre para el movimiento: ágil. La palabra la sugirió un asistente que había estado leyendo el libro Competidores ágiles y organizaciones virtuales: estrategias para enriquecer al cliente. El libro daba 100 ejemplos de empresas —incluidas ABB, Federal Express, Boeing, Bose y Harley-Davidson— que estaban creando nuevas formas de adaptarse a los mercados más turbulentos. Nombre en mano, los asistentes forjaron entonces un consenso sobre un llamado a las armas llamado «Manifiesto por un desarrollo ágil del software», que detallaba cuatro valores clave en los que todos estaban de acuerdo. Más adelante en la reunión, y continuando durante los siguientes meses, desarrollaron 12 principios operativos, llamados «Los principios detrás del Manifiesto Ágil». A partir de 2001, todos los marcos de desarrollo que se ajusten a estos valores y principios se conocerán como técnicas ágiles.

Una vez que la reunión de Snowbird canonizó el credo de la innovación ágil, el movimiento ágil se extendió rápidamente. Los firmantes publicaron su documento en Internet e invitaron a otros a añadir sus nombres como seguidores. La mayoría de los miembros del grupo original, a los que se unieron varios nuevos seguidores, volvieron a reunirse más adelante ese mismo año para hablar sobre las formas de difundir los principios de la agilidad. Todos estuvieron de acuerdo en escribir y hablar sobre el tema. Varios asistentes querían formar un grupo de trabajo más permanente, por lo que crearon una organización sin fines de lucro llamada Alianza ágil para apoyar el movimiento. En la actualidad, la Alianza Ágil tiene casi 30 000 miembros y suscriptores.

Mientras tanto, las metodologías ágiles seguían evolucionando. A finales de la década de 1980 y principios de la de 1990, los investigadores del MIT empezaron a estudiar los sistemas de fabricación japoneses, especialmente el sistema de producción de Toyota. Acuñaron el término «delgado» para describir los métodos del sistema para mejorar la productividad mediante la eliminación del despilfarro («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 en la década de 2000. Al principio, algunos puristas de la agilidad se negaron a reconocer estos enfoques como metodologías ágiles. Pero los defensores de la metodología lean intensificaron su enfoque en la colaboración con los clientes y, finalmente, los profesionales más ágiles llegaron a aceptar el lean, el kanban y sus híbridos (como el scrumban y el lean scrum) como aplicaciones legítimas de los valores y principios de la agilidad.

El éxito tiene muchos padres y la innovación ágil tiene una herencia colorida. Si bien el complejo árbol genealógico de la metodología ágil a veces provoca debates apasionados entre los profesionales de la metodología ágil, dos cosas están claras: primero, las raíces de la metodología ágil van mucho más allá de la tecnología de la información y, segundo, las sucursales de la metodología ágil seguirán extendiéndose para mejorar los procesos de innovación en casi todas las funciones de todos los sectores.

Play

Play

00:00

Play

Seek 10 seconds backwards

Seek 10 seconds forward

00:00 / 00:00

Mute

Settings

Picture in picture

Fullscreen

.video-summary-list-container { height: 100%; } .video-summary-list-container .MuiScopedCssBaseline-root { height: 100%; }

Summary & chapters

Read as overview

.chapters-list-module_intro__74vPf { padding: 16px; border-bottom: 1px solid rgba(255, 255, 255, 0.2); } .chapters-list-module_chapter__uKhQh { padding: 0 16px 16px 8px; border-bottom: 1px solid rgba(255, 255, 255, 0.2); .MuiPaper-root .MuiButtonBase-root .MuiAccordionSummary-content { margin-top: 16px; margin-bottom: 0; } .MuiPaper-root .MuiCollapse-root .MuiCollapse-wrapper .MuiAccordionDetails-root { padding-bottom: 0; } } .chapters-list-module_chapter-header__Pu4Xi { width: 100%; margin-right: 8px; } .chapters-list-module_chapter-header-content__JIOjX { flex-grow: 1; padding: 8px; border-radius: 8px; cursor: pointer; } .chapters-list-module_chapter-header-content__JIOjX:hover { background-color: rgba(0, 0, 0, .2); } .chapters-list-module_chapter-header-expand-icon__tLLZ9 { margin-top: 16px; } .chapters-list-module_chapter-header-text__bPoKD { font-size: 11px; font-weight: 400; letter-spacing: 1px; text-transform: uppercase; } .chapters-list-module_chapter-bullet-icon__kCL9n { font-size: 11px; font-weight: 400; letter-spacing: 1px; text-transform: uppercase; } .chapters-list-module_chapter-intro__H-iVR { display: flex; align-items: center; gap: 8px; margin-bottom: 2px; } .chapters-list-module_chapter-description__ziIpd { margin: 0 -16px 0 -8px; } .chapters-list-module_intro-text__Sqgju { } .chapters-list-module_chapter-description__ziIpd, .chapters-list-module_intro-text__Sqgju { font-size: 16px !important; white-space: pre-wrap; }