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

Su equipo celebra una retrospectiva en cada sprint. Los miembros acuden, colocan sus notas adhesivas, asienten ante dos o tres acciones pendientes y se marchan. Después, 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. Ha creado un hábito de hablar sobre la mejora. Ese es el modo de fracaso que casi nadie menciona: no es un formato malo, sino 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. Por lo general, no lo es. Hemos catalogado los diez antipatrones de retrospectiva más comunes en otro artículo, y merece la pena subsanarlos. Este capítulo aborda los dos fallos que la lista elude cortésmente, ya que son los que hacen que los ingenieros experimentados califiquen las retrospectivas de pérdida de tiempo: un problema de poder y un problema de seguimiento. Ningún rompehielos aborda ninguno de ellos. Si la facilitación es realmente su problema, la solución reside en cómo llevar a cabo retrospectivas eficaces, no aquí.

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 las medidas a tomar. Lo que quiere decir es que los problemas que merece la pena plantear (plantilla, dependencias entre equipos, un proceso de implementación que tarda cuarenta minutos, un plazo fijado tres niveles por encima) están realmente fuera del ámbito de competencia del equipo para solucionarlos. Como lo expresó con claridad un ingeniero en Hacker News, una retrospectiva puede convertirse en «una ceremonia sin un 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 proporciona a la dirección una excusa para no solucionar los problemas 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. Las personas desahogan sus frustraciones, 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 otorgará 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 a quién le corresponde realmente: 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. El objetivo del anillo exterior no es «ignorar estos aspectos», sino que constituye el punto de partida para una escalación.

No todo se complica, 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 van superándose poco a poco. Sin embargo, la retrospectiva honesta se niega a fingir que el anillo exterior sea 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 perjudicar la carrera profesional. El temor es concreto 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, afirmó: «guardan todas estas quejas para sacarlas a relucir en la revisión de su bonificación anual».

Eso es lo que se conoce como «banco de comentarios»: comentarios sinceros que se acumulan y se utilizan en su contra más adelante, y la forma más rápida de arruinar por completo 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 es suficiente. Nadie que controle su ascenso tiene que decir ni una palabra para que se ande con rodeos respecto a lo que habría dicho en otras circunstancias. 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.
• Acuerde 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 las personas se expresen, 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, erosiona la confianza que está intentando forjar. Deje que las personas lo elijan para aquellos temas 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 mecanismo de escalada 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 replanteamiento que lo corrige

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 recurrente de 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 («esta cuestión 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: la cifra que todo el mundo repite, un dato muy citado según el cual solo alrededor de un tercio de los equipos completan de forma sistemática las acciones derivadas de sus retrospectivas, resulta ser una visión excesivamente pesimista. Hemos medido cuántas medidas de las retrospectivas se llevan realmente a cabo a partir de cientos de miles de acciones reales: la tasa de cumplimiento se acerca a tres de cada cuatro, y la cadencia y la asunción de responsabilidad determinan en qué lado de esa brecha se sitúa un equipo. En lo que la creencia popular acierta es en la forma que adopta el fracaso. Una acción de la que nadie se hace responsable, sin fecha concreta, en un equipo sin ritmo, es aquella que se escribe en la pizarra y se borra.

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

En primer lugar, deje de intentar arreglarlo todo. Cuanto más larga es la lista, peor se llevan a cabo cada uno de sus puntos: según nuestros datos, las retrospectivas que concluyen con diez o más acciones completan aproximadamente el 56 % de ellas, frente al 79 % de las que concluyen con entre una y tres. Limítese a una mejora con la que el equipo se comprometa de verdad, inclúyala en el trabajo del próximo sprint en lugar de dejarla en el tablero, y comience cada retrospectiva revisando esa única cosa de la última sesión antes de plantearse 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, deje de considerar la tarea pendiente como el objetivo principal. Este es el cambio de perspectiva que propone Agile Retrospectives, 2.ª edición y hacia el que se está orientando toda la categoría. 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 corrección»), una fecha para revisarla y un análisis honesto de lo que realmente ha ocurrido. Una retrospectiva que no haya generado ninguna acción que se pueda marcar en una lista, 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. Johanna Rothman ya llevaba tiempo aplicando esta misma sustitución mucho antes de que se convirtiera en un elemento canónico de las retrospectivas, en Create Your Successful Agile Project: un punto, llevado a cabo como experimento, con el siguiente bloque de trabajo del equipo estructurado para incluirlo.

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 reunión 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 agrava: 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; esto protege a las personas introvertidas y a aquellas que no desean ser las primeras en expresarlo en voz alta. Recoja 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 gasto 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. Y eso se suma a las reuniones de pie, la planificación, la revisión y el refinamiento. En ciclos cortos, las cuentas se vuelven implacables: los equipos que trabajan 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 ninguna virtud.

La solución no consiste en omitir las reuniones retrospectivas, sino en adaptarlas a las necesidades del equipo. 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 una periodicidad quincenal, o convoque 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 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 gestión, proteja la honestidad, lleve a cabo al menos una medida concreta y ajuste el ritmo, 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. Una herramienta de retrospectiva en línea ayuda de una forma concreta: traslada cada cambio acordado como una acción con seguimiento, de modo que el cumplimiento perdura 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 dispone de un canal para remitirlos a ninguna instancia. 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 cambiarla. 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 escalar los asuntos que quedan fuera del alcance hacia arriba, 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?

Elevad el asunto por la vía oficial. Clasificad 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 «Retrospective Radiator») 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 y poco honesta.

¿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 por cada idea en concreto, en lugar de hacerlo de forma global («todo o nada»).

¿Son las retrospectivas una pérdida de tiempo?

Esto ocurre 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 (sacar a la luz las tensiones en una fase temprana, mantener 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.