Por qué fracasan las retrospectivas (y cómo lograr que las suyas sean significativas)

Su equipo celebra una retrospectiva en cada sprint. Los participantes acuden, colocan sus notas adhesivas, asienten ante dos o tres acciones pendientes y se marchan. Sin embargo, nada cambia en cuanto a cómo se lleva a cabo realmente el trabajo. Si hace eso cuarenta veces al año, no habrá creado un hábito de mejora, sino un hábito de hablar sobre la mejora. Ese es el modo de fracaso que casi nadie menciona: no se trata de un mal formato, sino de un ritual que genera de forma fiable palabras y solo palabras.

El consejo habitual considera que una retrospectiva fallida es un problema de facilitación: cambiar el formato, redactar acciones más SMART, añadir rompehielos. A veces ese es el problema. Pero, por lo general, no lo es. Hemos recopilado en otro lugar los diez antipatrones de retrospectiva más comunes, y merece la pena solucionarlos. Este capítulo aborda los dos fallos que la lista elude cortésmente, ya que son los que hacen que los ingenieros experimentados consideren las retrospectivas una pérdida de tiempo: un problema de poder y un problema de seguimiento. Ningún rompehielos aborda ninguno de ellos.

El estilo retro que no cambia nada porque el equipo no puede

Esta es la crítica más profunda que se puede hacer a las retrospectivas, y aquella en la que nuestro propio artículo sobre antipatrones se equivoca. Cuando un desarrollador afirma que «nunca ocurre nada», por lo general no se refiere a que el equipo se haya olvidado de redactar medidas a tomar. Lo que quiere decir es que los problemas que merecen ser planteados —la plantilla, las dependencias entre equipos, un proceso de implementación que tarda cuarenta minutos, un plazo fijado tres niveles por encima— están realmente fuera de la competencia del equipo para solucionarlos. Como lo expresó claramente un ingeniero en Hacker News, una retrospectiva puede convertirse en «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». Otro, en el mismo hilo: «Esto da a la dirección una excusa para no solucionar las cosas ni escuchar, ya que se supone que la retrospectiva es el espacio para expresar las quejas».

Ahí radica la trampa. La sesión retrospectiva se convierte en una válvula de escape —el equipo puede expresarse, precisamente para que nada tenga que cambiar—. La gente se desahoga, los responsables consideran que se ha cumplido con el trámite y la causa subyacente permanece intacta. Culpar al facilitador de esto es, como decía el ensayo de un desarrollador, «como culpar al buzón de sugerencias de que la dirección no lea las sugerencias». Por mucho que se recurra a la metáfora del velero frente a la estrella de mar, nunca se le dará a un equipo la autoridad para resolver un problema para el que nunca se le concedió dicha autoridad.

Nuestro antiguo consejo —«dejen de centrarse en cuestiones que quedan fuera de su círculo de influencia»— se alinea discretamente con el sistema en este caso. Indica al equipo que oculte el verdadero obstáculo para que la conversación se desarrolle en un ambiente agradable. Adopte, en cambio, una postura más firme. Clasifique cada problema según quién sea realmente responsable de él: lo que el equipo controla, lo que puede influir y lo que solo puede sufrir. Se trata de la actividad «Circles and Soup» de Agile Retrospectives (2.ª ed.) de Esther Derby y Diana Larsen, y el objetivo del anillo exterior no es «ignore these». Es el punto de partida para una escalación.

No todo se agrava, ni todo es desesperado. Soluciones al 15 % —la técnica de «Liberating Structures» que consiste en encontrar el cambio más pequeño que el equipo puede realizar sin necesidad del permiso de nadie— mantiene el impulso en el «anillo de influencia» mientras los grandes obstáculos se van superando poco a poco. Sin embargo, una retrospectiva honesta se niega a fingir que el anillo exterior es culpa del equipo.

Los comentarios que se acumulan y se utilizan en su contra

