El modo de fracaso más letal no es una ceremonia deficiente. Es una ceremonia acertada que no cambia nada.

Se puede grabar una reunión de pie, se puede sobrecargar una sesión de planificación, y el equipo seguirá sintiendo la fricción y la resistencia. La falta de seguimiento es aún peor porque da la sensación de que todo va bien. Se celebra la retrospectiva, la gente es sincera, se escriben notas adhesivas, todos asienten con la cabeza… y luego comienza el nuevo sprint y nada cambia. Si esto se repite unas cuantas veces, no se genera enfado, sino algo más silencioso y más corrosivo. Como señaló un ingeniero en Hacker News: «Las retrospectivas permiten expresar preocupaciones, pero, según mi experiencia, nunca se hace nada al respecto». Otro, sin rodeos: «Nunca he visto que ocurra nada más allá de las palabras». Esta es la queja más repetida sobre las retrospectivas en cualquier contexto, y no es la queja que los consejos de nuestro sector creen que es.

Palabras, y solo palabras

La visión habitual es que los equipos «se olvidan de redactar las medidas a tomar», por lo que la solución habitual consiste en redactarlas mejor: hacer que cumplan los criterios SMART, asignar un responsable y añadirlas al tablero. Sin embargo, esto pasa por alto la verdadera causa del problema. El problema rara vez es que no se haya redactado ninguna acción; es que la acción se redactó, se añadió a la lista de tareas pendientes y luego se quedó ahí para siempre, mientras que la siguiente retrospectiva generó tres más. «He repetido los mismos puntos de la retrospectiva de sprint tras sprint sin que se hayan abordado», reza un relato resignado. «Esta nota adhesiva no se va a abordar. Es un poco triste». Según una encuesta muy citada, solo alrededor de un tercio de los equipos completan de forma sistemática sus acciones de la retrospectiva, y los otros dos tercios están aprendiendo, sprint tras sprint, que la ceremonia solo genera palabras y nada más que palabras. No obstante, hay que tomar estas creencias populares con cautela: nuestros propios datos primarios sobre qué porcentaje de acciones de la retrospectiva se llevan realmente a cabo sitúan la tasa de cumplimiento más cerca de tres de cada cuatro, y muestran que son la implicación y la cadencia, y no el esfuerzo, las que determinan la diferencia.

La solución que realmente funciona no consiste en más acciones, sino en menos. Limítese a una sola. Una única mejora con la que el equipo se comprometa de verdad, que se revise al principio de la próxima retrospectiva antes de que ocurra nada más, es mejor que una lista de diez que acaben quedando en el olvido. Si se establecen demasiadas medidas, la mitad no se llevará a cabo —y esa mitad que no se lleva a cabo enseña al equipo que nada de ello cuenta. Un único punto, asignado a alguien y con una fecha de revisión, cierra el círculo que una lista extensa deja abierto. El capítulo «Por qué fracasan las retrospectivas» de nuestra guía sobre retrospectivas aborda cómo cerrar ese ciclo desde dentro de la propia sesión, y la retrospectiva «de marcar casillas» que se describe en el capítulo «Rendimiento» es el vacío que se produce antes de que el equipo se rinda por completo.

La válvula de presión

Pero existe una versión más profunda de ese vacío, y es precisamente en la que los consejos de nuestro sector se equivocan. A veces, las acciones no se llevan a cabo porque el equipo nunca iba a ser capaz de hacerlas realidad, ya que los verdaderos problemas están, de hecho, por encima de su nivel de competencia. El presupuesto, la plantilla, las dependencias entre equipos, una decisión de arquitectura tomada dos niveles por encima, un plazo fijado por el departamento de ventas. El equipo podría enumerar estos problemas todo el día. Pero no puede solucionar ninguno de ellos. Y así, la retrospectiva se convierte en una válvula de escape: un lugar para desahogarse, de modo que la dirección pueda sentir que se ha escuchado al equipo, sin ningún mecanismo para cambiar aquello sobre lo que se está expresando el descontento.

vs feedback in Owner Pressure valve input in, nothing out Radiator pushed out to an owner
Una válvula libera justo el vapor necesario para que nada cambie; un radiador traslada el mismo problema al propietario en cuestión. La siguiente sección transforma lo uno en lo otro.

