¿Cómo gestionar las acciones resultantes de las retrospectivas?

Scrum Master facilitando una
retrospectiva, gracias Marisa :-)

Una de las responsabilidades del Scrum Master es la de asegurarse que el equipo cierre las retrospectivas con acciones, una por retrospectiva, que sean posibles hacer durante el siguiente sprint. Recordemos que a través de las retrospectivas estamos estableciendo una cultura de mejora continua en la que equipo mejora su forma de trabajar con cada sprint.

Para asegurarnos que el equipo obtenga beneficio de las acciones propuestas, estas deben de gestionarse. Sin esta gestión las acciones de mejora pueden perderse o retrasarse innecesariamente, y el equipo puede perder la confianza en el marco de mejora continua. Suele ser frustrante si retrospectiva tras retrospectiva no hay acciones de mejora que se hayan materializado, en estos casos los equipos hasta dejan de hacer la reunión.

Las acciones resultantes de una retrospectiva deben de ser claras y entendidas por todos los involucrados, equipo de desarrollo y Propietario del Producto, y todos deben de estar de acuerdo en que las acciones son válidas.

Es recomendable que sean pequeñas y potentes, estén escritas con un patrón que incluya el porqué, la razón de esa acción o los problemas que resolverá, así como los beneficios que aportará, y también la persona o las personas que se la llevarán para gestionarla o hacer una exploración para determinar si se produce una mejora para el equipo en el siguiente sprint.

En función de la naturaleza y el tamaño de las acciones podemos llevarlas a diferentes pilas:

Acciones pequeñas al siguiente sprint, pueden incluirse en post-its de otro color el la pila de sprint en el scrum board. Ejemplos de ello pueden ser acciones como:

• Escribir todos los criterios de aceptación en la planificación de sprint
• Hacer pair work en las incidencias detectadas por el tester de manera que un desarrollador las resuelva al momento y en caliente
• Preparar una minibateria de pruebas para las revisiones de sprint

Acciones grandes a la pila de producto, suelen ser acciones que requieren de un esfuerzo estimable y que por tanto deben de tenerse en cuenta en la planificación de sprint y pueden, o no, entrar en el siguiente sprint. Ejemplos clásicos son:

• Carencia en la formación técnica o de negocio
• Preparar un máquina para integración continua
• Refactorización mayor

Para acciones de mejora que sean acuerdos del equipo llevarlas al tablero de políticas explicitas, usualmente un área específica del scrum board:

• Horario o lugar de la reunión diaria
• Hacer al menos un commit de cada elemento en el SVN a final del día
• Si alguien detecta deuda técnica añadir un post-it al tablero de deuda pendiente y mencionarlo en la siguiente reunión diaria

Impedimentos que surjan en las retrospectivas se los lleva el Scrum Master, recomiendo tener un tablero específico para éstos:

• Aligerar documentación de seguimiento (clásico de la PMO)
• Rendimiento de las VDIs (máquinas virtuales), incrementar su RAM
• Entorno de test estable y réplica de producción