Reunión de retrospectiva o Sprint Retrospective

La reunión de retrospectiva del Sprint: Es una reunión cuyo propósito es la mejora continua sobre el proceso de Scrum, permite al equipo Scrum priorizar mejoras que se implementaran en el siguiente sprint. Este contempla la inspección interna del equipo de como estuvo el sprint en término de las personas, sus relaciones, los procesos y herramientas, identificar las posibles mejoras y los puntos que salieron bien; y por último generar un pequeño plan de mejoras.

No debe durar más de 3 horas para un sprint de un mes de duración y para sprint más cortos es proporcionalmente más corta. 

Es una reunión para el equipo Scrum, para que tenga la oportunidad de analizarse en primer lugar internamente con el fin de realizar mejora continua. El equipo de desarrollo es el principal involucrado, sin embargo el Scrum Master pasa ser uno más del equipo en esta reunión y tiene derecho a voz y voto. Dado que el Product Owner es parte del equipo Scrum y el framework fomenta la transparencia, se recomienda que participe. Sin embargo, es importante que entienda el foco e la reunión para evitar enfocarse en el producto. Algunas razones típicas que veo necesarias tratar en esta reunión con los Product Owner son por ejemplo falta de involucramiento y participación en la generación del producto por parte del Product Owner en resolver dudas al equipo durante el Sprint, asistir a la Sprint Review o trabajar con historias que no están suficientemente refinadas.

No se recomienda invitar a otros stakeholders a la reunión, debido a que en general no conocen el propósito de la reunión y se podría perder; sin embargo, de vez en cuando es necesario hacer una retrospectiva dirigida con stakeholders claves para tener una visión fuera de lo que ve el equipo de las potenciales mejoras.

En esta reunión el equipo de Scrum puede actualizar la definición de terminado (DoD), el definition of ready (DoR) o los acuerdos de trabajo tratados en puntos anteriores.

Esta es sin lugar a duda una de las reuniones primordiales de Scrum, sin embargo es de las que menos se realizan en el mundo, esto se debe a varias razones, sin embargo una de las principales es que los equipos se comprometen con mejoras inalcanzables en el próximo sprint o demasiadas mejoras, desmotivándose por no poder cumplirlas. 

El Scrum Master es responsable de facilitar la reunión y hacer que cumpla el propósito y time box, sin embargo también debe preocuparse de mantener equipos motivados y fomentar la participación del equipo, esto se logra variando las dinámicas de la reunión, variando el lugar, cambiando el foco de los temas a tratar en la reunión.

Es importante que en esta reunión también se destaquen los logros del equipo, para eso es necesario tener tareas y logros semanalees, que pueden ser medidos en su avance al final de cada semana, por otro lado se puede incorporar los KUDO CADS, que es un juego de management 3.0 (https://management30.com/), que sirve para fomentar la colaboración buenas relaciones en el equipo, en el cual se dejan felicitaciones entre integrantes del equipo scrum y a terceros si se requiere. Abajo puede ver algunos ejemplos de Kudo Cards:

Por otro lado, el equipo debe votar en esta reunión por las potenciales mejoras que deben realizarse en el próximo Sprint, la guía de Scrum 2017 indica que debe hacerse al menos una mejora en el próximo sprint, sin embargo se conseja hacer máximo tres, que sean alcanzables de cumplir dentro del próximo sprint, con poca demanda de horas por persona, con fechas y responsables claros de realizar las mejoras.

Las dinámicas más comunes en la retrospectiva del sprint son la starfish (estrella de mar), el bote rápido (speed boat) y timeline (línea de tiempo), a continuación explicaremos cada uno de ellos para que pueda comenzar a aplicarlos, sin embargo es importante destacar que estos no se pueden hacer de manera repetitiva porque pierden efectividad y es labor del scrum master buscar nuevas dinámicas de facilitación y ver cual es la más apropiada en cada caso.

1 Estrella de mar: Permite clasificar de forma lúdica y claramente aquellas cosas que sucedieron durante el sprint en 5 categorías, que son que se debe empezar a hacer, seguir haciendo, hacer más, empezar a hacer, dejar de hacer y hacer menos. Esta votación la hace el equipo de desarrollo y luego se toman decisiones de las mejoras.

2 Speed Boat: Representa una situación en la cual se busca como objetivo llegar a una isla, siendo esta el objetivo del sprint y se analizan las anclas, que representan todos aquellas situaciones que impedían llevar a la isla y las velas, todas aquellas que ayudaban a llegar. Como agregado pueden haber tiburones en la bahía, quie son amenazas o riesgos potenciales que podrían impedir llegar. Existen anclas y velas más pequeñas y más grandes.

La dinámica logra en un ambiente lúdico identificar potenciales mejoras (anclas) y cosas buenas (verlas) que se han hecho pudiendo votar por las más relevantes para comprometer mejora continua.

3 Timeline: La línea de tiempo es otra dinámica que permite analizar y aprender de un período de tiempo problemático que se haya vivido. Contiene 5 pasos, que son:

1 Preparación: Se dibuja una línea de tiempo horizontal, identificando los principales hitos, clasificando los problemáticos de los buenos.

2 Conseguir datos: Se buscan datos que potencien y respalden los hitos identificados, como por ejemplo número de impedimentos recurrentes.

3 Generar conocimiento: Permite analizar más allá los principales hitos problemáticos con el fin de encontrar las principales causas raíces que los generan. Para esto se pueden utilizar herramientas de Lean como los 5 porqué (https://es.wikipedia.org/wiki/Los_cinco_¿Por_qué%3F) o el diagrama de Ishicagua (https://es.wikipedia.org/wiki/Diagrama_de_Ishikawa). Al finalizar este punto se debe elegir en conjunto los principales problemas a solucionar.

4 Decidir que hacer: En esta etapa el equipo debe elegir un par de apuestas experimentales de acciones de mejora para solucionar los problemas elegidos en el punto anterior. Deben ser pocas mejoras concretas porque deben alcanzar a hacerse dentro del sprint que viene. Se recomienda aplicar las técnicas como tormenta de ideas, brainwriting (https://samuelcasanova.com/2014/09/brainwriting-o-tecnica-635/) y las 4W:

• 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.

Todo esto pensando ejecutarse en el próximo Sprint.

Ver video: