La Retrospectiva (Sprint Retrospective) es intocable, es el evento de máxima importancia para muchos Scrum Team por su especial relevancia. Sin embargo, me encuentro equipos que entienden la Retrospectiva como una pérdida de tiempo sobre todo cuando los tiempos aprietan y piensan que, mientras “hablamos”, no estamos desarrollando nuestro proyecto o producto. ¿Para qué sirve la Retrospectiva?
Definición formal
Estudiemos la definición actual que nos da la Scrum Guide 2020 sobre la retrospectiva:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
Es decir, el objetivo de este espacio es mejorar la calidad (por eso se repasa o se actualiza la Definition of Done) y ser más efectivos. La efectividad la podemos entender como hacer las cosas correctas de la manera correcta (doing the right things right). En el contexto de Scrum, este Sprint puede llevarnos a entregar más valor.
La segunda parte de la definición, se centra en el cómo debemos enfocarnos:
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
Es decir, inspeccionamos a las personas, sus interacciones y cómo hemos trabajado, las herramienta, procesos, DOD etc. Con ello, debatimos sobre lo que nos ha funcionado y lo que es susceptible de mejorarse.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Por último, Scrum nos da pistas sobre cómo mejorar esa efectividad. Deberíamos sacar un plan de acción que implante mejoras. Es más, podrían ser añadidas al Sprint Backlog como parte del trabajo que vamos a realizar en las próximas semanas.
¿Puede un equipo negarse a hacer la retrospectiva?
Hay equipos que se ven “maduros” o, desde luego, con una confianza elevada para no necesitar un espacio para mejorar. Al final, cada minuto que destinamos a programar, nos acerca a los objetivos que nos hayamos marcado. Por tanto, reuniones de “mejorar” se ven ineficientes o inútiles. Los motivos pueden ser varios:
- No necesitamos tantas horas para hablar
- Las mejoras dependen de personas ajenas al equipo
- Siempre hablamos los mismos temas y nunca sacamos acciones
- El facilitador se centra más en dinámicas chorra que en hacer útil la sesión
Sin embargo, cuesta mucho negarse a participar en una retrospectiva, entre otras cosas porque es la reunión de “mejoras”. Decir abiertamente que estamos en contra de la reunión de mejoras, suena a que no queremos mejorar, de alguna manera estamos diciendo que somos perfectos y no es el mensaje que queremos lanzar.
Además, en Scrum hablamos de equipos autogestionados, por tanto, ¿debería un equipo decidir qué partes de Scrum hace? Es más, ¿debería un equipo autogestionado plantearse si puede rechazar Scrum?
El equipo que no mide, el equipo que no lo entiende
Debemos recordar que ninguna empresa tiene como objetivo “hacer Scrum” o “ser Agile”. Sin embargo, muchas (o casi todas) deben o deberían tener como objetivo mejorar su capacidad de entregar valor. Entregar valor, cuando vives en un entorno complejo, requiere de métodos, marcos y procesos que conviven con dicho entorno. Es decir, una aproximación predictiva suele ser poco recomendable cuando la probabilidad de que ocurra es baja.
Por tanto, si extendemos esta necesidad de entregar valor a los equipos, estos deben autogestionarse buscándolo. Si un equipo busca esa entrega de valor, Scrum empieza a tener sentido como marco de trabajo. La retrospectiva es un elemento de Scrum que, precisamente, se debe centrar en dicha entrega de valor. Sí, inspeccionamos a las personas y sus relaciones, por encima del producto (que ya lo inspeccionamos en la Sprint Review). Ahora bien, cuando se habla de un plan de mejoras, se habla de activar cambios que nos permitan entregar más valor como equipo.
Es decir, la retrospectiva sólo tiene sentido cuando medimos valor. Sin esa métrica, es complicado saber sí un equipo está trabajando mejor. De hecho, muchos equipos se definen como “alto rendimiento” sin medir dicho rendimiento en términos de negocio o valor entregado a clientes.
Valor, valor… y valor
Prácticamente cualquier elemento de Scrum está pensando en dicha entrega de valor. Por ejemplo, el Sprint Goal puede parecer absurdo: ¿Para qué tener un solo objetivo si el negocio nos está pidiendo varias cosas urgentes? Sin embargo, cuando tu foco es la entrega de valor, la pregunta puede ser: “podemos hacer muchas cosas para entregar valor, pero como no decidamos una sola y la entreguemos, acabaremos haciendo muchas cosas a la vez sin entregar nada” ¡Por eso existe el Sprint Goal!
Todo Scrum gira en torno a ello y, por eso, debemos tener muy presentes dos retos iniciales que tienen todos los equipos: entregar y medir valor. La entrega es clave: sin entrega, no podemos validar que generamos valor, ya que el valor lo definen los destinatarios de nuestro producto ¡Los que pagarán por él!
Por otro lado, definir “valor” en nuestro equipo es necesario, para saber si las decisiones que tomamos son acertadas o incorrectas, más allá de nuestras sensaciones. Es verdad que todo no puede ser un número pero no podemos vivir de espaldas a las métricas.
Y tú, ¿haces la retrospectiva orientada a valor?
