¿Qué es una retrospectiva?

Una retrospectiva es una reunión en la cual reflexionamos sobre la manera en la que trabajamos en un periodo de tiempo. Es una oportunidad para capitalizar aprendizajes y definir acciones de mejora a futuro.

Si vamos a uno de los libros referentes de retrospectivas: Agile Retrospectives, Making Good Teams Great (2006), sus autoras Esther Derby y Diana Larsen definen una retrospectiva cómo:

Una reunión especial donde el equipo participa después de completar un incremento de trabajo para inspeccionar y adaptar sus métodos y trabajo en equipo. Las retrospectivas permiten el aprendizaje de todo el equipo, actúan catalizadores para el cambio y generan acción.

Agile Retrospectives, Making Good Teams Great (2006)

Entonces en una retrospectiva vamos a tener: reflexión, inspección, aprendizaje y de plan acción.

Retrospectiva en Scrum

En Scrum la retrospectiva tiene lugar al final del Sprint, después de la Revisión de Sprint y antes de la siguiente Planificación de Sprint. Se trata de una reunión de, como máximo, tres horas para Sprints de un mes. En la práctica si trabajamos con Sprints de 2 semanas, la duración será a lo sumo de 1 hora y media.

¿Cual es el objetivo de la retrospectiva en Scrum?. Según la guía Scrum oficial:

El propósito de la Retrospectiva de Sprint es:

• Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas;

• Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras; y,

• Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.

Guía Scrum Oficial (2017)

¿Quienes participan?

Participa el equipo Scrum completo: equipo de desarrollo, Scrum Master y Product Owner. En cuanto a personas externas generalmente no es conveniente que participen, ya sea personas de otros equipos, líderes, gerentes, etc. ya que puede afectar el espacio seguro que buscamos generar.

Siempre hay excepciones igualmente, si hay un tema particular que ya hablamos internamente y el equipo esta de acuerdo podríamos sumar a alguien externo para conversar en conjunto.

Etapas de una retrospectiva

Etapas de una retrospectiva

1) Preparar el escenario: en esta etapa revisamos el objetivo de la reunión y cómo esta cada persona para comenzar con la retrospectiva. Conocer como llega cada uno nos va a dar mucha información para entender cómo se desenvuelve luego en la reunión. El estado de ánimo y la forma en que llegan las personas nos va a dar un indicio de qué tipo de retrospectiva va a necesitar el equipo en ese momento.

2) Recolectar Datos: recopilamos toda la información significativa del Sprint y la compartimos entre todos. Es importante en esta etapa destacar hitos o eventos importantes del Sprint (Ej: fuerte discusión entre 2 personas, error en un servidor productivo, migración a una nueva tecnología, etc.). El objetivo es lograr una visión compartida.

3) Generar descubrimientos («insights»): buscamos lograr un entendimiento del por qué de cada evento significativo sucedido en el Sprint, reflexionamos sobre la causa raiz de los mismos previo a pensar una solución. En esta etapa es donde más vemos el rol de coach del Scrum Master (descripto debajo), mediante la indagación buscará generar puntos de vista diferentes a los que tenía el equipo hasta ese momento.

4) Decidir qué hacer: en esta etapa vamos a tener una lista de temas, problemáticas y experimentos potenciales. Es el momento de decidir que hacer con eso. Nos tenemos que enfocar en los items que creemos mas prioritarios y en base a eso definir accionables que podamos ejecutar en el próximo Sprint. La idea es no enfocarse en más de 2 o 3 items como mucho, los equipos que definen muchos accionables rara vez los realizan. Algo útil en esta etapa es sumar esos accionables como items al Product Backlog para tomarlos el próximo Sprint. También suma acordar quién o quienes se llevan cada tema.

5) Cerrar la retrospectiva: Repasamos lo que fue la retrospectiva, revisamos accionables y aprendizajes, conversamos cómo podemos mejorar próximas retrospectivas.

El rol del Scrum Master en la retrospectiva

Roles del Scrum Master en la retrospectiva
Roles principales del Scrum Master (foto de un curso de ITtude)