La afirmación más contundente al respecto proviene de un desarrollador que escribe en dev.to, y merece la pena citarla íntegramente: «La retrospectiva se convirtió en una válvula de escape. Una apariencia de voz sin el fondo de poder». El mismo artículo plantea una cuestión que debería incomodar a cualquier coach: «Culpar a la facilitación es como culpar al buzón de sugerencias porque la dirección no lee las sugerencias». No se puede resolver un problema de poder mediante la facilitación. Y en Hacker News, se afirma sin rodeos: una retrospectiva es «una ceremonia sin propósito real, ya que, por lo general, los asuntos más profundos que la gente plantea no están dentro del ámbito de control de ese equipo»; y lo que es peor, «le da al liderazgo una excusa para no solucionar las cosas».

Aquí es donde la mayoría de los consejos de los proveedores causan un daño real. La lista estándar de antipatrones indica a los equipos que «se mantengan dentro de su círculo de influencia»: dejen de plantear cuestiones que no pueden cambiar. Al plantearse como un problema de disciplina del equipo, ese consejo es totalmente erróneo. Le indica al equipo que oculte el verdadero obstáculo y se centre únicamente en los aspectos menores, seguros y controlables por el equipo, que es precisamente cómo una retrospectiva se convierte en una mera farsa. Permanecer dentro de su círculo de influencia es un mal consejo cuando lo más importante de la sala se encuentra fuera de él.

Exprese sus emociones hacia fuera, no las reprima hacia dentro

La buena noticia es que el texto canónico ya incluye la corrección, y ha sido la edición actual la que la ha incorporado. La segunda edición de Agile Retrospectivas (2024), en la que David Horowitz se unió a Esther Derby y Diana Larsen, añadió un capítulo completo sobre cuestiones que escapan al control del equipo; el problema se agudizó hasta tal punto que la obra de referencia se vio obligada a ponerse al día. Tres de sus herramientas constituyen el antídoto contra la válvula de escape:

  • Círculos y «sopa» — Clasifique cada asunto según quién sea el responsable: lo que el equipo controla, lo que puede influir y lo que se encuentra en la «sopa», a lo que solo puede responder. Se trata de una clasificación por responsabilidad, y sustituye el lema «quédese en su círculo» por «derive cada problema a quien realmente pueda actuar al respecto».
  • Soluciones del 15 %: ante los grandes problemas que se han estancado, identifique la parte en la que el equipo puede empezar a trabajar ahora mismo sin necesidad de pedir permiso a nadie. No se trata de la solución completa, sino del 15 % de la misma que está a su alcance. Es mejor avanzar en una parte que quedarse paralizado ante el conjunto.
  • Radiadores retrospectivos: hacen que los problemas escalados sean visibles para el exterior, en un panel que la dirección pueda consultar y cuyo seguimiento se realice a lo largo del tiempo. Un «radiador» es lo contrario de una «válvula»: una válvula libera la presión y la oculta; un «radiador» da a conocer el asunto sin resolver hasta que alguien con la capacidad de solucionarlo lo haga. Escale los casos marcados en rojo indicando el nombre de la persona responsable.

Esa es la línea firme que se desprende de la investigación, y está respaldada por el canon: realizar una clasificación por titularidad, escalar los elementos rojos por nombre y fecha, y «irradiar» en lugar de «desahogar». Una retro que actúe así es honesta en cuanto al poder. Una retro que se salte este paso es una válvula de presión con un facilitador.

Lo importante es el aprendizaje, no la lista de tareas pendientes

Este último replanteamiento cierra el ciclo de todo el modo. La segunda edición también modifica el propio criterio de éxito, pasando de las medidas concretas al aprendizaje. La postura de la segunda edición —y es un alivio escucharla de la propia fuente autorizada— es que una retrospectiva sin una medida concreta no es un fracaso si el equipo ha aprendido algo. La unidad de cambio se convierte en un experimento —una hipótesis que se comprueba con una fecha de revisión— en lugar de una tarea pendiente que se queda estancada en la lista de tareas pendientes. «Creemos que trabajar en pareja en la implementación reducirá nuestra tasa de reversiones; lo probaremos durante dos sprints y lo comprobaremos» es un experimento. «Mejorar las implementaciones» es una nota adhesiva que acaba en el olvido.

