La reunión que todos fingen valorar
Levanta la mano si esto te suena. Fin de sprint, la retro empieza tarde, alguien abre una plantilla con tres columnas, cada uno suelta dos post-its tibios y a los cuarenta minutos os vais con la sensación de haber cumplido un trámite. Nadie se acuerda de lo que se decidió. Nada cambia. Al sprint siguiente, otra vez.
La retrospectiva es la única ceremonia de Scrum cuyo objetivo explícito es mejorar cómo trabajáis. Si la haces mal, no pierdes solo esa hora: pierdes el mecanismo de corrección del equipo. Los mismos problemas se repiten porque nadie los ataca en serio.
La buena noticia es que arreglarla es barato. No necesitas un facilitador certificado ni una herramienta de pago. Necesitas cambiar tres o cuatro hábitos.
El síntoma: retros que solo describen, nunca deciden
Una retro fallida se reconoce porque produce descripciones y no decisiones. “Hubo muchas interrupciones”, “el despliegue del jueves fue caótico”, “faltó comunicación con producto”. Todo cierto, todo inútil. Son diagnósticos sin tratamiento.
El listón es sencillo: si la reunión termina sin una acción concreta, con dueño y fecha, no ha sido una retrospectiva. Ha sido un desahogo colectivo. Y el desahogo tiene su valor, pero no es lo que vinisteis a hacer.
| Retro de quejas | Retro que funciona |
|---|---|
| ”Deberíamos comunicarnos mejor" | "Rubén publica el estado del despliegue en el canal antes de las 17:00” |
| Veinte post-its, cero prioridad | Una o dos acciones, elegidas por el equipo |
| Se escribe en un tablero que nadie reabre | Se revisa al inicio de la siguiente retro |
| El scrum master toma nota | El dueño de la acción la asume delante de todos |
La diferencia no es de actitud. Es de formato. Un formato que no fuerza decisiones no las produce.
Cambia la pregunta, cambia la reunión
El clásico “qué fue bien, qué fue mal, qué mejorar” tiene un defecto: invita a inventariar sentimientos sobre el sprint. Después de veinte sprints, el equipo se aburre y responde en automático.
Rota el formato. No por moda, sino porque cada uno saca a la luz cosas distintas:
- Timeline. Dibujáis la línea temporal del sprint y marcáis los momentos de tensión o alivio. Saca a relucir problemas que el formato de columnas esconde.
- Barco a vela. Qué nos empuja (viento), qué nos frena (ancla), qué riesgos vemos (rocas). Funciona bien cuando hay tensión y conviene despersonalizar.
- Los cinco porqués. Coges el mayor dolor del sprint y preguntas “por qué” cinco veces seguidas. Casi siempre el problema real está tres niveles por debajo del síntoma.
Si tuviera que quedarme con uno para un equipo que arrastra retros muertas, elegiría los cinco porqués. Obliga a bajar de la queja a la causa, que es donde vive la solución.
Seguridad psicológica: sin esto, no hay retro
Google lo midió en el proyecto Aristotle y la conclusión fue incómoda para quien busca fórmulas: el factor que más distingue a los equipos que funcionan no es el talento individual, es la seguridad psicológica. La sensación de que puedes decir “la metí” sin que te caiga encima.
En una retro esto se nota enseguida. Si nadie menciona el error que todos vieron, no tienes un equipo maduro: tienes un equipo con miedo. Y un equipo con miedo te dará retros de cortesía para siempre.
Un par de hábitos que ayudan más que cualquier discurso. Primero, la regla de oro: se critican decisiones y procesos, nunca personas. “El proceso de review dejó pasar el bug” en lugar de “a Marta se le escapó”. Segundo, quien lidera habla el último y reconoce sus propios fallos primero. Si el más veterano se moja, los demás dejan de tener miedo a mojarse.
Cierra el bucle o no sirve de nada
Aquí es donde se cae el 90 % de los equipos. Generan buenas acciones y luego las abandonan. La retro siguiente empieza de cero, como si el sprint anterior no hubiera existido.
El arreglo es casi vergonzosamente simple: la retro empieza revisando las acciones de la anterior. Cinco minutos. ¿Se hizo? ¿Funcionó? ¿La repetimos o la damos por cerrada? Ese pequeño ritual convierte la retro en un bucle de mejora real en lugar de una serie de reuniones sueltas.
Y trata las acciones como trabajo de verdad. Si acordáis algo que cuesta esfuerzo, entra en el backlog con su tarjeta, no en un post-it que se despega. Aquí va el patrón mínimo que uso, pensado para que nadie pueda escaquearse de la parte que importa:
# Una acción de retro sin dueño ni fecha es una intención, no un compromiso.
from dataclasses import dataclass
from datetime import date
@dataclass
class AccionRetro:
descripcion: str # qué se cambia, en concreto
dueno: str # una sola persona responsable, no "el equipo"
fecha_limite: date # antes de la próxima retro
hecha: bool = False
def es_valida(self) -> bool:
# Si no tiene dueño y fecha, no es accionable: no cuenta.
return bool(self.dueno) and self.fecha_limite is not None
# Se revisa al principio de la siguiente retro, una por una.
acciones = [
AccionRetro("Publicar estado del despliegue antes de las 17:00", "Rubén", date(2026, 7, 22)),
AccionRetro("Reducir el sprint a 8 tarjetas máximo", "Equipo", date(2026, 7, 22)),
]
pendientes = [a for a in acciones if a.es_valida() and not a.hecha]Fíjate en la segunda acción: dueño “Equipo”. Ese es exactamente el olor a acción que no se va a hacer. “Todos” es sinónimo de “nadie”. Si una mejora importa, tiene nombre y apellido detrás.
Menos, pero de verdad
La tentación al final de una retro con energía es salir con seis mejoras. No lo hagas. Un equipo que intenta cambiar seis cosas a la vez no cambia ninguna. Elegid una o dos, las que más duelan, y comprometeos a ellas de verdad hasta la siguiente.
La retrospectiva no es un ritual que se hace porque lo dice el manual. Es el único momento en el que el equipo se detiene a mirarse y decide cambiar algo. Si sale de ahí sin una decisión con dueño y fecha, sobra. Y si sale con ella y la revisáis al empezar la próxima, habréis convertido una reunión que todos fingen valorar en la que más os va a hacer crecer.