El retrospective del segundo sprint

En el proyecto en el que estamos trabajando, una herramienta de planificación y evaluación de rendimiento de una serie de profesionales, no hacemos el programa de una vez y lo entregamos al cliente cuando todo ha terminado. En vez de eso, construimos el sistema poco a poco, de forma incremental, y se lo vamos mostrando al usuario de forma periódica. De esa forma conseguimos del usuario una valiosa información que nos permite valorar la adecuación del producto que se va construyendo, aparte de hacer visibles muy temprano en el proyecto fallos de concepto, de funcionalidad, de usabilidad, etc. y poder corregirlos a tiempo. Al fin y al cabo, los que mejor conocen el dominio del problema y los que en definitiva van a usar el programa son esos mismos usuarios.

Cada uno de estos periodos de tiempo, en los que aumentamos la funcionalidad del sistema, recibe el nombre de sprint, y las reuniones periódicas reciben el nombre de sprint review meetings, aunque nosotros las llamamos demos.

Detrás de cada demo, los miembros del equipo y el Scrum Master (o sea, el que suscribe) llevamos a cabo otra reunión en la que analizamos qué fue lo que hicimos bien (y alegrarnos), qué fue lo que no se hizo tan bien (observad el sutil efecto impersonal) y qué medidas vamos a tomar para corregirlas. A estas reuniones se les llama sprint retrospective meeting.

¿Bueno, pues hoy hemos tenido nuestro segundo retrospective. Y hemos salido muy contentos. Por lo pronto, es toda una novedad que echemos la vista atrás para poder analizar qué se hace mal y poner remedio cada tres semanas, que es nuestra longitud de sprint. Pero hacerlo dos veces, es un milagro ;-). Respecto al anterior retrospective, he notado que somos mucho más equipo, que nos conocemos mejor. Nos enriquecemos mutuamente con el intercambio de ideas, de sugerencias, de puntos de vista y de reflexiones. Para decidir qué medidas correctoras íbamos a aplicar durante nuestro tercer sprint, hemos escrito en PostIts de los grandes cada uno de los aspectos negativos. En una sesión de brainstorming, hemos ido apuntando en cada PostIt las posibles soluciones, mientras que íbamos agrupando las que estaban relacionadas (pruebas, estimación, método...). Luego, cada uno ha dado sus nominaciones: tres votos a repartir entre un máximo de tres aspectos negativos a resolver.

Pero ha sido la agrupación de los PostIts y la lista de los nominados lo que me ha hecho pensar. Le hemos dado muchísima más importancia a los temas relacionados con las pruebas que con la estimación. Por lo visto, preferimos asegurar la calidad del código frente a la calidad de la estimación. También es verdad que en la primera retrospective ya se acometió una mejora sustancial: las estimaciones ahora se hacen mucho más precisas, descomponiendo inicialmente las historias del usuario (las características que le aportan valor) en tareas más pequeñas antes de empezar el sprint, y no después. Y lo que ya me ha dejado descolocado es que una de los aspectos negativos que hemos detectado es que no hemos cumplido bien las normas del scrum. Y ahí soy yo el principal responsable, porque esa es una de mis responsabilidades... Sin embargo, estoy satisfecho. Está claro que el equipo cree en este método, si no fuera así, no le importaría que las normas hubieran sido vulneradas.

Ahora falta que la Dirección también acabe igual de convencida como nosotros. Creo que vamos por buen camino.

Imagen cortesía de Mountain Goat Software.