Cuatro valores, no cuatro reglas
El Manifiesto Ágil, publicado en 2001, se resume en cuatro preferencias: los individuos y sus interacciones antes que los procesos y las herramientas, el software que funciona antes que la documentación exhaustiva, la colaboración con el cliente antes que la negociación contractual, la respuesta al cambio antes que el seguimiento de un plan. El texto precisa que los elementos de la derecha también tienen valor. No dice «sin plan» ni «sin documentación»: dice qué va primero cuando hay que elegir.
Diez años después, un número especial del Journal of Systems and Software hacía balance de la investigación y seguía intentando explicar por qué funcionan estas prácticas, en lugar de limitarse a describirlas (Dingsøyr et al., 2012). Dicho de otro modo, la agilidad es un conjunto de prácticas que han demostrado su valor sobre el terreno, y la teoría llega después.
Qué cambia en el día a día
El trabajo se hace visible
No se puede ajustar lo que no se ve. El primer gesto de un equipo que se vuelve ágil suele ser poner todas sus tareas en un tablero compartido, aunque descubra que hay diez cosas «en curso» para tres personas.
El ciclo se acorta
En lugar de planificar doce meses, uno se da una o dos semanas, un objetivo y una demostración al final. Es el principio básico del método Scrum, aunque se puede aplicar sin adoptar todo el marco.
La medición sigue siendo simple
Al final de un ciclo bastan dos o tres cifras: lo que está terminado, lo que está bloqueado, lo que se ha retrasado. El objetivo es discutirlas, no calificar al equipo.
Empezar esta semana con un equipo de cinco
- Lunes: cada persona enumera sus tareas en curso y futuras, sin filtro. Se colocan en un tablero común.
- Se elige una duración de ciclo (una semana para empezar) y un único objetivo, realista.
- Cada día, de cinco a quince minutos: qué avanza, qué se bloquea.
- Viernes: treinta minutos para mostrar lo que está realmente terminado y decir en voz alta qué se cambia la semana siguiente.
Si no se alcanza el objetivo tras dos ciclos, primero conviene revisar el tamaño de las tareas y la estimación antes de buscar otro método.
Fuentes
- Beck, K. et al. (2001). Manifiesto por el Desarrollo Ágil de Software. agilemanifesto.org
- Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85(6), 1213-1221. doi:10.1016/j.jss.2012.02.033