El rol del Scrum Master es clave en la retrospectiva, vamos a analizarlo en 2 aspectos diferentes:

  • Facilitación: cómo facilitador, el Scrum Master busca que se logre el objetivo de la retrospectiva. Por otro lado, que todas las voces sean escuchadas, que cada uno pueda expresar lo que piensa y siente, esto sabemos que muchas veces es un punto difícil de lograr. En relación a eso hay algo que a mi personalmente me dio muy buenos resultados: una serie de métodos, herramientas y patrones de interacción llamados estructuras liberadoras. Vamos a revisar un ejemplo de estructura liberadora llamada «1-1-2-4-todos»: Comenzamos la retrospectiva dando una consigna al equipo como por ejemplo: «Pensar el mayor impedimento que tuvimos en el Sprint«, esta estructura nos dice que iniciemos la dinámica trabajando la consigna individualmente y tomando notas en post it, luego compartimos las ideas de a pares con un compañero, después compartimos de a 4, y al final con todo el grupo. Este tipo de técnicas permiten generar la apertura necesaria en las personas para que puedan expresar realmente lo que piensan y sienten en ese momento.
  • Coaching: la retrospectiva es uno de los momentos del Sprint en que se ve en mayor medida el rol de coach del Scrum Master. Un coach busca generar reflexión y descubrimiento en un equipo mediante indagación y preguntas poderosas. Un ejemplo sería: mientas se discute un problema de cambios de alcance en el Sprint, se podría explorar el problema con preguntas cómo: ¿Por qué causa creen que cambia el alcance?, ¿En qué momento del Sprint sucede? ¿Qué consecuencias nos trae el cambio de alcance?, ¿Cuál seria la situación ideal hacia donde queremos ir?.

Dinámicas de retrospectiva

Fotos de dinámicas de retrospectiva
Algunos ejemplos de dinámicas

Existen muchas dinámicas con diferentes enfoques que agregan valor a una retrospectiva. Pueden armar sus propias dinámicas (revisando los pasos de una retrospectiva) o también tomar ideas de otras fuentes. Les comparto algunos links útiles con ideas de dinámicas:

Anti-patrones de la retrospectiva

Algunas de las cosas más comunes que NO tienen que suceder en tus retrospectivas:

  • Se buscan culpables: eso genera que no sea un espacio seguro, afecta directamente a la transparencia que vamos a tener en futuras retrospectivas. Si esto sucede nadie va a querer transparentar los problemas.
  • Catarsis sin acciones: es un problema común. Si no definimos accionables nos quedamos sólo en el problema y lo que hicimos mal, en estos casos la retrospectiva no tiene sentido.
  • Accionables no medibles: se definen accionables no medibles cómo por ejemplo: «mejorar la comunicación con el área de ventas» eso podríamos cambiarlo por «coordinemos al menos 2 reuniones con las personas clave del área de ventas en el próximo Sprint».
  • Demasiados accionables: esta demostrado que querer tomar muchos accionables (más de 3 o 4 por ejemplo) provoca que no se haga nada de lo definido o se haga a medias.
  • No hay seguimiento de los accionables: muchos equipos definen accionables pero luego no se siguen o se revisan recién en la siguiente retrospectiva. Una buena práctica es sumar esos accionables al Product Backlog o tenerlos en un lugar visible para revisarlos en la Daily Scrum.

Un patrón muy útil

Hay un patrón muy útil que nos puede ayudar a potenciar los descubrimientos y accionables de nuestras retrospectivas para lograr mejora continua real Scrumming the Scrum:

Identifiquemos el mayor impedimento (1 y sólo 1) en la retrospectiva y agregemoslo al Product Backlog priorizado, con criterios de aceptación claros y con máxima prioridad para tomar el siguiente sprint. Luego evaluaremos su estado en la Sprint Review cómo cualquier otro item de Product Backlog.

Marco Scrum para remover el mayor impedimento detectado en la retrospectiva
Usaremos Scrum Para mejorar Scrum

Eliminar el mayor impedimento va a incrementar considerablemente la velocidad del equipo en el siguiente Sprint. Si bien la velocidad de un Equipo oscilará de Sprint a Sprint, con el tiempo, la velocidad de un Equipo Scrum que funciona bien debería tener una tendencia constante de aumento de un 10% cada Sprint.

Conclusiones

La forma en la que hacemos retrospectivas esta directamente relacionada a los resultados de nuestros equipos. Si la sabemos aprovechar puede pasar de ser sólo un evento más a ser el evento más importante de Scrum y corazón de la mejora contínua del equipo.