Acciones de retrospectiva que no se pierden
La mayoría de las retros terminan con buenas intenciones y sin seguimiento. Por qué las acciones se pierden, qué dice la investigación, y cómo mantener cada una con dueño y fecha.
Una retrospectiva solo vale el tiempo invertido si algo cambia después, y lo que suele fallar no es la discusión, es el seguimiento. Los equipos salen con una lista de buenas intenciones, la lista vive en algún lugar que nadie revisa, y la mayor parte desaparece silenciosamente antes del siguiente sprint. La solución no es una mejor reunión, es convertir cada mejora en una única acción rastreada con un dueño y una fecha límite, y empezar la próxima retro revisando la anterior. A continuación: por qué se pierden las acciones, qué dice la evidencia, y una forma simple de hacer que se cumplan.
Por qué se pierden las acciones de retrospectiva
Tres modos de fallo aparecen una y otra vez:
- Viven en el lugar equivocado. Una pizarra es genial durante la reunión e inútil una semana después. Si la acción no está donde el equipo trabaja cada día, queda fuera de vista.
- Volver a escribirlas es una molestia, así que se omite. Cuando alguien tiene que copiar las acciones de la retro a una herramienta de tareas a mano, ese paso es el primero en descartarse en una semana ocupada.
- Nadie es dueño de ellas. "Deberíamos mejorar las revisiones de código" es un deseo. "Ana propondrá una ventana de revisión para el viernes" es una acción. Sin un nombre y una fecha, nadie es responsable.
Qué dice la investigación
Vale la pena conocer dos hallazgos de la investigación, porque apuntan directamente a la solución.
La seguridad va antes que la honestidad. Décadas de investigación sobre equipos muestran que la seguridad psicológica, la creencia compartida de que el equipo es un lugar seguro para asumir riesgos interpersonales, es lo que permite a las personas plantear problemas y aprender, en vez de quedarse calladas para no quedar mal. En un estudio fundacional con 51 equipos, la seguridad psicológica predijo el comportamiento de aprendizaje, que a su vez predijo el desempeño (Edmondson, 1999). Una retrospectiva solo saca a la luz problemas reales si las personas se sienten lo bastante seguras para nombrarlos, así que el formato tiene que proteger eso.
Los dueños y las fechas están fuertemente ligados al cumplimiento. Los datos rigurosos y revisados por pares sobre la finalización de acciones son escasos, pero las cifras disponibles apuntan todas en la misma dirección. En una encuesta a profesionales ágiles, casi todos creaban acciones, pero solo una pequeña minoría siempre les asignaba una fecha límite. Los datos reportados por proveedores de herramientas de retro son una asociación, no una prueba, pero son consistentes: las tasas de finalización aumentan notablemente cuando un ítem tiene tanto un dueño nombrado como una fecha límite. (Referencias en Fuentes, más abajo.)
La lectura práctica: haz que sea seguro ser honesto, y luego haz que cada acción sea concreta y tenga dueño.
Haz que sea seguro ser honesto
La forma más rápida de perder valor es que las personas escriban lo cómodo en vez de lo verdadero. Un hábito simple de formato ayuda: mantén las notas de cada persona ocultas hasta que todos hayan agregado las suyas, y luego revélenlas juntos. Cuando las notas permanecen privadas primero, las personas escriben lo que realmente piensan en vez de reaccionar a lo que ya está en el tablero. Es la misma idea anti-anclaje detrás de la revelación simultánea en el planning poker: primero el aporte independiente, después la discusión.
El tablero de tres zonas
Mantén la estructura simple e igual cada vez: Lo que salió bien, Por mejorar y Acciones. Deja que las personas agreguen notas a lo largo del sprint, no solo en la reunión, para que los momentos importantes se capturen cuando ocurren en vez de recordarse a medias al final.
Dos hábitos agudizan la discusión:
- Revelen las notas juntos, como se mencionó, para que nadie se ancle en el primer comentario.
- Conecten cada mejora con su acción. Tracen el vínculo entre el problema en "Por mejorar" y el ítem concreto en "Acciones", para que el "por qué" quede unido al "qué".
Convierte las mejoras en acciones reales
Cuando termina la retro, cada nota en Acciones debería convertirse en un ítem rastreado con tres cosas:
| Toda acción necesita | Ejemplo |
|---|---|
| Un dueño (un nombre, no "el equipo") | Ana |
| Una fecha límite | para el viernes |
| Un estado (abierta, en curso, hecha) | abierta |
Mantenla en un solo lugar, junto a la retro de la que surgió, con un conteo visible de lo que sigue abierto y lo que está vencido. El objetivo es que no haya nada que copiar a otra herramienta, porque ese paso de copiar es justamente donde las acciones suelen perderse.
Empieza la próxima retro con la anterior
Antes de recoger notas nuevas, dedica dos minutos a las acciones de la vez anterior. ¿Cuáles están hechas? ¿Cuáles están estancadas, y por qué? Los equipos que hacen esto notan algo rápidamente: las acciones se vuelven menos, más pequeñas y más específicas, y las retros dejan de repetir las mismas quejas.
Una acción con dueño y fecha vale más que cinco buenas intenciones.
Lista de verificación rápida
- Agreguen notas durante el sprint, no solo en la reunión.
- Revelen las notas juntos, luego discutan.
- Conviertan cada mejora en una acción concreta.
- Asignen a cada acción un dueño y una fecha límite.
- Abran la próxima retro con el estado de la anterior.
Preguntas frecuentes
¿Por qué nunca se completan las acciones de la retrospectiva?
Generalmente porque viven en algún lugar que nadie revisa, hay que volver a escribirlas en otra herramienta, o ninguna persona en particular es dueña de ellas. Mantener cada acción en un solo lugar, con un dueño y una fecha límite, elimina los tres puntos de fallo.
¿Cuántas acciones debería producir una retro?
Menos es mejor. Una o dos acciones concretas y con dueño que realmente se cumplan valen más que una lista larga de buenas intenciones. Si el equipo sigue generando más de las que puede terminar, limítalas y lleva el resto solo si todavía importa.
¿Quién es dueño de una acción de retrospectiva?
Una persona nombrada, nunca "el equipo". El dueño no tiene que hacer todo el trabajo, pero es responsable de que avance. La propiedad compartida suele significar ninguna propiedad.
¿Cómo se logra que las retrospectivas se sientan seguras?
Deja que las personas agreguen y revelen notas sin sentirse observadas, mantén la misma estructura simple cada vez, y enfócate en el proceso en vez de culpar a individuos. La investigación vincula este tipo de seguridad psicológica con equipos que aprenden y mejoran.
¿Qué hacer con las acciones sin terminar?
Empieza la siguiente retrospectiva revisándolas. Cierra lo que está hecho, y para lo que está estancado, pregunta por qué antes de arrastrarlo. Si un ítem sigue retrasándose y ya no importa, descártalo con honestidad en vez de dejarlo pendiente indefinidamente.
¿Cuáles son las tres columnas de una retrospectiva?
Un formato común y simple es Lo que salió bien, Por mejorar y Acciones. Las dos primeras enmarcan la discusión, y la tercera es donde las mejoras se convierten en compromisos concretos y con dueño.
Fuentes
- Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350-383 (la seguridad psicológica predice el aprendizaje del equipo, que a su vez predice el desempeño; estudio con 51 equipos).
- Dingsøyr, T. et al. (2018). Learning in the Large: an Exploratory Study of Retrospectives in Large-Scale Agile Development. XP 2018, LNBIP 314 (estudio de caso longitudinal; la mayoría de los problemas planteados se relacionan con el aprendizaje y la mejora del equipo).
- Datos de profesionales y proveedores sobre la finalización de acciones (encuesta a profesionales de Retrium; cifras de finalización de herramientas de retro): los dueños nombrados y las fechas límite están consistentemente asociados con una finalización mucho mayor. Tratar como asociación, no como prueba.
Sigue leyendo
Técnicas de estimación ágil comparadas
Planning poker, tamaños de camiseta, el sistema de baldes y la estimación por afinidad comparados: qué dice la investigación y cómo elegir la correcta.
Leer más →Cómo sincronizar story points con Jira
Conecta Jira con planning poker, elige el campo correcto (Story Points o Story point estimate) y resuelve estimaciones que no se sincronizan. Una guía de configuración.
Leer más →