Ahora, la parte de la que ningún proveedor habla. La gente guarda silencio en las reuniones retrospectivas por una razón más concreta que la timidez: ser sincero puede afectar negativamente a la carrera profesional. El temor es específico y se refleja en historias reales. Un desarrollador describió cómo los comentarios de la retrospectiva resurgieron «en mi evaluación anual, donde se me señaló que “me quejo demasiado”». Otro, con mayor cinismo, comentó: «Se guardan todas estas quejas para sacarlas a relucir en la revisión de su bonificación anual».

Eso es el «banco de comentarios» —comentarios sinceros que se acumulan y se utilizan en su contra más adelante— y es la forma más rápida de acabar con una retrospectiva de sprint. La Guía de Scrum describe la retrospectiva de sprint como el equipo de Scrum que se examina a sí mismo. Tómelo al pie de la letra: el equipo, examinándose a sí mismo. Entonces, ¿por qué la persona que firma su evaluación de rendimiento está sentada en la sala tomando notas? Su silencio basta: nadie que controle su ascenso tiene que decir una sola palabra para que usted suavice lo que, de otro modo, habría dicho. El Proyecto Aristóteles de Google descubrió que la seguridad psicológica es el principal factor predictivo de la eficacia de un equipo; la mera presencia de un responsable suele bastar para eliminarla. (Tratamos los mecanismos en el capítulo sobre cómo crear un espacio psicológicamente seguro.)

Así pues, identifique el miedo y elabore una estrategia para combatirlo:

• Mantenga la autoridad en materia de ascensos fuera de la sala. Comparta las medidas acordadas con los superiores, no los puestos. Un equipo bloqueado por la presencia de un responsable no puede llevar a cabo una retrospectiva transparente, y ningún truco de facilitación puede remediarlo.
• Acordemos que lo que se diga se quede en la sala. Solo salen de ella las acciones que el equipo decida hacer públicas. Esto es lo que permite que la gente se atreva a hablar, en primer lugar.
• Haga que el anonimato sea una opción para cada idea, no un modo permanente. El anonimato equilibra las dinámicas de poder y saca a la luz los temas delicados; si se utiliza como un recurso permanente, socava la confianza que está intentando generar. Deje que las personas lo elijan para aquellas ideas que lo requieran.
• Tenga cuidado al introducir métricas. Los datos objetivos (velocidad, tiempo de ciclo) tienen cabida en una retrospectiva; pero en el momento en que la velocidad se convierte en un objetivo con el que se evalúa al equipo, se ha creado un efecto trampa de la velocidad, y las personas se dedican a optimizar la cifra en lugar de decir la verdad. Este es el modo de fallo de poder que convierte la franqueza en rendimiento.

El vacío en el seguimiento — y el cambio de perspectiva que lo soluciona

Supongamos que los problemas de energía y seguridad están resueltos. Las retrospectivas siguen fracasando en lo que respecta a la queja más repetida en todo el debate: «Las retrospectivas permiten expresar las preocupaciones, pero en realidad nunca se hace nada al respecto». O, dicho sin rodeos: «Nunca he visto que se haga nada más allá de las palabras». Ese tono de resignación —«este tema pendiente no se abordará»— es lo que se percibe desde dentro en las retrospectivas que parecen el «Día de la Marmota». No es fruto de la imaginación: según una cifra de la Scrum Alliance que se cita con frecuencia, solo alrededor de un tercio de los equipos completan de forma sistemática las medidas derivadas de sus retrospectivas. El resto se anota en una pizarra y se borra. Sin embargo, la creencia popular exagera el pesimismo: hemos medido cuántas acciones de las retrospectivas se llevan realmente a cabo a partir de cientos de miles de acciones reales, y la tasa de cumplimiento se acerca a tres de cada cuatro, siendo la cadencia y la asunción de responsabilidad los factores que determinan en qué lado de la brecha se sitúa cada equipo.

Dos correcciones, y la segunda es la más importante.

