Las retrospectivas en SCRUM son reuniones que se realizan tras finalizar el sprint (después de la demo o revisión del sprint y antes de la planificación). La duración de la reunión depende de la duración del sprint: normalmente 1 hora, por semana de sprint.
El equipo identifica problemas, posibles medidas para solucionarlos y valoran aquellos hábitos o forma de trabajo que el equipo desea mantener: en la reunión de retrospectiva, se exponen, plantean y reflexionan los tres grupos. Surgiendo medidas o acciones necesarias para mejorar en posteriores sprints.
Se trata de evolucionar la forma de trabajar mediante la mejora continua hacia la excelencia, incrementando la productividad progresivamente. Además, fomenta la cohesión y la confianza del equipo.
En la reunión, el equipo contesta tres preguntas:
¿Qué ha funcionado bien?
¿Qué debemos mejorar?
¿Que acciones tomamos?
Es recomendable reflejar las respuestas en un simple tablero Kanban a lo largo de la reunión:
En primer lugar y normalmente se hace balance de lo que ha ido bien y lo que debe mejorar, para posteriormente tomar las medidas o acciones recomendadas para mejorar.
Existen otras variantes o técnicas para reflejar las reflexiones del equipo en esta reunión: la técnica del barco de vela o la técnica de la estrella de mar:
En este caso existen más apartados en los que reflejar las opiniones del equipo o la evolución de éstas en el transcurso de varios sprints. Tener más apartados significa tener más detalle de la situación, aunque también significa invertir más tiempo en consensuar todas las posibilidades con el equipo.
En mi opinión, es más acertado tener un tablero simple que influya al equipo a ser más estrictos en la síntesis, centrándose en lo realmente importante.
Las acciones que se identifiquen como tareas, pueden incluirse en el Product Backlog del proyecto que corresponda. El resto, se informarán en el tablero.
El Kaizen y las retrospectivas
Uno de los libros que leí hace poco el cual recomiendo: El camino del Kaizen, nos explica todas las ventajas que supone aplicar esta filosofía en la mejora continua constante mediante pequeños pasos acumulativos. Las retrospectivas son las reuniones ideales para ponerla en práctica.
Se trata de establecer acciones fácilmente abarcables que nos permitan adoptarlas sin mayor esfuerzo.
Evitar indicar grandes acciones a grandes problemas, tratando en todo caso de desglosarlo haciendo frente a una parte mínima de éste, para poder combatirlo más eficazmente mediante pequeñas acciones hasta que desaparezca por completo. O bien, hacerle frente en su totalidad, pero empezando y eligiendo el primer paso mínimo fácilmente abarcable para combatirlo progresivamente a lo largo de los sprints.
¿Qué ocurre si las acciones no se realizan y se acumulan?
Desde mi punto de vista, el motivo principal de raíz por lo que no se cumplen, es el enfoque incorrecto de las acciones que se aplican para solucionar el problema: ya sea por intentar solucionar la totalidad del problema (siendo una gran y compleja acción), son demasiado conceptuales/abstractas o dependen de terceras personas externas al equipo.
Aquellas que dependen de terceras personas externas al equipo, son las candidatas a incluirlas en el Product Backlog que corresponda.
Si no se realiza una acción determinada en el sprint siguiente, nos indica que la acción tiene un mal enfoque: debemos seguir disminuyendo el tamaño de la acción o experimentar con otras pequeñas acciones que hagan frente al mismo problema, hasta que se realice.
No soy partidario de responsabilizar a nadie para que las acciones se realicen, la presión y la responsabilidad debe caer al equipo al completo por igual.
Lecturas recomendadas:
7 razones por las que las retrospectivas en Scrum fallan
Retrospectiva de estrella de mar (Starfish retrospective)
Agile Retrospectives: Making Good Teams Great