Algunos antipatrones en retrospectivas


Al finalizar la retrospectiva, preguntas al equipo: “¿qué tal?, ¿qué os ha parecido la sesión?” y la respuesta coincide con las otras veces que preguntaste: “Ha estado bien”. Al fin y al cabo hemos hablado de cosas que preocupan al equipo y hasta hemos acordado algunas medidas para mejorar. Sin embargo, notas que se trata de una inversión de tiempo enorme y que cada vez es más difícil ver el valor de estas sesiones.

Como Scrum Masters, nuestra labor es provocar cambios positivos en el equipo. Uno de los eventos clave para que esto suceda es la retrospectiva. Pero existen ciertos comportamientos que pueden minar este importante evento de Scrum, y por tanto frenar la evolución de tu equipo.

Antipatrones en retrospectivas agile

Conocer estos antipatrones en retrospectivas es el primer paso para solucionarlos. Aunque seguramente habrán miles, me gustaría compartir contigo una lista de los que yo me he encontrado con más frecuencia. También probar algunas cosas que podemos probar en caso de experimentarlos:

  • Balones fuera: todo es culpa del entorno del equipo, y por tanto no hay nada que hacer. Una forma de visualizar esto es utilizar la dinámica círculos y sopa y pedir al equipo que concentre sus ideas en el área de control.
  • El día de la marmota v1: se acuerdan medidas pero nunca se llevan a cabo. Como consecuencia suele pasar que siempre salen los mismos temas. Toma notas de las acciones acordadas, colócalas en un sitio visible, e inicia cada retrospectiva repasando si se están llevando a cabo las acciones y si están dando los resultados esperados.
  • Tema nuevo en cada retro: Cada día sale un tema diferente, y el anterior ya no es importante. Y por eso no se ha hecho nada de lo que se acordó en la anterior retro. Haz consciente al grupo de que algunas mejoras llevan tiempo. También que es mejor enfocarse y no atacar todo a la vez. Si las necesidades parecen cambiar de prioridad, seguramente te falta llegar al fondo de estas necesidades. Utiliza 5 whys o diagramas fishbone en estos casos.
  • Silencio: Pocos participan. El Scrum Master pide opinión y nadie contesta, o las respuestas son escasas y/o superficiales. En ese caso probablemente exista falta de confianza. Lee la Prime Directive al inicio de la retrospectiva y asegúrate que cumplir la regla de Las Vegas, lo que se habla en la retro queda en la retro. También puede ser consecuencia de un historial de retros ineficientes.
  • Blame game: Todo es negativo siempre. Todo son quejas. La culpa suele buscarse fuera, pero pueden haber acusaciones incluso entre los propios miembros del equipo. En este caso se puede recurrir a la Prime Directive nuevamente.
  • Starring…: Siempre hablan los mismos. Aunque se pide opinión a todo el equipo, incluso de forma explícita, el 90% del tiempo de discusión lo acaparan unos pocos. En este caso, busca dinámicas que eviten esto, como rondas, constelaciones, speed dating, 25/10 Crowd Sourcing o Dot Voting.
  • HIPPO o Facipulador: El Product Owner, stakeholder, jefe de turno o incluso el Scrum Master traen ya una agenda de los temas a hablar. No hará falta mucho consenso para decidir las acciones, pues también vendrán prescritas. El Scrum Master deberá vetar la entrada a la retrospectiva a cualquiera fuera del equipo Scrum, y hablar con el Product Owner para que entienda que es uno más del equipo, igual que su opinión.
  • Product Owner desaparecido: Al no ir a la retrospectiva ni aporta su opinión ni es parte del compromiso en las acciones. Puede terminar en un blame game dev team vs PO. Dale visibilidad del tipo de conversaciones que se dan en las retros. Si no es suficiente, trata de identificar algunas posibles mejoras en temas que le toquen de cerca e invítalo a tratar estos temas con el equipo.
  • El día de la marmota v2: Siempre se usa la misma dinámica de retro (claro, es la que viene en la template de confluence). El aburrimiento no tarda en llegar. La solución es sencilla, utiliza dinámicas que hagan al equipo pensar diferente para obtener resultados diferentes. Retromat es un buen sitio para empezar con esto.
  • No dejes para hoy lo que puedas hacer en la retro: Cualquier cambio es postergado a la retro. Atento a frases como “esto es mejor hablarlo en la retro” o similares. Como agente de cambio no permitas desperdiciar estas oportunidades de mejora, sobre todo si son decisiones fáciles y rápidas de tomar. Se llama mejora continua por algo.
  • Retrospectiva buffer: Solo se hace si hay tiempo al final del Sprint. Si han quedado cosas pendientes se cancela la retro. Otras variantes es acortar la retro y dejarla con un tiempo ridículo, o hacer la retro pero con la gente pendientes de otras cosas “más importantes”. En este caso, tu problema raíz probablemente sea que la gente en realidad no ve valor en las retrospectivas. Busca un espacio lo antes posible para hablar esto con el equipo y para crear un plan infalible para que en la próxima retro se aproveche bien el tiempo. Identifica otros antipatrones para buscar medidas adicionales.
  • Víctimas: Opuesto del balones fuera. En esta retro solo se tratan temas locales del equipo porque se siente que lo de fuera no tiene remedio. Probablemente se han repetido los temas durante un tiempo y en realidad no se ha hecho nada con ellos. Haz consciente al equipo del tipo de medidas que se pueden plantear para atacar estos temas, haz seguimiento de las acciones acordadas y sobre todo da visibilidad al equipo de las acciones que sí se llevan a cabo y de las mejoras obtenidas.

Antipatrones en retrospectivas Scrum

Soy consciente de que habrán muchos más, pero he preferido quedarme en una lista manejable y legible. Espero que te haya resultado interesante y útil.

Si crees que me he dejado alguno importante no dudes en comentar y gustosamente retocaré lo que haga falta.

Antes de despedirme, quiero dar las gracias a Andrés Mumenthaler por su contribución directa e indirecta a este artículo. Más de la mitad de esta lista viene de una forma u otra de alguna enseñanza suya 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *