Retrospectivas de sprint que de verdad cambian algo
Si la retro de tu equipo produce las mismas quejas sprint tras sprint, no tienes una retrospectiva — tienes una sesión de desahogo. He estado en cientos. El patrón se repite: pósits, agrupar temas, votar, diez minutos de debate y luego no pasa nada. Dos semanas después, los mismos problemas vuelven a aparecer. El equipo deja de creer que la retro sirva para algo y, tarde o temprano, alguien propone cancelarla.
La retro es la ceremonia más valiosa de cualquier proceso ágil. Es la única reunión diseñada explícitamente para que el equipo se mejore a sí mismo. Cuando funciona, el efecto se acumula: pequeñas mejoras en cada sprint que, trimestre a trimestre, dan un equipo fundamentalmente mejor. Cuando falla, el equipo se estanca.
Por qué fallan la mayoría de las retros
Nadie ejecuta las acciones acordadas. El asesino número uno. El equipo acuerda una acción, nadie se hace cargo y, para la siguiente retro, ya está olvidada. Tres ciclos así y el equipo aprende la lección: los compromisos de la retro no valen nada.
Quedarse en el síntoma. "Los despliegues son lentos" aparece en un pósit. El equipo acuerda que "habría que desplegar más rápido" y pasa al siguiente tema. Pero ¿el pipeline de CI está sobrecargado? ¿Hay un paso de aprobación manual? ¿Los tests son inestables? Sin escarbar más, la acción queda vaga y nadie sabe qué hacer con ella.
Dominan las voces más fuertes. Dos o tres personas acaparan el 80% de la conversación. Los ingenieros más callados — a menudo los de las observaciones más afiladas — no dicen nada, porque el formato no les hace hueco.
El mismo formato una y otra vez. "Qué fue bien / qué fue mal / qué mejorar" sirve para las primeras retros. A los seis meses está agotado. Y el aburrimiento mata la participación.
Los 5 porqués: llegar a la causa raíz
La técnica de retro más potente son los 5 porqués — nació en Toyota, pero se traslada perfectamente a los equipos de software. Cuando alguien plantea un problema, sigue preguntando "¿por qué?" hasta dar con la causa raíz.
Ejemplo:
- "El miércoles tuvimos una caída en producción." — ¿Por qué?
- "Una migración de base de datos se ejecutó en plena hora punta de tráfico." — ¿Por qué?
- "No teníamos ninguna política sobre cuándo ejecutar migraciones." — ¿Por qué?
- "Nadie se lo había planteado — el tráfico nunca había sido tan alto como para que importara." — ¿Por qué?
- "No tenemos una lista de comprobación previa al despliegue." — Causa raíz.
La acción no es "no ejecutar migraciones en hora punta". Eso es un parche. La acción es "crear una lista de comprobación previa al despliegue". Eso es arreglar el sistema.
Un formato que funciona
Paso 1: repasar las acciones del sprint anterior (5 minutos)
Empieza cada retro repasando las acciones de la anterior. ¿Las hicimos? Si no, ¿por qué? Este paso, por sí solo, crea responsabilidad y deja claro que los compromisos van en serio. La regla: toda acción no completada se vuelve a comprometer con un responsable claro o se descarta explícitamente. Nada se arrastra más de dos sprints.
Paso 2: lluvia de ideas en silencio (5 minutos)
Cada uno escribe sus observaciones por su cuenta. Sin hablar. El silencio evita el efecto ancla: que quien habla primero marque el encuadre de toda la conversación. Rota las preguntas para que no se gasten:
- "¿Qué deberíamos empezar a hacer, dejar de hacer y seguir haciendo?"
- "¿Dónde nos sentimos bloqueados? ¿Dónde fluimos?"
- "Si pudiéramos cambiar una sola cosa de cómo trabajamos, ¿cuál sería?"
Paso 3: agrupar y votar (5 minutos)
Agrupa las observaciones por temas. Vota con puntos. Quédate con los 2-3 temas principales — ni 5 ni 7. Querer cubrirlo todo es la forma más segura de no cubrir nada bien.
Paso 4: profundizar con los 5 porqués (15 minutos)
Para cada tema, una discusión estructurada. El facilitador insiste con el "¿por qué?" y corta las culpas y las tangentes. Regla de juego: no se señala a personas. "El proceso de despliegue es lento" vale. "Juan retrasa las revisiones de código" no.
Paso 5: comprometerse con las acciones (10 minutos)
Cada acción debe tener:
- Un responsable. Una persona concreta, no "el equipo".
- Una definición de terminado. No "mejorar los despliegues", sino "añadir una etapa de tests en paralelo para dejar el pipeline por debajo de 10 minutos".
- Una fecha límite. Normalmente, "antes de la próxima retro".
Limítate a 2-3 acciones. Dos acciones completadas por sprint valen más que cinco abandonadas.
Rota el facilitador, o la dinámica se anquilosa
No dejes que la misma persona dirija todas las retros. Cuando el tech lead facilita siempre, la dinámica se anquilosa. Rota el rol por todo el equipo — sí, también entre los ingenieros más callados. Dales una guía sencilla: el formato de arriba, los tiempos de cada paso y un par de opciones de preguntas. La mayoría de la gente facilita mejor de lo que cree.
El trabajo del facilitador: controlar el tiempo. Asegurarse de que todo el mundo habla. Preguntar "¿por qué?" cuando el grupo se queda en el síntoma. Anotar las acciones con responsable y fecha.
La responsabilidad se juega entre retro y retro
La retro dura 40 minutos. Lo que hace que esos minutos cuenten es el sistema de seguimiento que hay alrededor.
Haz visibles las acciones. Ponlas en el tablero del equipo, junto al trabajo normal. Si usáis Jira o Linear, las acciones de retro son tickets del sprint en curso. Mejorar el proceso no es un extra voluntario — es trabajo, sin más.
Revisa a mitad de sprint. Una mención de dos minutos en la standup: "Repaso rápido — Sara, ¿cómo va la mejora del pipeline de CI?" Es la señal de que los compromisos del equipo consigo mismo importan.
Mide la tasa de cumplimiento. Si tu equipo completa el 80% de las acciones de retro, el proceso funciona. Por debajo del 50%, las acciones son demasiado ambiciosas, demasiado vagas o no están priorizadas.
Cuando la confianza está tocada
Si tu equipo lleva meses soportando retros que no sirven para nada, pensará que todo esto es una pérdida de tiempo. Y, francamente, tiene razón: una retro que nunca cambia nada es puro coste, y cancelarla es la respuesta racional. Ese argumento no se gana con palabras — la confianza se reconstruye con victorias rápidas. Elige un problema pequeño y concreto que el equipo pueda arreglar dentro del mismo sprint. "A nuestra plantilla de PR le falta la sección de plan de pruebas." Arréglalo. Enseña el resultado en la siguiente retro. Tres sprints de acciones completadas y la confianza vuelve. Y esa confianza lo es todo.
En Conectia, los ingenieros senior que incorporamos a los equipos de nuestros clientes llegan con la experiencia de varios equipos de alto rendimiento. Cuando un ingeniero ha visto el mismo cuello de botella de despliegue resuelto de tres formas distintas en tres empresas distintas, su aportación en la retro vale más que otra ronda de lluvia de ideas desde cero.
¿Necesitas ingenieros que aporten madurez de proceso además de nivel técnico? Habla con un CTO — nuestros ingenieros senior de LATAM refuerzan tanto tu código como tus prácticas de ingeniería.
