20 años de Agile: la rebelión fracasada
(simplethread.com)<p>- Han pasado 20 años desde que se publicó el Agile Manifesto y, a estas alturas, hay dos hechos evidentes:<br />
1. Se ganó en ponerle nombre a Agile. Nadie quiere que lo llamen non-Agile.<br />
2. En la práctica de Agile, se ha quedado muy corto frente a las ideas revolucionarias de sus fundadores.<br />
- “Todos dicen que hacen Agile, pero casi nadie es realmente Agile”. ¿Cómo llegamos a esta situación?<br />
<br />
[ Whence The Manifesto : ¿Cómo comenzó el manifiesto? ]<br />
- En febrero de 2001, un grupo de 17 expertos en software se reunió en un resort de esquí en Utah.<br />
- Tras varios días de discusión, redactaron en conjunto el "Agile Software Development Manifesto".<br />
<br />
- Lo importante es que eran "Practitioners (profesionales de trinchera)". No eran PMs, CTOs ni VPs of Engineering. Eran desarrolladores, programadores, científicos e ingenieros. Seguían escribiendo código y colaborando con stakeholders para resolver problemas. Eso es realmente importante.<br />
- Otro punto es que el Agile Manifesto no surgió de la nada. Varios de ellos ya tenían metodologías que habían creado o estaban difundiendo.<br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming <br />
<br />
- Todos en el grupo tenían mucha experiencia en desarrollo de software, y estaban buscando una alternativa a los pesados procesos de desarrollo dirigidos por documentación que dominaban el mercado en ese momento.<br />
- El núcleo del manifiesto es la explicación de cuatro valores.<br />
<br />
"Estamos descubriendo mejores formas de desarrollar software, haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:<br />
- a los individuos y sus interacciones por encima de los procesos y las herramientas<br />
- el software funcionando por encima de la documentación exhaustiva<br />
- la colaboración con el cliente por encima de la negociación contractual<br />
- la respuesta al cambio por encima de seguir un plan<br />
Es decir, aunque hay valor en los elementos de la izquierda, valoramos más los de la derecha."<br />
<br />
[ A New Hope : Una nueva esperanza ]<br />
- Visto desde 2021, es fácil dar por sentadas muchas prácticas modernas de desarrollo de software, pero en 2001 estas ideas eran muy radicales.<br />
- ¿Empezar a desarrollar software antes de recopilar todos los requisitos y evaluar todas las funciones? ¡Están locos!<br />
- Un punto importante que se ha ido olvidando es que, al principio, Agile era abierta y combativamente anti-management.<br />
<br />
- Por ejemplo, Ken Schwaber, cofundador de Scrum, defendía eliminar a todos los project managers; no solo sacar al PM de los proyectos, sino borrar esa profesión de la industria.<br />
<br />
"Descubrimos que el rol del project manager es improductivo en el trabajo complejo y creativo.<br />
La forma de pensar del project manager, expresada en el plan del proyecto,<br />
en lugar de reunir la inteligencia de todos para resolver mejor el problema,<br />
limita la creatividad y la inteligencia de todos a lo que está escrito en el plan."<br />
<br />
- El scrum master casi no tenía autoridad y ni siquiera tenía voto sobre los issues. Era un servant leader*, protegía al equipo y quitaba obstáculos, pero no lo gestionaba.<br />
→ Servant leader: líder que sirve a sus subordinados, ayuda a su crecimiento y desarrollo, genera confianza entre líder y equipo y hace que contribuyan por iniciativa propia a los objetivos de la organización.<br />
- En XP originalmente también existían los roles de Tracker y Coach, y funcionaban de forma parecida.<br />
<br />
- Alistair Cockburn, creador de Crystal y de la arquitectura Hexagonal, comentó esto hace poco en un hilo de Twitter:<br />
"Scrum cerró un trato increíble en territorio hostil:<br />
- La dirección podía cambiar de rumbo 12 veces al año, como quisiera, después de cada sprint.<br />
- El equipo obtenía un mes completo de calma, sin interrupciones ni cambios de dirección, para hacer trabajo pesado de pensamiento y ejecución.<br />
- El equipo podía anunciar, durante el Bid (para definir prioridades), qué podía y qué no podía hacer en un mes sin interferencia de la dirección.<br />
- Ningún ejecutivo consiguió jamás un mejor trato que este.<br />
- Ningún equipo de desarrollo consiguió jamás un mejor trato que este.<br />
"<br />
(Esta respuesta en Twitter comenzó con la pregunta: "¿De dónde salió la idea de que un equipo Scrum debe completar al 100% todos los ítems asignados al sprint? Eso no tiene sentido". Vale la pena leer el hilo original completo).<br />
<br />
- He trabajado más de 15 años en equipos Agile y soy scrum master certificado, además de haber leído muchos libros populares del área, pero nunca había visto la idea de Scrum explicada de forma tan clara y concisa.<br />
- Scrum fue creado para funcionar en entornos hostiles. Es un acuerdo entre desarrolladores que necesitan tiempo para pensar y explorar, y managers coercitivos.<br />
<br />
[ The Empire Strikes Back : El Imperio contraataca ]<br />
- En cierto sentido, Agile fue un movimiento laboral de base. Empezó con practitioners y subió hasta la dirección. ¿Cómo logró tener éxito?<br />
- En parte, porque aumentó la cantidad de desarrolladores y el valor que aportaban al negocio.<br />
- Pero la razón más grande fue que el desarrollo tradicional en waterfall simplemente no estaba funcionando.<br />
- A medida que el software se volvió más complejo, el ritmo del negocio se aceleró y los usuarios se volvieron más exigentes, se hizo imposible planearlo todo por adelantado.<br />
- Adoptar desarrollo iterativo era algo lógico, pero para los managers acostumbrados a planearlo todo, daba un poco de miedo.<br />
<br />
- A mediados de los 2000, la dirección todavía no lo aceptaba del todo.<br />
- Luego apareció la idea de: "Probemos esta idea loca de la que los ingenieros no dejan de hablar. Total, igual ya no vamos a cumplir la fecha límite; ¿qué tan mal puede salir?"<br />
- Pero, sorprendentemente, empezó a funcionar. Al principio los equipos estaban un poco encogidos (iban más lento), pero gradualmente comenzaron a entender qué patrones funcionaban para cada equipo y empezaron a agarrar velocidad.<br />
- Después de unos cuantos sprints, entendieron el poder de priorizar el software funcionando, la colaboración, y dedicar tiempo a inspeccionar y adaptarse, por encima de todo lo demás.<br />
<br />
- Durante unos cinco años, Agile pasó de ser una metodología de la que algunos habían oído hablar a algo con lo que no todos estaban familiarizados, pero que iba expandiéndose.<br />
- En 2005, Agile y TDD eran verdaderos diferenciadores.<br />
- En 2010, todos los equipos de software modernos estaban haciendo Agile de alguna forma.<br />
- Al menos en la industria de consultoría, era una burbuja. Aunque las grandes empresas siempre se movieron más lento.<br />
<br />
"¡Lo logramos! ¡Ganamos! ¡Felicitémonos todos!"<br />
Aquí termina la historia, y ya pueden cerrar la pestaña del navegador.<br />
<br />
"Winning was easy, young man. Governing’s harder."<br />
"Ganar fue fácil, joven. Gobernar es más difícil."<br />
→ George Washington, tal como es retratado en Hamilton (el musical)<br />
<br />
- Desafortunadamente, como muchas revoluciones, la historia de Agile no se desarrolló como la imaginaron sus fundadores.<br />
→ Resultó que priorizar "individuos e interacciones" era una idea difícil de vender. Es mucho más fácil vender procesos y herramientas.<br />
→ Resultó que producir "software funcionando" es más difícil que producir planes irreales y mucha documentación.<br />
→ La "colaboración con el cliente" requiere confianza y vulnerabilidad, y eso no siempre existe en los negocios.<br />
→ "Responder al cambio" suele pesar menos que las necesidades de la dirección de hacer planes a largo plazo y mantener el control.<br />
<br />
"Resultó que, si Agile no se ejecuta bien, muchas veces se siente como caos"<br />
<br />
- Pero eso no significa que estos cuatro valores estén equivocados.<br />
- Significa que para que todo esto funcione de verdad hace falta algo de esfuerzo, y también el valor de aceptar que el software es inherentemente desordenado y caótico.<br />
- Hay que entender y creer que, si seguimos aprendiendo, adaptándonos, mejorando y entregando, al final llegaremos a un lugar mucho mejor que waterfall: más honesto, más realista y más productivo.<br />
<br />
"El movimiento Agile no es anti-metodología.<br />
De hecho, muchos de nosotros queremos restaurar la credibilidad de la palabra 'metodología'. Queremos que se recupere el equilibrio.<br />
Aceptamos el modelado, pero no para guardar diagramas en una bodega polvorienta de la empresa.<br />
Aceptamos la documentación, pero no libros de cientos de páginas que no se mantienen y casi nunca se usan.<br />
Hacemos planes, pero reconocemos los límites de los planes en entornos turbulentos.<br />
Quienes etiquetan a los defensores de XP, Scrum u otras metodologías Agile como 'Hackers' desconocen las definiciones originales de los términos 'metodología' y 'hacker'."<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- Estos son puntos importantes. Seguimos haciendo planes y documentación, y debemos ser rigurosos con Agile. Se trata de equilibrio.<br />
- Pero si tu organización está teniendo dificultades con la transición a Agile y cae en el caos, si alguien te ofrece un salvavidas en forma de certificaciones, procesos y herramientas, vas a saltar hacia ahí.<br />
- La dirección entiende mucho mejor los procesos y las herramientas que los "equipos autoorganizados".<br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One (el regreso) ]<br />
- Aquí mi estructura de tres actos se rompe un poco, porque no se ve ninguna valiente rebelión regresando sin llevar la etiqueta Agile.<br />
<br />
- Los vendors de herramientas, consultores de procesos y expertos suelen prometer cosas que jamás podrán cumplir.<br />
- Esa es la razón por la que terminamos creando SAFe (Scaled Agile Framework for Enterprise), Scaled Scrum y otras versiones de Agile para empresas.<br />
- Estos frameworks no fueron creados con mala intención, y probablemente tengan cierto valor en el contexto adecuado.<br />
- Pero yo no los llamaría Agile.<br />
- Si intentas escalar una metodología centrada en individuos e interacciones, inevitablemente surgen problemas y se dañan los valores originales de la metodología.<br />
<br />
- Ron Jeffries, firmante del manifiesto Agile y cofundador de XP, escribió este texto famoso en 2018:<br />
<br />
"Los desarrolladores deberían abandonar Agile.<br />
Cuando las ideas 'Agile' no se aplican correctamente, se genera más interferencia sobre los desarrolladores, menos tiempo para trabajar, más presión y exigencias de 'ir más rápido'. Eso no es bueno para los desarrolladores y, al final, tampoco para la empresa. Cuando 'Agile' se hace mal, suele producir muchos más defectos y un avance más lento de lo que realmente sería posible. Con frecuencia, los buenos desarrolladores terminan yéndose de esas empresas, y el resultado es una organización menos eficiente que antes de adoptar 'Agile'."<br />
<br />
- Dave Thomas, otro firmante y cofundador de Pragmatic Programming, escribió este famoso texto en 2014:<br />
<br />
"Agile ha muerto. (Larga vida a la agilidad)<br />
La palabra 'Agile' ha sido tan subvertida que prácticamente ya no significa nada, y la comunidad Agile se ha convertido en gran medida en un lugar donde consultores y vendors venden servicios y productos. A medida que el manifiesto se popularizó, la palabra Agile se volvió un imán que atrae cualquier cosa que tenga algo que promover, horas que facturar o productos que vender, convirtiéndose en un término de marketing.<br />
<br />
Por eso creo que ya es momento de jubilar la palabra 'Agile'."<br />
<br />
[ Retro : Regreso al pasado ]<br />
- Lo realmente triste es ver a desarrolladores jóvenes despreciar Agile y pensar que es una herramienta para que la dirección imponga promesas irreales y empuje a los desarrolladores a trabajar una cantidad absurda de horas.<br />
- El único Agile que conocen es un mecanismo de control impuesto sobre ellos, no una herramienta de empoderamiento que alguna vez fue recibida con entusiasmo.<br />
- Aun así, espero que empezar a discutir la historia y la visión original nos ayude a recordar cómo deberíamos avanzar de aquí en adelante.<br />
<br />
- Incluso así, la buena noticia es que los principios del Agile Manifesto siguen siendo tan sensatos y relevantes hoy como hace 20 años. Y hasta quienes parecen apóstatas, como Jeffries o Thomas, siguen pensando lo mismo.<br />
<br />
- En el texto mencionado arriba, Jeffries dice lo siguiente:<br />
"Sin embargo, los valores y principios del Manifesto for Agile Software Development siguen ofreciendo, en mi opinión, la mejor manera de construir software que conozco, y basándome en mi larga y variada experiencia, seguiré esos valores y principios en organizaciones grandes sin importar qué metodología usen."<br />
<br />
- Estoy de acuerdo con esa opinión.<br />
- Hablar de Agile hoy ya no es algo cool ni de moda. Agile es aburrido.<br />
"Todos hacen Agile, ¿no?"<br />
- Este es el momento perfecto para mirar hacia atrás a estos 20 años y hacernos algunas preguntas:<br />
→ ¿Qué salió bien?<br />
→ ¿Qué salió mal?<br />
→ ¿Qué te gustaría hacer distinto la próxima vez?<br />
- En los próximos meses, el autor planea volver a revisar los 12 principios originales de Agile, contextualizar su significado original y considerar su valor en el entorno actual de desarrollo de software.<br />
<br />
"Mi esperanza es que, al estudiar los principios fundacionales, podamos aprender del pasado y, como dice Dave Thomas, incluso si abandonamos 'Agile', podamos conservar la 'Agility'."</p>
3 comentarios