La retrospectiva que por fin funcionó: el giro de un equipo
La Retrospectiva del Sprint es el único evento de Scrum cuyo propósito entero es mejorar al equipo. La Guía Scrum es clara: el equipo examina cómo fue el último Sprint e identifica mejoras para aplicar en el siguiente. Sin embargo, muchos equipos la convierten en una ronda de agradecimientos seguida de una lista prolija que nadie vuelve a abrir. Aquí va la historia anonimizada de un equipo de entrega híbrido, recuperándose a comienzos de 2021 entre el trabajo remoto y las interrupciones de suministro aún recientes, cuyas retrospectivas por fin empezaron a cambiar algo.
Qué estaba fallando
El equipo —llamémoslo la cuadrilla del Puerto— hacía una retrospectiva cada Sprint, puntual, durante la hora completa. La gente asistía, casi siempre con la cámara encendida, y decía cosas razonables. El Scrum Master agrupaba las notas en tres columnas: salió bien, salió mal, ideas. El tablero se llenaba. Y nada se movía. La misma queja sobre entornos de prueba inestables apareció en cuatro retrospectivas seguidas. Nadie la asumía, nadie la resolvía y, con el tiempo, el equipo dejó de plantearla, porque plantearla se había vuelto un ritual sin consecuencias.
El problema de fondo no era el formato. Era que la retrospectiva producía conversación, no compromisos. Las mejoras quedaban como observaciones flotando en el aire, no como trabajo que alguien se hubiera comprometido a hacer.
Los tres cambios que importaron
Una mejora, en el Backlog. En vez de una lista de deseos, el equipo salía de cada retrospectiva con exactamente una mejora que de verdad pensaba realizar en el siguiente Sprint, y la añadía al Backlog del Sprint como un elemento real con un responsable. La Guía Scrum lo permite de forma explícita: la mejora de mayor impacto se aborda cuanto antes. Ponerla en el Backlog hacía que compitiera por capacidad como cualquier otro trabajo, en lugar de ser un consejo gratuito.
Empezar por los datos, no por las sensaciones. Antes de las opiniones, el Scrum Master dedicaba cinco minutos a los hechos del Sprint: cuántos elementos se arrastraron, dónde se disparó el tiempo de ciclo, qué entorno falló y cuándo. Anclar la conversación en evidencia evitaba que derivara hacia la teoría favorita del más ruidoso y sacaba a la luz el problema del entorno de prueba como un costo medible y recurrente, no una queja vaga.
Revisar primero la vez anterior. Cada retrospectiva abría ahora repasando la única mejora del Sprint anterior. ¿La hicimos? ¿Ayudó? Ese solo hábito creó responsabilidad. Una mejora que reaparece una y otra vez sin tocarse deja de ser fácil de ignorar cuando lo primero que haces es leerla en voz alta.
Para un equipo distribuido, la mecánica también importaba. Usaban un tablero en línea compartido para que los miembros remotos y de oficina tuvieran igual voz, daban a cada uno unos minutos en silencio para escribir antes de hablar, y rotaban la facilitación para que no fuera siempre la misma persona al mando. Nada exótico. Es solo la diferencia entre una reunión que finge mejorar y otra que mejora de verdad.
Qué cambió tres meses después
El entorno de prueba inestable se arregló, porque por fin se convirtió en un elemento del Backlog, con responsable y un Sprint en el que vivir. Más importante aún, el equipo aprendió que una retrospectiva no es una sesión de desahogo ni un informe de estado. Es un pequeño acto deliberado de cambiar cómo se trabaja, una mejora a la vez, con la disciplina de comprobar si de verdad cuajó. Apunta a un cambio real por Sprint que lleves hasta el final, y superarás a cualquier equipo que persiga diez que se evaporan.
Sal con una mejora, no con diez.
Conviértela en un elemento del Backlog con responsable, no en una nota adhesiva.
Abre la siguiente retrospectiva comprobando si funcionó.
Si tus equipos hacen retrospectivas que nunca cambian nada, la asesoría en entrega de programas y proyectos de XNM puede ayudarte a construir hábitos de entrega que de verdad perduren.