Ceremonias Scrum: Sprint Retrospective

Concepto

La retrospectiva de Sprint es una reunión de mejora contínua del proceso

Reglas

• Duración máxima de 3 horas en Sprints de 4 semanas. Tiempo proporcional para ciclos más cortos.
• Participan el Scrum Master y el equipo de desarrollo obligatorios. Se puede invitar al dueño de producto si se considera necesario o conveniente

Elementos necesarios

• Sala de reuniones. Si el equipo es distribuído, las herramientas telemáticas correspondientes.
• Lista de acciones de mejoras de la iteración anterior.
• Lápiz y papel. Notas autoadhesivas.

Desarrollo

El protocolo más utilizado es de 5 pasos.

Preparar el escenario / romper el hielo

El propósito es lograr que la gente adopte una actitud abierta y de buena disposición a comunicar. Esto se puede conseguir mediante alguna actividad del tipo icebreakers o dinámica grupal lúdica. Algunos ejemplos son: la torre de nubes, dibujar la iteración, ronda de admiración. Un muy buen recurso es Retromat (https://retromat.org/). 

Recopilar información

En esta etapa, buscamos generar insights sobre qué ha ocurrido durante el Sprint. Qué cosas han ido bien, mal o se pueden mejorar. Preguntar esto directamente a los participantes no es efectivo. Podemos utilizar técnicas como el barco de vela, la estrella, el globo aerostático, las 4 A (amado, aprendido, anhelado y ausente).

Reflexionar

Una vez que sabemos qué ha ocurrido, debemos entender cuáles son las causas y motivos. Generamos un debate abierto donde cada uno se sienta libre de expresar sus vivencias y puntos de vista. Cuando las respuestas son superficiales, técnicas como los cinco porque son útiles para indagar. Es fundamental que el equipo se encuentre a gusto con el conflicto y que tenga capacidad de resolverlo de manera positiva.

Decidir qué hacer

Cuando los motivos han sido identificados, el equipo buscará acciones de mejora. Nos aseguraremos que surja la mayor cantidad de ideas, y que todos participen. Luego, clasificaremos las propuestas, y las ordenaremos por efectividad y dificultad de implantación. Es menester comprender que la mejora continua es un proceso permanente y gradual. Intentamos capitalizar pequeños avances o quick wins en cada iteración.

Cerrar la retrospectiva

Con las acciones consensuadas de mejora elaboramos una lista, la leemos en voz alta y una vez aceptada y conocida por el equipo la pegamos en la sala de trabajo, a la vista de todos. 

Resultado

Luego de la ceremonia obtenemos una lista de acciones de mejoras y el compromiso del equipo para su implantación

Problemas habituales

Es frecuente encontrar retrospectivas disfuncionales, basadas en echar culpas, o que son tomadas a la ligera, o que luego no aplican las acciones de mejora. El equipo debe considerar este evento una oportunidad para evitar problemas pasados y mejorar el proceso. Un desarrollo optimizado permitirá aumentar tanto la velocidad como el nivel de felicidad. 

A pesar de ser un elemento crítico del marco, muchas veces, se decide suprimir el evento para abocarse a la construcción del producto. Esto puede suceder debido a que no se han conseguido ejecutar todas las historias de usuario planificadas para el ciclo, o porque existe un cronograma de proyecto con retrasos. Cuando hay una planificación inicial sujeta a un calendario, y con un alcance cerrado a fuego, es inevitable que surjan desfasajes. Estas demoras generan la necesidad de compensar el tiempo de la manera que sea, por ejemplo, quitando ceremonias scrum (la retrospectiva es siempre la primera víctima), o con sobre esfuerzos, llevando al equipo a un ritmo no sostenible.

Métricas aplicables

• Mejoras planificadas versus implantadas
• Nivel de felicidad del equipo
• Velocidad del equipo (último Sprint, media y promedio de las tres iteraciones pasadas)

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.