Las retrospectivas (o actividades de reflexión en los proyectos) deben ser el motor de la mejora.Espacios donde los equipos identifican problemas reales, se comprometen con cambios específicos y los implementan con resultados medibles. Sin embargo, la mayoría no lo eran (1).
El patrón que observo con más frecuencia es el siguiente: el equipo se reúne, analiza qué salió bien y qué se podría mejorar, genera una lista de acciones a tomar y luego regresa al trabajo. Dos semanas después, se reúnen de nuevo. Las acciones a tomar de la retrospectiva anterior se ignoran, se olvidan o se abordan de pasada antes de que la conversación avance hacia nuevas preocupaciones.
La retrospectiva se ha convertido en teatro, que parece una instancia de reflexión, pero en realidad el equipo no mejora.
El problema no es el formato
Cuando los equipos me dicen que sus retrospectivas no funcionan, la primera pregunta que hago es qué formato usan. ¿Iniciar-Parar-Continuar? ¿Enfadado-Triste-Contento? ¿Velero? Los detalles varían, pero la respuesta casi nunca es la clave.
El problema rara vez reside en la estructura de la conversación. El problema es lo que sucede —o no sucede— una vez terminada la conversación.
Una retrospectiva que no produce seguimiento no es una retrospectiva. Es una sesión de desahogo. Y si bien es valioso dar espacio a las personas para expresar su frustración, desahogarse por sí solo no mejora el rendimiento. Lo que mejora el rendimiento es la acción. Una acción específica, con plazos definidos y recursos asignados, que alguien es responsable de completar.
De la observación al resultado
He trabajado con equipos donde las notas retrospectivas eran exhaustivas, la facilitación, experta, y las observaciones planteadas, precisas. Las retrospectivas seguían fallando. ¿Por qué? Porque la conversación se detenía en la observación.
«La comunicación necesita mejorar». «Necesitamos mejores prácticas de prueba». «La deuda técnica nos está frenando».
Todas estas afirmaciones son ciertas. Además, no son prácticas. La pregunta que distingue una retrospectiva funcional de una ineficaz es simple:
¿Qué acciones específicas y mensurables tomaremos y qué resultados esperamos ver?
Si la respuesta a esa pregunta es vaga, la acción no se llevará a cabo. Si el resultado no está definido, no habrá forma de saber si la acción tuvo algún impacto.
La anatomía de un plan de acción funcional
Cuando ayudo a los equipos a reconstruir su práctica retrospectiva, les pido que estructuren sus planes de acción con cinco elementos. No porque la estructura sea intrínsecamente valiosa, sino porque cada elemento aborda un modo de fallo específico que observo repetidamente.
1. Acción—¿Qué haremos?
2. Resultado— ¿Qué resultado medible esperamos?
3. Responsable—¿Quién es el dueño de esto?
4. Timebox — ¿Cuándo estará listo? ¿Y cuánto esfuerzo requerirá?
5. Recursos— ¿Qué necesita la persona responsable para tener éxito?
Permítanme ilustrarlo con un ejemplo real. Un equipo con el que trabajé identificó que sus tasas de defectos habían aumentado y que las historias tardaban más. Su velocidad se había vuelto impredecible. Tras un debate, concluyeron que los nuevos miembros del equipo tenían dificultades con un componente tecnológico específico. Esto estaba ralentizando el trabajo de todos.
Así es como estructuraron su respuesta:
| Elemento | Detalle |
| Planteamiento del problema | Las tasas de defectos aumentan, las historias toman más tiempo y la velocidad es impredecible debido a que los nuevos miembros tienen dificultades con el <componente tecnológico>. |
| Causa principal | Los nuevos miembros del equipo necesitan un apoyo más estructurado para comprender el componente |
| Impacto esperado | Acortar el proceso de incorporación liberará capacidad y mejorará la productividad |
| Acción | Establecer tareas de seguimiento: solo para tareas que involucren <componente tecnológico>, sesiones con una duración máxima de 4 horas, sin sesiones consecutivas |
| Resultado | Velocidad y calidad constantes en 3 sprints |
| Responsable | Scrum Master incorpora asignaciones durante la planificación; el desarrollador senior toma historias |
| Caja de tiempo | Sesión de seguimiento de 3 horas por cada nuevo miembro del equipo por sprint |
| Recursos | Tiempo del desarrollador senior asignado durante la planificación del sprint |
Observe el contenido de este plan de acción. No se trata de un compromiso vago para “mejorar la incorporación”. Es una intervención concreta con un resultado medible, un responsable designado, un plazo definido y recursos asignados. Tres sprints después, el equipo pudo evaluar si se había recuperado la velocidad constante. De ser así, la acción tuvo éxito. De no ser así, tenían pruebas claras para intentar algo diferente.
La cuestión de los recursos que la mayoría de los equipos pasan por alto
El elemento que más frecuentemente falta en las acciones retrospectivas son los recursos. Los equipos identifican qué necesita cambiar, asignan a alguien para que lo gestione y luego dejan que esa persona averigüe cómo implementarlo, junto con su carga de trabajo actual.
Por eso fracasan tantas acciones. No porque el responsable no esté comprometido, sino porque estaban programadas para fracasar desde el principio.
Si vale la pena comprometerse con una acción, vale la pena asignarle recursos. Esto podría implicar asignar tiempo durante el sprint (suelo usar Scrum Spikes para este propósito). Podría implicar reducir temporalmente la capacidad planificada del equipo para crear espacio para mejoras. Podría implicar incorporar apoyo externo o redistribuir temporalmente otras responsabilidades.
La forma del recurso variará. Lo importante es que la pregunta se formule y responda antes de que finalice la retrospectiva. De lo contrario, se le está pidiendo a alguien que tenga éxito sin darle los medios para lograrlo.
Mejoras a largo plazo
Las retrospectivas que impulsan una mejora real no producen transformaciones drásticas de la noche a la mañana. Producen pequeños ajustes sostenidos que se acumulan con el tiempo. Un equipo que identifica constantemente un problema significativo, se compromete con una acción específica, la cumple con disciplina y evalúa el resultado es un equipo que mejora. Sprint a sprint. Trimestre a trimestre.
Esa disciplina es más difícil de mantener de lo que parece. Requiere una facilitación que sepa cuándo presionar para obtener claridad y cuándo avanzar. Requiere un liderazgo que proteja el tiempo y los recursos necesarios para el trabajo de mejora. Y requiere un equipo que crea que sus retrospectivas realmente importan.
Esa creencia no se inculca con exhortaciones. Se gana con resultados. La primera vez que un equipo observa que una acción retrospectiva produce una mejora medible, algo cambia. Empiezan a tomar el proceso en serio. Y una vez que lo hacen, la retrospectiva se convierte en lo que siempre estuvo destinada a ser: el motor de su mejora.Si bien la estructura descrita aquí es sencilla, transformar las retrospectivas en verdaderos motores de mejora a menudo requiere una perspectiva externa para ver lo que el equipo no puede ver. Ahí es donde el coaching basado en la evidencia acelera el progreso. Contáctanos hoy y transformemos la reflexión en resultados. Descarga mi guía gratuita para Hacer de las retrospectivas el motor de mejora de tu equipo.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
