Dinámica de retrospectiva en scrum

Dinámica de retrospectiva en Scrum línea de tiempo


Una de las liturgias más importantes y eficaces de Scrum es sin duda las retrospectivas. La idea principal de la retrospectiva es reunirse todo el equipo después de cada iteración o Sprint para reflexionar. El objetivo de una retrospectiva es siempre elegir una acción o medida a implementar en la siguiente iteración que les lleve a mejorar como equipo.

Durante estas sesiones es común entre los Scrum Masters utilizar dinámicas de retrospectiva en equipo y juegos ágiles, con el objetivo de romper el hielo, romper la rutina, que no se conviertan en algo repetitivo, y sobre todo guiar el proceso creativo para conseguir el objetivo de la sesión, acciones y medidas que permitan la mejora continua.

A continuación os propongo una dinámica de retrospectiva ágil llamada “la línea de tiempo” o “Timeline”, muy genérica pero a la vez muy efectiva.

Dinámica “La línea de tiempo”

La dinámica de línea de tiempo o Timeline se puede utilizar en multitud de situaciones, pero sobre todo es útil cuando nos interesa analizar un periodo temporal problemático, como por ejemplo un proyecto (aplica igual a un Sprint por ejemplo).

La dinámica tiene 5 fases y el tiempo estimado es de 1 o 2 horas, dependiendo de la longitud del periodo a analizar y del tamaño de equipo.

Fase 1: Preparación preliminar (5-10 minutos)

En esta fase se prepara el terreno para la sesión. En una pizarra o flipchart se dibuja una línea de tiempo horizontal que representará el proyecto.

Con la ayuda del equipo, en ella incluimos los principales hitos y eventos del proyecto. En esta fase temprana ya se pueden comenzar a identificar los hitos problemáticos y los eventos no planificados en rojo, frente a los eventos satisfactorios en verde.

Fase 2: Conseguir datos (10-20 minutos)

Si se tienen podemos aprovechar esta fase para sacar algunos números conocidos de nuestros Information Radiators que nos aporten información cuantitativa sobre el proyecto estudiado.

Después se pregunta al equipo si tienen alguna otra información que ayude a entender el resultado del proyecto. Se puede hacer un recorrido en el tiempo para identificar las principales etapas del proyectos así como los procedimientos que han entrado en juego (si se han pasado por alto alguna definición de hecho o de ready, si se han violado los límites WIP del tablero Kanban, cuántos impedimentos han aflorado en las reuniones diarias de Scrum, etc…).

Fase 3: Generar conocimiento (20-40 minutos)

Es el momento de generar debate sobre los principales impedimentos y problemas que se han producido durante el proyecto. Al principio de esta fase siempre conviene recordar el propósito de la sesión: encontrar una medida SMART que esté al alcance del equipo y que le sirva al equipo para mejorar como equipo.

Al aflorar los primeros problemas, los más evidentes, podemos comenzar por marcar los que son más nuevos y los que son recurrentes en el equipo.

En esta misma fase, tras los primeros problemas son útiles las herramientas Lean de la técnica de los 5 por qué o el diagrama Ishikawa para el análisis de causa raíz. Normalmente suelen salir primero los problemas más superficiales y evidentes, y es necesario profundizar un poco con alguna de estas técnicas para aflorar los problemas de fondo, los que al final tienen un mayor impacto en el rendimiento.

Al finalizar esta fase deberíamos tener todos claro y consensuado un listado de los principales problemas a tratar de solucionar.

Fase 4: Decidir qué hacemos (20-40 minutos)

Una vez identificados los problemas principales y sus causas de fondo el equipo debe pasar a la fase creativa de la retrospectiva. En esta fase el equipo debe proponer soluciones y medidas correctivas de los principales problemas que se han identificado. Cualquier medida es bienvenida, pero se intentará focalizar al equipo a atacar sobre todo las causas raíz.

Lo normal es en una primera parte usar técnicas como la tormenta de ideas o variantes como el Brainwriting para aflorar cuantas más ideas mejor, sin juzgar ni descartar. Posteriormente, en una última parte debatir entre todos cuales son las mejores propuestas, bien por votaciones o por consenso. Elegiremos entre 1 y 2 medidas como mucho, ya que las medidas son de implementación inmediata y eso llevará más esfuerzo si son más numerosas, y además será también más sencillo evaluar si la medida es efectiva aplicando medidas de 1 en 1 en lugar de en grupos de 5 medidas a la vez.

Dinámica de retrospectiva en scrum

Resultado de la sesión, en postits naranja los problemas, en verde las medidas propuestas

Debe quedar claro en qué va a consistir la medida adoptada por el equipo en la retrospectiva. Para ello podemos usar las 4 Ws:

  • El qué (What): definir muy bien qué se va a hacer.
  • Quién (Who): quién es el responsable de llevarla a cabo.
  • Cómo (hoW): el plan exacto de cómo el equipo debe adoptar la medida.
  • Cuándo (When): cuándo se deberá comenzar a implementar, idealmente debería ser inmediato.

Además de definir los elementos anteriores es recomendable también definir los criterios de éxito, es decir, qué indicadores vamos a mirar para comprobar si la medida ha tenido éxito o si no está funcionando. Para ello se deberá especificar el indicador con el valor actual y el valor deseado una vez implementada la medida.

Fase 5: Cierre (5 minutos)

Al final de cada retrospectiva siempre conviene dejar un pequeño tiempo de margen para repasar una vez más el compromiso adquirido por el equipo y para recibir la opinión general del equipo sobre la sesión. Se puede simplemente preguntar al grupo qué les ha parecido la sesión y si la ven positiva, o también hacer una encuesta rápida para recoger las impresiones.

También te puede interesar...

Resumen Clean Code Este verano he releído uno de los libros de referencia de todo buen programador. Se trata de "Clean Code", de Robert C. Martin (o más conocido como Un...
Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Resumen User Stories Applied de Mike Cohn ¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean? El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y c...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *