Mucho se habla de la duración de las iteraciones, en especial la duración "ideal" de un Sprint de Scrum. El tamaño sugerido va desde 4 semanas hasta tan pequeño como 2 semanas (e incluso algunos están probando con sprints de 1 semana). ¿Cuál existe una duración ideal? ¿Por qué hay un consenso sobre "mientras más chico, mejor"?
Como siempre, lo primero a analizar es el contexto del equipo, su experiencia y situación. En mi caso, al implementar Scrum empezamos usando Sprints de 3 semanas. ¡Y vaya si fue dificil! Tener que hacer entregas cada 3 semanas fue un esfuerzo importante, un cambio de mentalidad enorme para todo el equipo. Parecía muy acelerado, muy rápido.
Y sin embargo, y ya en ritmo, sentimos la necesidad de quitar esa tercer semana y empezar a trabajar con Sprints de 2 semanas. Y es que, al momento de planificar, la tercer semana nos quedaba "lejos": era facil pensar lo que íbamos a hacer la semana que empezaba, podíamos imaginar lo que ocurriría la semana siguiente.... pero la tercer semana nos quedaba distintante, oculta por una semana imaginada en el medio.
Más chico, mejor
Lo cierto es que existe un consenso sobre la duración de una iteración, y es el siguiente: mientras más chico, mejor. ¿Por qué?
En primer lugar, y tal como nos enseña Lean, las iteraciones cortas minimizan el trabajo-en-progreso (work-in-progress, WIP), lo cual significa menos desperdicio y menos costos. Menos costos se traducen en mayor ROI. Y recordemos, el objetivo del Dueño del Producto es maximizar el ROI de su proyecto.
Además, las iteraciones cortas tienden a estresar el proceso de desarrollo, revelando sus debilidades y fallas. Las cosas que en iteraciones largas se pueden tolerar o ignorar, en las iteraciones cortas se transforman en verdaderos problemas que se deben solucionar.
Y creo que justamente aquí tenemos uno de los puntos más interesantes para aplicar iteraciones cortas: estresar el proceso, revelar disfuncionalidades y encarar su resolución. Con iteraciones cortas el equipo debe automatizar todas las tareas repetitivas (build, despliegues, pruebas, regresiones, etc.) para poder concentrarse más en entregar valor de negocio para el cliente. Al tener tan poco tiempo entre las entregas, el equipo deja de tolerar problemas en el proceso y comienza a buscar soluciones.
Recordemos que Scrum ayuda a descubrir rápidamente las disfuncionalidades del proceso vigente en la organización. Las iteraciones cortas se alinean con este objetivo de Scrum y obliga al equipo a encarar los conflictos y buscar resoluciones. Scrum revela los problemas, los equipos los resuelven. Como debe ser.
