Una guía con opinión propia sobre retrospectivas de sprint que mejoran la forma de trabajar del equipo: formatos, disfunciones habituales, facilitación remota y cómo lograr que las acciones se cumplan.
Cada sprint termina igual para miles de equipos de scrum: una reunión llamada retrospectiva a la que todo el mundo asiste, que la mayoría aguanta y de la que pocos esperan que cambie nada. Normalmente el formato está bien y el problema es la facilitación, lo cual es una buena noticia, porque la facilitación se puede corregir.
Las retrospectivas se hacen en equipos de tres personas y de treinta, en persona y en remoto por completo, en startups que lanzan cada semana y en grandes empresas que trabajan con sprints de seis semanas. Las disfunciones se parecen mucho en todas partes, y las soluciones también. Esta guía cubre ambas cosas.
Qué es realmente una retrospectiva de sprint (y qué no es)
La Guía de Scrum define la retrospectiva de sprint como un evento formal al final de cada sprint en el que el equipo se inspecciona a sí mismo y crea un plan de mejoras para el siguiente sprint. En la práctica, es la única reunión de scrum que trata explícitamente sobre cómo trabaja el equipo y no sobre qué construye el equipo.
La mayoría de los equipos subestiman esto. Los post-mortems se hacen después de los desastres, y las sprint reviews miran el resultado del producto. La retrospectiva es el único espacio recurrente para la salud del proceso, así que dejar que degenere en un trámite sale caro.
La investigación Project Aristotle de Google identificó la seguridad psicológica como el factor más importante de la eficacia de un equipo. Las retrospectivas bien llevadas son uno de los pocos rituales de equipo diseñados para construirla, y las mal llevadas la desgastan rápido.
La edición 17 del State of Agile Report de Digital.ai confirmó que scrum sigue siendo el marco ágil dominante en el sector. Muchos equipos hacen retrospectivas, así que facilitarlas bien es una habilidad que vale la pena tener.
La anatomía de una retrospectiva bien estructurada
El libro de Esther Derby y Diana Larsen Agile Retrospectives introdujo la estructura de cinco fases que sigo considerando el estándar de referencia:
- Preparar el escenario
- Recopilar datos
- Generar ideas
- Decidir qué hacer
- Cerrar la retrospectiva
Quienes facilitan se saltan la primera fase más que ninguna otra. Preparar el escenario construye la confianza que hace posible una conversación honesta, así que es algo más que un calentamiento. Una simple pregunta para acordar normas de trabajo o un check-in de una palabra lleva cinco minutos y cambia la sala.
La Guía de Scrum recomienda un máximo de tres horas para un sprint de un mes, y proporcionalmente menos para sprints más cortos. Mi regla general es reservar al menos el 20% de la retro para definir las acciones y sus responsables. Muchos equipos dedican la mayor parte de la sesión a recopilar datos y luego van con prisa con los compromisos, que es justo al revés. Una idea sin compromiso es solo desahogo.
Quien facilita no debería ser el responsable jerárquico del equipo. Un desequilibrio de poder percibido frena el feedback sincero; cualquiera que haya vivido una retro en la que el engineering manager también dirige el ejercicio de notas adhesivas lo reconocerá. Es parte de la razón por la que existe el rol de Scrum Master.
Formatos de retrospectiva populares y cuándo usar cada uno
Start / Stop / Continue
La mayoría de los equipos empiezan aquí, y con razón: tres columnas, preguntas claras, rápido de explicar y rápido de hacer.
Su punto débil es un resultado superficial. Los equipos enumeran los mismos elementos sprint tras sprint sin preguntarse por qué algo sigue volviendo. Si usas Start/Stop/Continue, combina el elemento «Stop» más votado con un ejercicio de los 5 porqués. Ese único añadido convierte un generador de listas en una herramienta de diagnóstico.
Las 4Ls: Liked, Learned, Lacked, Longed For
Introducidas por Mary Gorman y Ellen Gottesdiener, las 4Ls (lo que nos gustó, lo que aprendimos, lo que faltó y lo que echamos de menos) funcionan especialmente bien después de un lanzamiento o un hito importante. Mezclan la reflexión emocional con la revisión analítica de una forma que Start/Stop/Continue no logra, y «Longed For» saca a la luz aspiraciones que los formatos centrados en el proceso tienden a enterrar.
Las uso cuando un equipo acaba de entregar algo significativo y necesita procesar lo que salió bien y lo que se echó en falta, en lugar de revisar el sprint de forma mecánica.
Mad / Sad / Glad
Mad/Sad/Glad (enfadado, triste, contento) es abiertamente emocional. Esa es su fortaleza, y la razón por la que algunos equipos se resisten a él.
Imagina un equipo distribuido que pasa de Start/Stop/Continue a Mad/Sad/Glad después de seis meses y enseguida saca a la luz un problema de moral en torno a la rotación de guardias que el formato analítico pasaba por alto una y otra vez. El enfoque emocional da permiso a las personas para nombrar algo que parecía demasiado personal para una discusión sobre procesos.
Úsalo cuando sospeches que hay un problema de moral o de salud del equipo que tu formato actual no está sacando a la luz.
El velero
Adaptado del juego Speed Boat de los Innovation Games de Luke Hohmann, el velero usa una metáfora visual: el viento impulsa al equipo, las anclas lo frenan y las rocas son los riesgos que hay por delante. Una imagen espacial provoca un pensamiento distinto al de una columna de texto.
Funciona especialmente bien en equipos remotos que usan Miro o FigJam, donde el lienzo permite a los miembros más callados del equipo contribuir de forma asíncrona antes de la sesión en directo. Llenar el tablero antes de la llamada es la mitad del valor.
Cómo gestionar las retrospectivas disfuncionales
Hay tres disfunciones que aparecen una y otra vez, y cada una necesita una respuesta distinta.
Los mismos problemas reaparecen una y otra vez
Esto es indefensión aprendida: el equipo ya no cree que la ceremonia lleve a ningún cambio, así que cumple con el trámite. Una actividad nueva no lo arreglará; una auditoría sí. Recupera las acciones de los últimos cinco sprints, clasifícalas delante del equipo en completadas, bloqueadas o abandonadas, y descarta explícitamente aquellas sobre las que el equipo no tiene capacidad de influir. El trabajo de Patrick Lencioni sobre las disfunciones de los equipos trata este tipo de erosión de la confianza como algo fundamental, y no se puede construir nada útil encima hasta que se aborde directamente.
Una o dos voces dominan
La solución más fiable es la lluvia de ideas en silencio antes de compartir en grupo: cada persona escribe por su cuenta antes de que nadie hable. Herramientas como EasyRetro permiten la votación digital anónima, que quita el componente personal a la hora de ordenar las ideas y da el mismo peso a los miembros más callados del equipo. La investigación en psicología social sobre el bloqueo de producción apunta en la misma dirección: escuchar hablar a los demás frena tu propia generación de ideas. Así que primero escribe y después comparte.
En la práctica, la gente habla menos cuando hacerlo parece socialmente arriesgado. Un ingeniero sénior que domina la retro está reduciendo la capacidad del equipo para mejorar por sí mismo, lo que es un problema mayor que resultar molesto.
Retros que se convierten en sesiones de quejas
El desahogo tiene su lugar en una retrospectiva, pero no en la fase de acciones. Cuando una retro se convierte en pura queja, redirígela con una pregunta concreta: «¿Qué es una cosa que nosotros podemos cambiar en las próximas dos semanas que mejoraría esto?». Limitar la pregunta a lo que el equipo controla y a un plazo corto corta el desahogo y orienta al grupo hacia algo sobre lo que puede actuar.
Retrospectivas remotas e híbridas
Las retros remotas fallan de formas previsibles: fatiga de cámara, preparación que nadie hace y una brecha de participación para quienes se sienten menos cómodos con las herramientas digitales. Las buenas personas facilitadoras en remoto se ocupan de las tres antes de que empiece la sesión.
Una de las prácticas más eficaces es dividir la retro en una fase previa asíncrona (24 horas antes de la llamada) y una fase de síntesis síncrona. Herramientas como Miro y FigJam lo permiten de forma nativa. Los miembros del equipo rellenan un tablero digital antes de la sesión en directo, así que no tienen que generar ideas bajo presión social en tiempo real. La sesión en directo se concentra entonces en agrupar, discutir y decidir.
El manual de trabajo remoto de GitLab sitúa la comunicación asíncrona primero en el centro de cómo funciona una empresa totalmente remota. Es una de las referencias reales más detalladas sobre la práctica ágil en remoto.
Las retrospectivas híbridas son más difíciles que las totalmente remotas. Cuando algunas personas comparten sala y otras están en una pantalla, quienes están en la sala se convierten en un subequipo. La solución es que todo el mundo se conecte desde su propio dispositivo, aunque estén sentados en la misma oficina. Eso pone a todo el mundo en igualdad de condiciones y elimina la ventaja de estar en la sala.
Cómo lograr que las acciones se cumplan de verdad
Aquí es donde fallan la mayoría de las retrospectivas, sea cual sea el formato que hayas elegido.
Cada acción necesita tres cosas: una persona responsable con nombre (no «el equipo»), una definición de terminado y un lugar en el Sprint Backlog. Una acción que no entra en el trabajo del siguiente sprint, en la práctica, no existe.
Limítate a entre una y tres acciones por sprint. En la práctica, los equipos que producen ocho acciones rara vez terminan alguna, y los equipos que se comprometen con dos suelen completar ambas.
Sé concreto. Las personas que deciden de antemano cuándo, dónde y cómo van a actuar sobre un objetivo tienden a cumplirlo con más frecuencia que quienes solo declaran una intención. «Mejoraremos nuestro proceso de revisión de PR» no es una acción. «Antes de que termine el Sprint 14, Priya añadirá una checklist de PR a la página de Confluence del equipo y la usaremos en las próximas tres revisiones» sí lo es.
Un backlog de la retro visible (una etiqueta o épica dedicada en Jira, Linear o Azure DevOps) muestra los compromisos abiertos de la retrospectiva junto al trabajo del sprint, sin reuniones adicionales. Una forma fiable de salir de las «retros zombi» es un primer punto fijo en la agenda: revisar las acciones de la retro del sprint anterior con un estado rojo/ámbar/verde antes de generar otras nuevas. Ese único cambio estructural a menudo devuelve al equipo la confianza en la ceremonia.
Tu primera retrospectiva mejorada
La retrospectiva es la vía más directa del equipo para mejorar su forma de trabajar. Bien hecha, es la ceremonia más valiosa de scrum; mal hecha, la más desmoralizadora.
Hacer retros excelentes es una habilidad que lleva tiempo. Quien facilita retros excelentes en su tercer año llegó ahí gracias a lo que aprendió en el primero y el segundo, no por encontrar el formato perfecto el primer día.
Así que elige un formato de esta guía y úsalo en tu próximo sprint. Si tu equipo lleva seis meses atascado en Start/Stop/Continue, prueba Mad/Sad/Glad. Si trabajas en remoto y te saltas la fase previa asíncrona, añádela. Si tus acciones siguen muriendo sin responsable, introduce el backlog de la retro.
Después vuelve y cuéntanos en los comentarios qué pasó. Los detalles concretos son bienvenidos.
Para los equipos que quieran ir más allá, los recursos sobre retrospectivas de Workshop Weaver cubren técnicas de facilitación para una gran variedad de equipos, desde squads recién formados que hacen su primera retro hasta equipos con experiencia que intentan romper patrones que dejaron de funcionar hace meses.
💡 Consejo: Prueba Workshop Weaver gratis durante 7 días. Sin tarjeta de crédito.
Iniciar prueba gratuita