La Sprint Retrospective (la “Retro”) es una reunión en que el protagonista es la búsqueda de la mejora en todos los aspectos de la gestión y la construcción del producto

Solo hay una reunión en el marco de trabajo Scrum donde el Scrum Master es responsable de su organización, así como pilotarla i aplicar las decisiones que se desprendan en ella. Y es la Sprint Retrospective. En el resto de reuniones propuestas en el marco de trabajo, los responsables son los propios técnicos (Sprint Planning y la Daily), o el Product Owner (Sprint Review)

Cómo hemos dicho, el objetivo de esta reunión es proporcionar al equipo un espacio para poder debatir sobre que aspectos pueden mejorar en adelante en las acciones de construcción del producto. Para hacer esto, es muy buena práctica utilizar la experiencia inmediata obtenida en la ejecución del Sprint que justo acaba de finalizar. En este sentido, hay algunas fuentes de datos que el Scrum Master y el equipo pueden utilizar para hallar áreas de mejora:

El resultado final del Sprint

Algunas cuestiones que el Scrum Master i el equipo técnico pueden poner sobre la mesa en la Retro:

• ¿Se han resuelto satisfactoriamente todas las historias de usuario previstas en el Sprint?
• ¿Se ha dodo respuesta al objetivo del Sprint (Sprint Goal) inicialmente establecido?
• ¿Se ha obtenido el valor esperado?

Resultados de la Sprint Review

La Retro se celebra (o debería celebrarse) justo después de la Sprint Review del Sprint. Por qué la información en caliente proporcionada en esta reunión es de mucho valor para la Retro. Los resultados de la Review van más allá de sí los stakeholders nos han aceptado o no el incremento. E incluyen otras variables objetivas y subjetivas:

• ¿Hemos podido mostrar el resultado final al Product Owner y hemos podido ponerle al día para qué sea el quién lidere la reunión?
• ¿Han estado presentes los Stakeholders apropiados?
• ¿Los Stakeholders, han podido validar las historias de usuario y el propio incremento de acuerdo a unos criterios de aceptación correctos y viables?
• ¿Los Stakeholders nos han proporcionado feedback de valor en la reunión?
• ¿El Product Owner ha cumplido con su papel a la hora de pilotar la reunión?
• Ante pequeños problemas e inconvenientes que fácilmente pueden aparecer en la reunión (por ejemplo: problemas con el entorno o problemas de seguridad o de acceso). ¿Hemos actuado de forma apropiada?

La lista de incidentes

El Scrum Master es responsable de la lista de los incidentes, bloqueos o problemas aparecidos durante el Sprint. Esta lista se somete a debate en la Retro para poder extraer algunas propuestas de mejora.

• ¿Por qué han aparecido?
• ¿Cómo se han resuelto (si es que se han resuelto)?
• ¿Cómo ha impactado en el trabajo o en las tareas del Sprint?
• ¿Cómo podemos actuar para qué un problema dado no aparezca o quede mitigado?

Los tiempos

Al final, los tiempos son siempre una fuente necesaria de información. Los tiempos de resolución de las historias de usuario y de las tareas técnicas nos da información sobre la complejidad real en comparación a la inicialmente estimada. Casar lo que estimamos con el resultado en la práctica es un buen ejercicio para aprender y afinar en futuras estimaciones.

Los éxitos

No podemos hacer una Retro basada únicamente en los problemas.

Hacer esto es no tener en mente a las personas que tenemos delante. Somos personas, no máquinas. Los éxitos, es decir, aquello que hemos hecho bien, es tan o más valioso que un problema de la lista de incidentes.

El Scrum Master ha de tomar buena nota de las cosas que se han hecho bien y exponerlas en la reunión, para qué el equipo adquiera conciencia de lo que hace bien, y lo refuerce en los sprints siguientes.

Las acciones de mejora como resultado necesario de las reuniones de Retrospective

Una Retro que acaba sin decidir nada no es una Retro. Las retros han de acabar con una serie de propuestas consensuadas por el equipo. A este respecto, existen algunas dinámicas que el Scrum Master puede utilizar para qué el equipo participe, debata, clasifique y decida las acciones de mejora más interesantes.

Una actividad bastante extendida consiste en clasificar nuestras propuestas de mejora en función de aspectos o acciones que nos interesa potenciar o mitigar. El diagrama anterior ilustra acciones que:

• no hacemos y deberíamos empezar a hacer (start)
• hacemos y deberíamos dejar de hacer (stop)
• hacemos y aún deberíamos hacer más (more)
• hacemos, no podemos dejar de hacer, pero quizás sí podemos hacer menos (less)

Una vez trabajada esta lista de mejoras, el equipo selecciona algunas (al menos una) para ejecutarla durante el sprint siguiente. Las acciones de mejora pueden ser muy diversas:

• Acciones de refactoring sobre el producto
• Acciones de mejora de las herramientas de trabajo
• Formación al equipo o a personas individualmente para suplir lagunas de conocimiento
• Cambios sobre la forma de hacer, los tempos o las reuniones

La organización debe ser consciente que las acciones de mejora son trabajo. Es decir, ocupan tiempo. Por tanto, es lógico esperar que al Sprint siguiente haremos trabajo en favor del producto, pero no del valor del sprint. Hemos de hallar un equilibrio, con la ayuda del Product Owner, para qué estas acciones de mejora puedan incorporarse en el Sprint de una forma proporcionada y razonable.

Algunos consejos para organizar la Retro

Algunos anti patrones típicos en la Retro

Descarga el esquema de la Retro

Descarga el esquema para imprimir aquí