La muerte lenta y dolorosa de Agile y Jira
(ehandbook.com)"Como Agile ya no es Agile, ha llegado el momento de que desaparezca junto con Jira"
- Los ciclos de desarrollo de software son cada vez más largos, los equipos técnicos cada vez más grandes, se necesitan cada vez más apps para gestionar el desarrollo, cada vez menos personas escriben código de verdad y, en períodos cada vez más cortos, hay cada vez menos avance entre puntos de control continuos
- ¿En qué momento empezó a salir mal Agile?
- Agile fue una metodología desarrollada a inicios de los 2000 como alternativa a los pesados procesos de desarrollo de software centrados en la documentación
- Sin embargo, hoy Agile se está deformando hasta convertirse en la antigua metodología compleja de gestión de proyectos
La hinchazón tecnológica (Tech Bloat) es el problema principal
- La razón principal por la que muchas personas abandonan o quieren abandonar Agile es la hinchazón tecnológica
- La hinchazón tecnológica es enemiga de toda empresa tecnológica y también representa un riesgo para empresas no tecnológicas que tienen equipos de desarrollo internos o tercerizados
- La hinchazón tecnológica es distinta de la deuda técnica, pero la produce
- Los síntomas de la hinchazón tecnológica son los siguientes:
- Se habla repetidamente con los clientes, pero no se llega a ser experto en su comportamiento
- Se evalúan y reevalúan constantemente las fechas límite y las fechas de entrega
- Hay una resistencia extrema a iniciar el proceso de desarrollo hasta que cada detalle esté documentado
- Surge la motivación de empezar por las tareas más fáciles y no por las más riesgosas
Los resultados caóticos de la hinchazón tecnológica
- Aumento de la documentación
- En el proceso se infiltra una documentación que no solo rastrea qué se desarrolló y por qué, sino también "cómo" se desarrolló
- Ese "cómo" pasa a ser el foco de las actualizaciones de estado, y el equipo reevalúa constantemente cómo está trabajando
- El equipo pasa más tiempo discutiendo por qué no se completó el trabajo que haciéndolo
- Fijación frecuente de fechas límite
- Se establecen más fechas límite en puntos de revisión más frecuentes, lo que en esencia genera micromanagement en cada punto de giro de un proceso intrínsecamente creativo
- Esto va en contra de producir software de calidad, porque todo se entrega en plazos fijados sin importar qué tan bien se haya ejecutado el trabajo
- La duda constante del proceso de reevaluación
- Durante los períodos de reevaluación, la duda constante impide declarar buenas prácticas, eliminar desperdicios y reconocer economías de escala
- Micromanagement del proceso productivo
- Cuando alrededor del 30% de una funcionalidad completa está terminada, deja de ser prioridad
- La organización entra en una espiral de muerte en la que produce lo que está en la hoja de ruta, sin importar si esa hoja de ruta sigue definiendo cómo construir un producto exitoso
- Resultado final
- El producto sufre bajo el peso de requerimientos de clientes diversos y contradictorios
- Las funciones suelen llegar tarde al mercado y se entregan en la forma y el orden que más convienen al equipo técnico, no en la forma y el orden más adecuados para el mercado
- Al final, los equipos de ventas y marketing reaccionan porque no saben qué están vendiendo ni los clientes qué están comprando
- Entonces la organización emprende una gran limpieza
El mundo necesita software ligero que haga mejor lo importante, no más funciones
- No es una idea nueva, pero es una idea de la que todas las metodologías terminan alejándose
- La gente termina preguntándose si el método Toyota es suficientemente Toyota para Toyota, y eso acaba convirtiéndose en más trabajo
- Agile ahora se ha convertido en un PMP con nombre bonito, reuniones más cortas y más reglas
- El problema no es la idea de Agile, sino la ejecución y la falta de liderazgo para controlarla
- Es un problema de la gerencia media, enfocada en fechas límite por encima de la utilidad, en recortes por encima del crecimiento y en ahorro por encima del progreso
Opinión de GN⁺
- Agile, a diferencia de su intención original, se ha burocratizado y formalizado hasta convertirse en un factor que ralentiza el desarrollo de software
- La hinchazón tecnológica es un riesgo al que deben prestar atención no solo Agile sino todas las organizaciones tecnológicas
- La documentación, la fijación de fechas límite y el micromanagement pueden terminar reduciendo tanto la calidad como la velocidad
- Como la esencia de Agile está en el enfoque en el cliente, la colaboración y la flexibilidad, hace falta volver a sus principios en lugar de quedar atrapados en la forma
- En el desarrollo de software, lo importante no es tener más funciones, sino implementar bien las funciones clave
- Como la cultura organizacional y el liderazgo determinan el éxito o fracaso de Agile, los gerentes técnicos deben prestar atención a esto
- Parece que ha llegado el momento de buscar nuevas metodologías más allá de Agile
17 comentarios
No pude ver el original completo porque es un artículo de pago, pero creo que convendría pulir un poco más la expresión traducida.
“Como Agile ya no es agile, ahora es momento de que Agile desaparezca junto con Jira”
=> “Como Agile dejó de
being agile, ahora es momento de que Agile desaparezca junto con Jira”Existe la idea de distinguir entre
Agilecon mayúscula yagileen minúscula,y aunque
being agileydoing agileestán conectados entre sí, se consideran por separado.being agile by doing agile.La razón para adoptar Agile es importante. ¿Lo implementan para que el desarrollo salga bien? No, es más bien: no soporto verlos "ahí perdiendo el tiempo". Voy a ver qué tanto se esfuerzan. Se implementa con esa mentalidad. Por eso termina siendo un infierno.
A estas alturas, parece que vamos a necesitar una checklist de cumplimiento ágil.
Antes que la cuestión de si es Agile o waterfall, si el entorno —como las personas y la cultura— sigue igual, por más que intentes imponer una metodología de desarrollo novedosa, el único camino será que se convierta en una versión K-OOO.
Si (casi) no hay cambios en los requisitos, es cierto que desde el punto de vista de quien desarrolla, waterfall es una forma realmente cómoda de trabajar. Siempre y cuando no haya cambios en los requisitos…
En la agilización K no hay reevaluación.!
Cliente: creo que el botón quedaría bien aquí en esta pantalla
Desarrollador: (me va a tocar quedarme toda la noche y además hay cosas nuevas)
Cliente: creo que debería haber un botón en otra pantalla
Desarrollador: (que alguien use una técnica de clonación por mí) sí, jaja..
Cliente: ¿todavía no está? ¿no se suponía que por calendario ya debía estar todo terminado?
Desarrollador: (sálvenme) sí..;;
No hay muchos casos en los que Agile se use de forma verdaderamente ágil y sostenible a largo plazo,
y parece que la mayoría de las organizaciones terminan convergiendo hacia trabajo tipo waterfall con plazos cortos.
El problema no es Agile. El problema es la gente que lo aplica. Sin importar qué metodología traigas, al final todo depende de cómo la implementen las personas. Yo creo que Agile no es una metodología, sino más bien una mentalidad orientada a hacer crecer el producto en ciertos ciclos. Si se pierde eso de vista y solo se hace planificación y retrospectivas a ciegas, me parece una pérdida de tiempo.
Pensé que solo era así con el k-agile, pero al parecer era un fenómeno global.
Sí, da la sensación de que siguen golpeando cualquier cosa... debería juzgarse según si encaja o no con el Manifiesto Ágil...
Incluso Uncle Bob, quien participó en el Manifiesto Ágil, entendió este problema desde temprano y publicó en 2019 el libro Clean Agile para corregir el uso erróneo de Agile, pero este tipo de problemas todavía continúa. Personalmente, creo que se debe a que Agile no tiene lineamientos estándar y usa la expresión ambigua de "cultura". Ojalá se presentaran lineamientos estándar concretos.
Creo que el autor probablemente sostendría que hay que abandonar cualquier metodología en cuanto se burocratiza.
Estoy de acuerdo. Parece que cada vez hay más casos de gente que practica mal Agile y luego dice que Agile está equivocado.
Por otro lado, también pienso que, aunque ya ha pasado bastante tiempo desde que apareció, parece inevitable que siga siendo difícil construir bien las prácticas.
¿Después de tanto dar vueltas, volvemos a lo de antes?
Opiniones de Hacker News
Problemas de Agile
Principios del Agile Manifesto
La esencia de Agile
La flexibilidad de Agile
Opiniones sobre JIRA
El origen de Agile
La situación actual de Agile
Problemas de JIRA
Aplicación de Agile