¿Qué era lo que queríamos evitar de la Cascada? Entre otras cosas, queremos evitar los momentos de transición! Se pierde mucha información cuando se la transfiere a otra persona. Otra cosa que queremos evitar es crear un orden estricto en las cosas, porque lleva a una flexibilidad limitada. Igualmente, el Sprint Cero es una práctica bastante común, y parecería que ocurre antes que todas las otras cosas, ¿no?.
Entonces, ¿cómo hacemos un Sprint 0 de manera inteligente? Veamos algunos principios.
- el Sprint Cero no debería durar más de 1 semana.
- gastar la mitad del tiempo del Sprint Cero en capacitación y conformación del equipo alcanza.
- hacer más de lo estrictamente necesario para empezar el primer sprint es demasiado.
- el resultado del Sprint Cero es empezar directamente con el Sprint Uno.
¡SI! Es importante mantener un ritmo parejo de duración en los sprints. Pero el Sprint Cero es la excepción. Mientras más corto, mejor. Sería completamente aceptable empezar un Sprint Cero el miércoles y comenzar el Sprint Uno el próximo lunes.
¡SI! El entregable de cada sprint es código con calidad productiva. Pero el Sprint Cero es la excepción. El Sprint Cero se usa para conocernos. Conformar un equipo, antes de empezar a construir software. Obviamente que no se puede conformar un equipo en 5 días, pero es un buen inicio. Este inicio puede hacer la diferencia entre llegar a ser un Equipo o ser un grupo de personas.
¡SI! Debemos tener la meta final en mente. Pero no pospongamos el inicio hasta comprender el final. Inspección y Adaptación. Sea que sea lo que hagamos, la meta va a cambiar por todo lo que aprenderemos en el camino.
Puede ser muy importante tener un Sprint Cero efectivo. La mayoría de los involucrados seguramente habrán leído algo de Scrum, y lo que recordarán es que Scrum es Ágil y que los equipos autogestionados enfocados entregan software. Tener un Sprint Cero de 3 semanas va a matar el entusiasmo y la esperanza en cualquier principio de Scrum o de Ágil.
Ágil establece que se valora a los individuos y sus interacciones por sobre los procesos y las herramientas. ¡Es verdad! Podemos inventar cualquier tipo de proceso con cualquier cantidad de herramientas, y sin las personas correctas interactuando, el proceso nunca funcionará y las herramientas no servirán de nada. De la misma forma, un grupo de individuos no es la fórmula ganadora; necesitamos crear un Equipo de todos estos campeones y allí está la diferencia. Debemos hacernos tiempo para conformar un equipo en el Sprint Cero, porque más tarde corremos el riesgo de no tener tiempo.
La arquitectura y las herramientas son bienes importantes para los equipos que entregan software de manera exitosa. Sin embargo, es más importante construir software y aprender de ello. Recordemos que si no podemos imaginar la arquitectura en 2 días, la cosa no va a cambiar mucho después de 2 semanas. Mientras desarrollamos y exploramos las historias, va a emerger la mejor arquitectura posible.
¿Cómo se ve un Sprint Cero ideal?
En un Sprint Cero ideal el equipo completo se sienta junto por 3 días consecutivos:
- El primer día para tener un entrenamiento en Ágil y Scrum. Es importante que este entrenamiento lo haga todo el equipo, y que el entrenador le preste atención a los aspectos de conformación de equipos. Durante este día deberían aparecer las reglas del equipo y la Definición de Terminado.
- El segundo día es para examinar el backlog. Asumimos que el Dueño del Producto ya lo tiene preparado, y que el equipo sólo necesita validar la calidad del backlog. Sin embargo, aunque este no sea el caso, el equipo y el Dueño del Producto deberían ser capaces de crear suficientes historias en el backlog para el primer Sprint. El Dueño del Producto tiene la visión/ideas, el Equipo tiene la necesidad de especificar las cosas y por lo tanto hace preguntas. Sería una pérdida de tiempo pasar más de 1 día en la creación del backlog del producto. Este es el trabajo del Dueño del Producto y no del Equipo. Dado que estamos hablando de un Sprint Cero ideal, la calidad del backlog es alta, y medio día debería alcanzar para determinar que las historias de usuario están lo suficientemente bien armadas para estimarlas. De esta manera, la segunda mitad del día podría usarse para estimar los cambios más importantes.
- El tercer día es para terminar el Sprint Cero. En otras palabras, el tercer día debería usarse para asegurarnos que podemos empezar el Sprint 1 al día siguiente. Si todavía no se definió la Definición de Terminado, este es el momento de hacerlo. Asegúrense de que queda tiempo para conformar el equipo, conocerse entre si. Hay varios ejercicios que disparan discusiones interesantes y que ayudan a enfocarse en la Agilidad del equipo.
Por supuesto, el mundo no es ideal. Sin embargo, puede ayudarnos tener presente estos principios. Y teniendo estos principios, vamos a darnos cuenta que el mundo es más ideal de lo que pensábamos.
