Claves para una excelente retrospectiva. Seguramente has escuchado que las retrospectivas “no dan valor”, “son un juego”, “nos hacen perder el tiempo”… Esto tiene sentido cuando muchos facilitadores vienen utilizando “la dinámica del barco” durante años y no entienden cómo sacar el máximo provecho a las retrospectivas.
Veamos estas Claves para una excelente retrospectiva y llevar a los equipos al siguiente nivel.
1. Entender el propósito
En este caso: IDENTIFICAR FORMAS DE MEJORAR PARA EL EQUIPO.
Como en todo contexto, entender el propósito te va ayudar a alcanzarlo. Parece algo lógico pero te puedes llevar una sorpresa al preguntarle a tu equipo si entiende para qué se hace una retrospectiva, si tu equipo lo tiene claro le permitirá prepararse para la sesión y tener una mejor predisposición y apertura.
2. Icebreaker
Si en una retrospectiva el equipo no habla, no podrás recopilar datos para luego definir acciones de mejora, es clave energizar y conectar al equipo. Ya sea una retrospectiva virtual o presencial siempre recomiendo ejecutar un Icebreaker que no tomará más de 5-10 minutos de la retrospectiva.
Te dejo un link dónde encontrarás muchos ejemplos: https://www.funretrospectives.com/category/energizer/
3. La dinámica
Como lo mencioné al inicio del artículo existen muchas más dinámicas además de “la del barco”, pero, ¿Qué dinámica debes usar en tu equipo?
En mi opinión la dinámica a elegir depende mucho de la madurez y el contexto del equipo. El modelo de Tuckman para el desarrollo de equipos comprende 4 fases:
– Forming: Construcción del equipo
– Storming: Fase de conflicto y agitación
– Norming: El equipo alcanza su momentum
– Performing: Alto desempeño
Usemos esta gráfica como referencia de qué dinámica usar dependiendo la madurez del equipo:
Te dejo un link dónde encontrarás todas las dinámicas explicadas: https://miro.com/app/board/uXjVPLlRfbg=/?share_link_id=143124848951
4. Analizar datos
El facilitador debe ver el impacto de las retrospectivas a través de la medición, no hay forma de saber que tanto estamos mejorando si no medimos el performance del equipo.
Imagínate que soy tu nutricionista y al verte te digo que debes bajar de peso porque te veo más gordo, es muy probable que no lo tomes de buena forma. No es lo mismo que yo te diga que de acuerdo a tu último control subiste 2 kg de peso y 5% de grasa corporal y debemos hacer algo. Esto es muy relevante porque los datos quitan la subjetividad de una opinión o apreciación.
Para el equipo es más fácil encontrar brechas cuando les llevamos los datos que miden su performance (si es un equipo de desarrollo deberían analizar su velocidad, % cumplimiento, calidad, Lead Time, Diagrama de flujo acumulado, etc).
Debemos hacer un seguimiento de las métricas mencionadas en todas las retrospectivas para inspeccionar el performance del equipo. Sin embargo no es el único momento para medir el impacto, por ejemplo si la mejora va en pro de mejorar el flujo de entrega del equipo podemos ver el impacto mediante el comportamiento del Diagrama de flujo acumulado o Burn Down Chart durante el sprint, o ver el incremento o disminución de la velocidad al final de cada sprint.
A continuación te dejo un ejemplo real de un problema solucionado analizando datos y usando una de las dinámicas mencionadas:
Problema:
- Bajo % de cumplimiento (30% promedio en 4 sprints)
- Su velocidad era muy poco predecible (Un sprint podían terminar 70 puntos y otro solo 20)
Dinámica: Después de mostrar las métricas usamos la dinámica “¿Qué aprendimos? – ¿Qué anhelamos?” para encontrar mejoras.
Acciones:
- Aplicar técnicas de slicing de Historias de usuario (El tamaño de las historias de usuario no podía ser de más de 8 puntos)
- Disminuir el total de historias y puntos comprometidos por sprint (El equipo empezó a tomar en cuenta su velocidad (capacidad) durante la planificación del sprint)
Resultado: Luego de 2 sprints llevando a cabo estas acciones el equipo pasó de un cumplimiento del 30% al 80% y mejoró su predictibilidad y su velocidad promedio.
“Lo que no se mide no se puede mejorar”.
5. Participantes
Según la Guía de Scrum todo el Scrum Team debe participar en la retrospectiva, PERO podemos elegir no invitar a alguien dependiendo el contexto.
Hace algunos años mientras preparaba una retrospectiva recibí comentarios respecto a la casi nula presencia del Product Owner durante el sprint, para mi sorpresa durante la retrospectiva no se expuso ese tema. Luego de tener conversaciones y analizar la situación decidí pedirle al Product Owner que no participe en la siguiente retrospectiva y pasó lo que ya sospechas, el equipo expuso no sólo este problema sino muchos otros más. Esto abrió mucho espacio de mejora para el equipo y los hizo evolucionar.
Entonces… Según mi experiencia, dependiendo del contexto podemos elegir si en alguna ocasión es necesario prescindir de la participación de alguien.
6. Accionar
Siempre repito: “Si no hay acciones de mejora, no es una retrospectiva”.
Como facilitadores debemos asegurarnos que en todas las retrospectivas el equipo identifique y planifique acciones para mejorar. Sólo así vamos a cumplir con el objetivo de mejorar y las retrospectivas tendrán el impacto que queremos.
Te recomiendo que comprometas por lo menos 2 acciones de mejora por sprint y que estas acciones las agregues a tu sprint backlog.