En primer lugar, deje de intentar arreglarlo todo. Una retrospectiva que genere diez acciones a realizar no lleva a cabo ninguna de ellas. Limítese a una mejora con la que el equipo se comprometa de verdad, y comience cada retrospectiva revisando esa única acción de la última sesión antes de plantear nada nuevo. Si no se ha llevado a cabo, esa es la conversación más útil que puede tener en la sala. Buscar un nuevo formato es lo primero que intentan los equipos y lo que menos probabilidades tiene de ayudar: cambiar «Enfadado/Triste/Contento» por un velero es un cambio superficial si no se lleva a cabo el seguimiento.

En segundo lugar —y este es el cambio de perspectiva que propone la Agile Retrospectives, 2.ª edición y hacia el que se está orientando toda la categoría—: deje de considerar la tarea pendiente como el objetivo principal. El cambio clave que proponen Derby, Larsen y David Horowitz es que el aprendizaje, y no la tarea completada, es el criterio de éxito. Sustituya la «tarea de acción» por un experimento: una hipótesis que se pone a prueba («si trabajamos en pareja en la historia arriesgada, reduciremos el trabajo de reelaboración»), una fecha para revisarla y una reflexión sincera sobre lo que realmente ocurrió. Una retrospectiva que no haya generado ninguna acción de «marcar casillas», pero que realmente haya enseñado algo al equipo, no es una retrospectiva fallida. Ese simple cambio disipa la queja de que «nada cambia», ya que el objetivo deja de ser una tarea que hay que completar y se convierte en un cambio que realmente se está llevando a cabo.

El silencio no es apatía, es una señal

Un fracaso más silencioso: esa sesión de retro en la que dos de cada ocho personas hablan durante cinco minutos y el resto es silencio, y por mucho que pruebe con distintos formatos o plantillas preelaboradas, nada cambia. Es fácil interpretar eso como un equipo desmotivado. Pero normalmente no lo es. El silencio en una retrospectiva es una señal, no el problema en sí mismo: apunta a una falta de confianza, a un propósito poco claro o a un problema de liderazgo que la gente no se atreve a mencionar en voz alta. El trabajo a distancia lo empeora: cámaras apagadas, micrófonos silenciados, energía a cero.

No llene el silencio con más indicaciones. Cambie quién habla primero. Organice una sesión de lluvia de ideas en silencio e individual antes de cualquier debate, de modo que las personas escriban antes de hablar —lo cual protege a los introvertidos y a quienes no desean ser los primeros en expresarlo en voz alta—. Recopile aportaciones de forma asíncrona con antelación. Permita que las personas aporten una nota adhesiva sin tener que defenderla ante el resto de la sala. El objetivo no es una reunión animada, sino datos sinceros, y los datos sinceros suelen surgir en silencio.

El «impuesto de las reuniones» es un coste real, no una excusa

Por último, la crítica que los defensores de «nunca saltarse la retrospectiva» descartan con demasiada rapidez: las retrospectivas tienen un coste. «Es otra reunión en mi agenda que puede interrumpir cualquier estado de concentración profunda en el que me encontrara», escribió un desarrollador —sumada a la reunión diaria, la planificación, la revisión y el refinamiento—. En ciclos cortos, las cifras se vuelven implacables: los equipos con sprints de una semana describen la planificación y la retrospectiva semanales como «una carga», y tienen razón. Cincuenta retrospectivas al año en un equipo consolidado no son una virtud.

La solución no consiste en saltarse las reuniones retrospectivas, sino en adaptarlas a la situación. Un equipo recién formado que se encuentra bajo presión se beneficia de celebrar una reunión retrospectiva en cada sprint. Un equipo estable que sigue manteniendo la misma conversación superficial le está indicando que la cadencia es incorrecta, no que la reflexión carezca de valor. Pase a celebrarlas cada dos semanas, o active las retrospectivas en función de acontecimientos —tras un lanzamiento, tras una interrupción del servicio, tras un sprint complicado— cuando realmente haya algo que analizar. La frecuencia es un regulador, no un mandamiento. (La misma lógica de sobrecarga se aplica a todas las ceremonias; consulte los antipatrones de las reuniones de pie y el vacío de seguimiento en nuestra guía práctica «Agile Theatre»).

