• Rotuladores o marcadores de colores para cada uno de los asistentes
• Post-its
• Pizarra blanca grande o papel tamaño cartulina
• Datos objetivos de los problemas del proyecto (lista de requisitos priorizada (Product Backlog), lista de tareas de la iteración (Sprint Backlog), gráficos de progreso del proyecto o de la iteración (Burndown Charts), métricas del proyecto, etc.)

Actividades

Puesta en escena (5′)

El facilitador explica el objetivo de la retrospectiva y enumera los diferentes pasos y tiempos que va a tener la reunión.

Qué ha funcionado bien (15′)

Una retrospectiva no sólo debe fijarse en la solución de problemas (podría quedar una sensación demasiado negativa de que las cosas no van bien), si no también hacer reconocimiento de las cosas que fueron bien e identificar las que hay que potenciar más.

Para «forzar» a que todo el equipo piense en las cosas positivas que sucedieron, el proceso se puede iniciar de la siguiente manera: cada miembro del equipo tiene que escribir en silencio un mínimo de 2-3 post-its con lo que funcionó bien. A partir de ahí, se van poniendo de pie, explicando su post-it, pegándolo y agrupándolos por tema.

Identificación de problemas (20′)

• El facilitador hace un resumen de los hechos, objetivos conseguidos (o no) y decisiones más relevantes del período o proyecto a analizar con la finalidad de mejorar en el siguiente. Se apoya en datos objetivos utilizando para ello, por ejemplo, la lista de requisitos priorizada, la lista de tareas de la iteración, las actividades realizadas, los gráficos de progreso del proyecto o de la iteración, las métricas del proyecto, etc.
• Los miembros del equipo proponen aspectos a mejorar adicionales, anotando los problemas en post-its que se pegan en una pared o una pizarra blanca de manera que todo el equipo pueda leerlas. Como base para identificar problemas se puede utilizar una línea de tiempo del proyecto (cronograma de lo que sucedió).
• El equipo agrupa los diferentes problemas según tengan una afinidad o relación y da nombre a cada grupo, escribiéndolo como cabecera de grupo en la pizarra (o bien utilizando para ello un post-it.
• El equipo vota qué grupos de problemas afectan más a los objetivos del proyecto o la productividad del equipo. Para ello cada persona dispone de hasta 5 puntos en forma de post-its a repartir libremente entre los diferentes grupos.

Descubrimiento de causas (20′)

• Para los grupos de problemas más votados, el equipo analiza por qué se están produciendo. Para ello utiliza, por ejemplo, un diagrama de espina de pez o Ishikawa, con el problema como espina dorsal y las causas como espinas que crecen a partir de la dorsal o de otras causas, hasta encontrar las causas básicas.
• Notar que en ningún momento se trata de buscar culpables, si no de ver qué partes del proceso de trabajo, de interrelaciones y de colaboración, tanto intraequipo como con terceros, deben ser mejoradas.

Plan de acción (15′)

• El equipo propone soluciones para las causas que producen la mayoría de los problemas del proyecto. Para ello puede utilizar una lluvia de ideas. Su selección final puede estar basada en una votación o en criterios como coste, esfuerzo o tiempo de realización, satisfacción del cliente, sostenibilidad de la solución, etc.
• Se generan las tareas necesarias y en ese momento las personas ya se autosignan la responsabilidad de ejecutar, o bien las tareas se introducen en un Improvement Backlog o la lista de tareas de la siguiente iteración (Sprint Backlog).

Conclusiones de la reunión (15′)

• Se revisan las principales conclusiones y decisiones.
• Se revisa si se ha conseguido el objetivo de la reunión.
• Se analiza qué ha ido bien y qué hay que mejorar de la dinámica de la retrospectiva para que la próxima sea mejor (¡ la retrospectiva de la retrospectiva !).

Artículos relacionados

• Retrospectiva – Sprint retrospective
• Retrospectiva de estrella de mar (Starfish retrospective)
• Retrospectivas ágiles – Resultados del septimo encuentro ágil en Barcelona
• Videos cortos sobre retrospectivas

• inspección_adaptación