Nulo: cuando la ceremonia no cambia nada

El modo de fallo más letal no es una ceremonia deficiente, sino una ceremonia adecuada 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. Luego comienza el nuevo sprint y no cambia absolutamente nada. 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 ocurre nada realmente al respecto». Otro, más directo aún: «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 medida; es que la medida 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 las mismas cuestiones de la retrospectiva de sprint tras sprint sin que se hayan abordado», reza un relato resignado. «Esta nota adhesiva no se 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 produce palabras y solo palabras. No obstante, hay que tomar estas creencias populares con cautela: nuestros propios datos internos sobre qué porcentaje de tareas 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 responsabilidad y la cadencia, y no el esfuerzo, las que determinan la brecha.

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 en el principio de la próxima retrospectiva antes de que ocurra nada más, es mejor que una lista de diez que acaban quedando en el olvido. Este consejo no es nuevo: Johanna Rothman ha recomendado un único punto, tratado como un experimento e integrado en el siguiente bloque de trabajo del equipo, en Create Your Successful Agile Project. Si se establecen demasiadas medidas, la mitad no se llevará a cabo, y esa mitad que no se cumpla enseñará al equipo que nada de ello cuenta. Una sola tarea, asignada a alguien y con una fecha de revisión, cierra el círculo que una lista larga deja abierto. El capítulo «Por qué fracasan las retrospectivas» de nuestra guía sobre retrospectivas aborda cómo completar ese ciclo desde dentro de la ceremonia, 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

Sin embargo, 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: los verdaderos problemas están, sin lugar a dudas, fuera del alcance del equipo. 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 enumerarlas todo el día. Pero no puede solucionar ninguna de ellas. Y así, la retrospección 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.

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 sustancia 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 de que la dirección no lea 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». Peor aún: «le da a la dirección 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 representación teatral. 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.

Irradie hacia fuera, no se 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 presión:

• Círculos y «sopa»: clasifique cada asunto según quién sea el responsable, distinguiendo entre lo que el equipo controla, aquello sobre lo que puede ejercer influencia y lo que se encuentra en la «sopa», a lo que solo puede responder. Se trata de una clasificación por responsabilidad, que sustituye el principio de «quédese en su círculo» por «derive cada incidencia 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 permiso de 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: hagan que los problemas escalados sean visibles para el exterior, en un panel que la dirección pueda ver, con un seguimiento 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 pendiente hasta que alguien con la capacidad de resolverlo lo haga. Escale los asuntos 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 selección en función de la propiedad, 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 aprender, no la lista de tareas pendientes

Este último replanteamiento cierra el ciclo de todo el proceso. La segunda edición también modifica el propio criterio de éxito, pasando de las medidas de acción al aprendizaje. Su postura (y es un alivio escucharlo de la propia fuente autorizada) es que una retrospectiva sin medidas de acción no es un fracaso si el equipo ha aprendido algo. La unidad de cambio se convierte en un experimento: una hipótesis que se pone a prueba con una fecha de revisión, en lugar de una tarea pendiente que se queda estancada en el backlog. «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.

Además, 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 consistir en «más de una hora sentado ahí, principalmente escuchando a otras personas quejarse de cosas, lo cual me desanima». Una retrospectiva dedicada exclusivamente a desahogarse no solo no soluciona los problemas, sino que supone una carga para las personas que deben asimilar las quejas. La solución no consiste en prohibir los sentimientos, sino en ofrecerles una salida: convertir los elementos «rojos» en experimentos asumidos, con fecha límite y difundidos, de modo que esa hora deje 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 pequeño como para cerrarlo, realice una clasificación de prioridades con la honestidad necesaria para escalar lo que el equipo no pueda solucionar, y mida el aprendizaje en lugar de contar las 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 cada sesión de retrospectiva?

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 retrospectiva se añaden tres más. Limítese a un único elemento asignado con una fecha de revisión, y comience la siguiente retrospectiva comprobándolo. Si el problema sigue reapareciendo porque realmente está fuera del 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 eso 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 inicio de la próxima retrospectiva antes que nada, 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 en 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 como el aprendizaje, y no como las 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

• Poder: cuando la autoridad se apropia de la ceremonia. Por qué los problemas que merece la pena plantear suelen estar por encima del nivel de competencia del equipo.
• Espectáculo: la ceremonia que se organiza para el público. El estilo retro de «marcar casillas», antes de que el equipo lo deje de lado.
• Cómo crear un espacio psicológicamente seguro. Una franqueza que tiene un lugar al que dirigirse.
• La Directiva Primaria retrospectiva. La norma que garantiza la honestidad en la sala.
• La retrospectiva de sprint (la ceremonia). El lugar que ocupa la retrospectiva en el ciclo y el ciclo que se cierra gracias a ella.
• Glosario de Agile Theatre. Definición de los cuatro tipos de fallos identificados.