Action item “Improve deploys” backlog words, and only words Experiment EXPERIMENT We think X… Try — 2 sprints Review ▸ a date learned a change you’re running Judge a retro by what it learns, not the to-dos it lists.
Una tarea como «mejorar las implementaciones» se queda estancada en la lista de tareas pendientes sin que nadie se haga cargo de ella; sin embargo, esa misma intención, planteada como un experimento —una hipótesis con una fecha de revisión—, se convierte en un cambio que el equipo está llevando a cabo de verdad.

También pone de relieve un coste que nunca aparece en las listas de antipatrones: el desgaste emocional que supone una sesión dedicada exclusivamente a desahogarse. Como señaló uno de los participantes, una retrospectiva puede ser «más de una hora sentado ahí, principalmente escuchando a otras personas quejarse de cosas, lo cual me deprime». Una retrospectiva dedicada exclusivamente a desahogarse no solo no soluciona nada, sino que supone una carga para las personas que deben soportar las quejas. La solución no consiste en prohibir los sentimientos, sino en ofrecerles una salida: convertir los puntos rojos en experimentos asumidos, con fecha límite y difundidos, y así esa hora dejará de ser un espacio en el que solo circula la frustración.

Esa es la forma de salir del vacío y de la guía. Haga que el ciclo sea lo suficientemente breve como para cerrarlo, realice una clasificación de prioridades con la honestidad necesaria para escalar lo que el equipo no pueda resolver, y mida el aprendizaje en lugar de contabilizar acciones —porque la franqueza que no cambia nada acaba dejando de ser franqueza. Los cuatro modos —Rendimiento, Poder, Sobrecarga y el Vacío— son, en definitiva, la misma pregunta formulada de cuatro maneras diferentes: ¿está esta ceremonia cumpliendo su función, o simplemente representándola?

Preguntas frecuentes

¿Qué hace usted cuando surgen los mismos problemas en todas y cada una de las reuniones retrospectivas?

Analice por qué se repiten, ya que dos fallos distintos pueden parecer idénticos desde dentro. Si la acción se ha registrado pero nunca se ha asignado a nadie, se queda estancada en la lista de tareas pendientes mientras que en la siguiente retrospección se añaden tres más: limite a una sola tarea asignada con una fecha de revisión, y comience la siguiente retrospección comprobando que se ha completado. Si el problema sigue reapareciendo porque realmente escapa al control del equipo, volver a incluirlo en la lista nunca funcionará: clasifíquelo según quién sea el responsable y remítalo a un nivel superior indicando el nombre y la fecha, en lugar de volver a desahogarse.

¿Qué hace usted cuando el verdadero problema escapa al control del equipo?

No anime al equipo a plantear problemas de menor importancia; así es como una retrospectiva se convierte en una farsa. Clasifique cada problema según quién sea realmente el responsable; a continuación, remita los problemas graves a los niveles superiores indicando el nombre y la fecha, y hágalos visibles en un «radiador de retrospectiva» para que no puedan dejarse de lado discretamente. Mantenerse dentro de su círculo de influencia es un mal consejo cuando ello implica ocultar el verdadero obstáculo.

¿Cómo podemos conseguir que las tareas retrospectivas se lleven realmente a cabo?

Limítese a una sola. Una única mejora con la que el equipo se comprometa de verdad, que se revise al principio de la próxima retrospectiva antes que cualquier otra cosa, es mejor que una lista de diez que acaben quedando en el olvido. Asigne un responsable y una fecha de revisión, y trátela como un experimento con una hipótesis, en lugar de como una tarea más de una lista.

¿Es necesario establecer una medida concreta tras una sesión retrospectiva?

No, y insistir en que sí lo es forma parte del problema. La segunda edición de «Agile Retrospectives» replantea el criterio de éxito en términos de aprendizaje, y no de acciones pendientes: una retrospectiva en la que el equipo haya comprendido realmente algo nuevo no es un fracaso solo porque no haya generado una tarea pendiente. Realice experimentos de los que pueda aprender, no tareas por las que se sienta culpable.

Lecturas relacionadas