Solucione el problema de la motivación, proteja la honestidad, lleve a cabo al menos una medida concreta y ajuste el ritmo a la medida adecuada, y la retrospectiva dejará de ser una válvula de escape. Se convertirá en esa hora del sprint en la que el equipo cambia realmente su forma de trabajar —que era, precisamente, el objetivo desde el principio. Una herramienta de retrospectiva en línea ayuda de una forma concreta: traslada cada cambio acordado a una acción con seguimiento, de modo que el cumplimiento perdure más allá de la semana posterior a la reunión.

Preguntas frecuentes

¿Por qué nunca cambia nada tras nuestras retrospectivas?

Por lo general, esto se debe a que los problemas más importantes quedan fuera del ámbito de competencia del equipo, y la retrospectiva no ofrece ningún canal para remitirlos a quien corresponda. El tablero se llena de problemas que el equipo no puede resolver por sí solo —plantilla, dependencias, un proceso de implementación defectuoso— y todos se marchan tras haber descrito la situación en lugar de haberla cambiado. La solución consiste en clasificar cada asunto según quién sea realmente el responsable, mantener una única mejora controlada por el equipo en la que trabajar y elevar los asuntos que quedan fuera del alcance a los niveles superiores, indicando el nombre del responsable y una fecha, en lugar de descartarlos sin más.

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

Lo eleva al nivel superior, de forma oficial. Clasifique los problemas en aquellos que el equipo controla, aquellos en los que puede influir y aquellos que solo puede sufrir (la actividad de los «Círculos y la Sopa» de Agile Retrospectives). El consejo habitual es ignorar el anillo exterior y permanecer en su círculo de influencia. Así es como una retrospectiva se convierte en un espectáculo. En su lugar, convierta los elementos del anillo exterior en una solicitud visible —un «Radiador de Retrospectiva»— que identifique el obstáculo, el impacto y quién debe actuar, y preséntela ante las personas que pueden resolverla. Una retrospectiva que solo saca a la luz problemas que el equipo ya puede solucionar resulta cómoda, pero deshonesta.

¿Es seguro ser sincero en una retrospectiva?

Solo si la honestidad no supone un coste para la carrera profesional. Los desarrolladores suelen informar de que los comentarios retrospectivos resurgen en las evaluaciones de rendimiento como prueba de que «se quejan demasiado». Si la persona encargada de aprobar los ascensos está presente en la sala, o si lo que se dice se guarda para más adelante, la gente se calla y afirma que todo va bien. Proteja la franqueza de forma deliberada. Mantenga fuera de la sesión a los responsables directos que tienen en sus manos las promociones, acuerde que lo que se discuta se quede en la sala y que solo salgan de ella las medidas acordadas, y ofrezca la posibilidad de mantener el anonimato para cada idea en concreto, en lugar de hacerlo de forma global.

¿Son las retrospectivas una pérdida de tiempo?

Se dan cuando el único criterio de éxito es una tarea completada, ya que la mayoría de los sprints no le ofrecen una situación tan clara. Replantee el objetivo: una retrospectiva tiene éxito cuando el equipo aprende algo que aplicará en el siguiente sprint, incluso sin una tarea que se pueda marcar como completada, y cuando lleva a cabo un experimento sincero en lugar de diez tareas abandonadas. Las retrospectivas también realizan una labor más discreta —sacando a la luz las tensiones de forma temprana y manteniendo la cohesión del equipo— que nunca aparece como una tarea concreta, pero que es real. Si se consideran un ritual de aprendizaje en lugar de una fábrica de tareas, se ganan su lugar.