Una retrospectiva ágil de Scrum

A continuación se explica cómo hacer una retrospectiva para la solución de problemas de un proyecto e identificar qué cosas están funcionando bien.

La siguiente reunión de retrospectiva dura 2,75 horas. Los tiempos de cada actividad son aproximados. Están basados en el tiempo de análisis necesario para  proyectos con iteraciones mensuales. Estos tiempos pueden ser inferiores si las iteraciones son de 15 días o si el equipo ya tiene experiencia en la realización de retrospectivas.
 

 

Material necesario

 

Actividades

 

Puesta en escena (15′)

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

Identificación de problemas (60′)

  • 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 problemas adicionales mediante, por ejemplo, una lluvia de ideas (brainstorming). El facilitador va anotando los problemas en las tarjetas y los pega en una pared o la pizarra blanca de manera que todo el equipo pueda leerlas. Como base se puede utilizar una línea de tiempo.
  • El equipo agrupa los diferentes problemas según tengan una afinidad o relación y da nombre a cada grupo utilizando para ello otra tarjeta como cabecera de grupo (grouping).
  • El equipo vota qué grupos de problemas afectan más a los objetivos del proyecto. Para ello cada persona dispone de hasta 10 puntos en forma de post-its a repartir libremente entre los diferentes grupos.

Descubrimiento de causas (30′)

  • 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 para que el problema no se repita.

Plan de acción (45′)

  • El equipo propone soluciones para las causas que producen la mayoría de los problemas del proyecto. Para ello puede volver a 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 la lista de requisitos priorizada del proyecto (Product Backlog) o la lista de tareas de la siguiente iteración (Sprint Backlog).

Qué ha funcionado bien

Una retrospectiva no sólo debe fijarse en la solución de problemas, si no también hacer reconocimiento de las cosas que fueron bien e identificar las que hay que potenciar más. Para ello, se puede aplicar un proceso muy similar al anterior, pero mucho más rápido. Para "forzar" a que todo el equipo piense en las cosas positivas que sucedieron, el proceso de brainstorming se puede iniciar de la siguiente manera: cada miembro del equipo tiene que escribir un mínimo de 2 post-its con lo que funcionó bien. A partir de ahí, ya comienza la parte de grouping.

Conclusiones de la reunión (15′)

  • Se resumen 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


 
 
Para conocer otras técnicas que se pueden aplicar en retrospectivas, así como consejos para la facilitación de éstas:
  • Agile Retrospectives: Making Good Teams Great – Esther Derby
  • Collaboration Explained: Facilitation Skills for Software Project Leaders – Jean Tabaka.
  

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s