Por qué fracasan las retrospectivas (y cómo lograr que las suyas sean significativas)
La mayoría de las retrospectivas fracasan por motivos que ningún rompehielos puede solucionar: la falta de empoderamiento, los comentarios utilizados como arma y la falta de seguimiento. A continuación le explicamos cómo lograr que la suya sea significativa.
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 mal formato, 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 un rompehielos. A veces ese es el problema. Pero, por lo general, no lo es. Hemos recopilado en otro lugar los diez antipatrones más comunes en las retrospectivas, y merece la pena corregirlos. 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 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 medidas a tomar. Lo que quiere decir es que los problemas que merecen ser planteados (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ó 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: «Le 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 quejas».
Ahí radica la trampa. La sesión retrospectiva se convierte en una válvula de escape: se permite al equipo expresarse, precisamente para que nada tenga que cambiar. Las personas se desahogan, 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 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 «Círculos y sopa» del libro Agile Retrospectives (2.ª ed.) de Esther Derby y Diana Larsen. 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, 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 afectar negativamente a 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, comentó: «Guardan todas estas quejas para sacarlas a relucir en la revisión anual de su bonificación».
Eso es lo que se conoce como «acumulación de comentarios»: opiniones sinceras que se guardan para luego utilizarlas en su contra, y 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 proceso en el que el equipo de Scrum se examina a sí mismo. Tómelo al pie de la letra: el equipo se examina 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 ni una 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 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, socava la confianza que está intentando forjar. 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) deben formar parte de 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» en torno a la velocidad, y las personas se dedican a optimizar la cifra en lugar de decir la verdad. Este es el modo de fallo que convierte la franqueza en un indicador de 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 repetida en todo el debate: «Las retrospectivas permiten expresar inquietudes, 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 medidas 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 la 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 solucionarlo todo. Cuanto más larga es la lista, peor resultado se obtiene con cada punto: según nuestros datos, las retrospecciones 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 la pizarra, y comience cada retrospectiva revisando esa única mejora 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, deje de considerar la tarea pendiente como el objetivo principal. Este es el cambio de perspectiva que propone la 2.ª edición de Agile Retrospectives 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 finalización de una tarea, 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 en la 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 venía aplicando esta misma sustitución mucho antes de que se convirtiera en un elemento canónico de las retrospectivas, en su libro Create Your Successful Agile Project: una tarea, llevada a cabo como un experimento, con el siguiente bloque de trabajo del equipo estructurado para incluirla.
El silencio no es apatía: es una señal
Un fracaso más silencioso: esa sesión «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 predefinidas, 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; esto protege a las personas introvertidas y a aquellas que no desean ser las primeras en expresarse 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 «no saltarse nunca la reunión retrospectiva» descartan con demasiada rapidez: las reuniones retrospectivas tienen un coste. «Es otra reunión más en mi agenda que podría interrumpir cualquier estado de concentración profunda en el que me encontrara», escribió un desarrollador. A esto hay que sumarlo a las reuniones de pie, de planificación, de revisión y de perfeccionamiento. En ciclos cortos, las cifras se vuelven abrumadoras: 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 maduro no son una virtud. La misma queja se manifiesta a escala organizativa en la investigación sobre la carga de reuniones, donde se mide —en lugar de estimarse— el porcentaje de reuniones que las personas afirman que podrían haberse omitido.
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 una periodicidad quincenal, 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 los Standups y la falta 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 de cada 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: lleva adelante cada cambio acordado como 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 dispone de 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 en silencio.
¿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, en los que puede influir y en 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 «Retrospectiva 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, 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 particular, en lugar de hacerlo de forma global.
¿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 (sacando a la luz las tensiones de forma temprana, 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.