Los 11 males más comunes de las retrospectivas en escalados.

Después de 3 años como Scrum Master en un escalado Nexus, me sorprendí a mí misma buscando en Google: “cómo hacer una retrospectiva con varios equipos”. No es que no haya facilitado nunca una retrospectiva, es que mi barra de marcadores está llena de links a dinámicas, trucos, artículos y post. ¿La tuya no?

Si quieres trabajar de manera agile, pero dejas de investigar y experimentar, estarás olvidando algo tremendamente importante como es tratar de mejorar y tratar de ayudar al equipo de desarrollo a cumplir los objetivos y superarse cada sprint. Como comentaba mi compañera Fátima Casaú en su post 5 pasos para exprimir tus retrospectivas ágiles, “La mejora continua es uno de los principales valores de gestión ágil de proyectos”, y la retrospectiva es el evento, momento, oportunidad, que tenemos para analizar cómo lo estamos haciendo y cómo podemos mejorar.

Pero… ¿cuándo nos paramos a pensar en qué tal estamos haciendo la retrospectiva? Una retrospectiva de la retrospectiva nos permitirá analizar si son mejorables, si son productivas, si estamos teniendo problemas, y evitará el riesgo de que se convierta en un “evento obligatorio” que no nos aporte nada.

En este momento somos 5 equipos Scrum y un total de 45 personas en el escalado. Imaginaos la cantidad de problemas que pueden surgir a la hora de llevar a cabo la retrospectiva.

Once problemas en una retrospectiva de escalado y cómo mitigarlos

A la hora de planificar

Planificar la reunión de retrospectiva en equipos grandes es importante si queremos aprovecharla al máximo, y ya pueden surgir dudas o problemas en este punto:

1. ¿Cómo hago una retro con 45 personas?

Lo primero es que no es necesario hacer una retro con 45 personas. Para que resulte más eficiente, tanto el número de personas que asisten como el número de temas a tratar debe ser limitado.

Realizaremos la retrospectiva del escalado en dos partes (y no en tres como sugiere la guía Nexus). En la primera, cada equipo pequeño realizará su propia retrospectiva, añadiendo una reflexión extra en la que sacar temas/problemas/cuestiones que afecten a más de un equipo.

De esta reflexión pueden surgir muchos temas; sin embargo, es recomendable elegir 1 ó 2 por equipo mediante votación. De esta manera, aseguramos que los temas que se van a tratar son suficientemente importantes y acotamos un poco las cuestiones sobre las que centrarnos (ya sabéis el dicho: “quien mucho abarca, poco aprieta”).

La segunda parte, que podríamos llamar “retro conjunta”, es donde se exponen los temas de cada equipo, se debate y se elabora un plan de acción. La asistencia a la “retro conjunta” se limitará a, al menos, un representante de cada equipo como veremos a continuación.

2. ¿Cómo se decide quién va a la retro?

Si no vamos todos, ¿quién tiene que ir? La guía Nexus nos recomienda un representante por equipo, que explique/defienda los temas que quieren tratar, que proponga posibles soluciones y participe después en la toma de decisiones. En nuestro caso, además de los representantes de los equipos, asistimos todos los Scrum Masters y abrimos el evento para que acuda quien quiera.

Y ¿cómo elegimos el representante? Aquí podéis optar por la opción que más os encaje, se puede hacer un sorteo en cada sprint, se puede rotar la persona que por sprint se encarga de ir a los eventos (Manuel va a en calidad de representante este sprint y Lucía va el siguiente, etc), pero lo que sí os recomiendo es que todos los miembros vayan alguna vez.

3. Nadie quiere asistir

Puede ocurrir que el evento se convierta en algo repetitivo y poco productivo que todo el mundo quiera saltarse. Como en cualquier retro, se hace necesario recurrir a dinámicas diferentes y motivadoras y en las que puede ser necesario romper con lo cotidiano, sacando algún rato distendido que nos sirva, además, de team building (personalmente me encanta cualquier actividad que una al equipo y sirva de team building). Puede ser motivador aplicar métricas que conciencien al equipo de su propio estado y/o el del producto.

Durante el desarrollo del evento

Hemos hecho la retrospectiva en cada equipo, traemos uno o dos temas por equipo, empezamos la retro conjunta… y surgen más problemas.

4. No da tiempo a tratar todos los temas

A pesar de haber limitado el número de temas que cada equipo propone en la retro conjunta, podemos encontrarnos con demasiados asuntos. Podemos hacer de nuevo una votación para elegir un máximo de ‘n’ temas a tratar (en función del tiempo disponible para el evento). Sería bueno, además, llevar algún tipo de control sobre los asuntos aplazados para poder analizar si hay algún tema recurrente que no se ha llegado a tratar, y poder prestarle la atención adecuada.

Para seguir probando acciones que minimicen este problema, en mi equipo hemos puesto en marcha una nueva medida que es la clasificación de los temas candidatos en tres tipologías: express (se puede tratar en 15 minutos), crítico (es urgente tratarlo) o no crítico (no es rápido de tratar, ni urgente, pero sí nos preocupa) que pondremos en práctica en este sprint como parte de nuestro proceso de mejora continua.

5. Nos enrollamos en un tema y no avanzamos

Para atajar este problema, usamos timebox por tema. Si no se llega a consenso y es un tema importante, se convoca una reunión ad-hoc para tratarlo y poder buscar soluciones.

6. No llegamos a un acuerdo

Puede ser que, ni en el timebox destinado para tratar el tema en la retro conjunta ni en la reunión ad-hoc, nos pongamos de acuerdo en el plan de acción. En este caso, hay varias estrategias que se pueden llevar a cabo para la toma de decisiones y 5 formas de tomar una decisión, según el nivel de conflicto y en base a dos variables: asertividad y cooperación (más información y recomendada lectura de Conflictos en equipos ágiles: cómo mejorar tus habilidades de Pedro Revueltas). Si el ambiente es asertivo y colaborativo, se buscará y tomará por consenso la decisión que satisfaga las preocupaciones de todos.

7. Los temas a tratar en la retro conjunta no tienen como objetivo mejorar la productividad, ni las habilidades del equipo, ni la calidad del producto

A veces, los temas que se proponen en los equipos para tratar en la retro conjunta, son quejas o problemas mal enfocados. Durante la reflexión, podemos hacernos esta pregunta: ¿la resolución de este problema que planteo nos va a ayudar a mejorar en calidad, productividad o en habilidades sprint tras sprint? Si la respuesta es “no”, es un tema que no debería subir a la retro conjunta.

8. El tema a tratar en la retro conjunta no ha sido propuesto por el equipo de desarrollo

Puede ocurrir que los Scrum Master, con la mejor de las intenciones, quieran plantear una cuestión a tratar en la retro sin esperar a que los equipos propongan temas. Desde la experiencia, no recomiendo esta práctica para nada, porque correremos el riesgo de que el equipo de desarrollo sienta que se le imponen los temas y que se coarta su autoorganización y capacidad de decisión. Debe ser el equipo Scrum quien reflexione e identifique los cambios más útiles para mejorar su eficacia.

9. Problemas de comunicación

Ya que no todos asisten a la retro, el resto del equipo no sabe qué ha pasado. Como hemos comentado con anterioridad, podemos abrir el evento a quien quiera participar y, al mismo tiempo, compartir la información (problemas tratados y el plan de acción que se ha decidido tomar) en la siguiente daily y también por escrito a través de la herramienta que uséis para comunicaros (vía email, slack, confluence, la que mejor os funcione). Esto se hace más necesario hoy día con el trabajo en remoto.

A la hora de revisar…

Hemos conseguido terminar la retro conjunta con un plan de acción. En la siguiente retro conjunta, el primer paso será revisar las acciones que se decidieron tomar en la retro anterior:

10. Hacemos retro, sacamos acciones pero... llegamos a la siguiente retro sin haber cumplido

La razón de que esto ocurra puede ser diversa, pero es importante que las acciones tengan asignado un responsable de seguimiento y si, además, ponemos una fecha de vencimiento (due date), estaremos más cerca de garantizar su cumplimiento. Podemos ponernos un punto de revisión a lo largo del sprint, o incluso meterlo como tarea en nuestro sprint backlog para que esté presente en las conversaciones de cada daily. Y, desde luego, deberemos asegurarnos de que las acciones estén en nuestra mano. Es decir, no podemos acordar una acción que sea que un tercero tenga preparado su acuerdo de interfaz en fecha, porque no podremos hacer nada para conseguirlo y sólo nos generará frustración.

11. Sí: hacemos retros y seguimos las acciones, pero no mejoramos

Si estamos haciéndolo todo, ¿por qué esta sensación de pérdida de tiempo? Este problema es más frecuente de lo que podríamos pensar.

Para evitar que esto ocurra, en lugar de sacar un plan de acción podemos planteárnoslo como un experimento: formulamos cada acción en formato hipótesis y acordamos cuál es el objetivo o el resultado esperado.

Lo ideal es que estos objetivos sean SMART:

• (S) Específicos: ¿Qué queremos conseguir? ¿Cuál es el resultado esperado?
• (M) Medibles: ¿Qué indicadores podemos usar para medir si hemos alcanzado el resultado y en qué grado?
• (A) Alcanzables: ¿Es razonable y está en nuestra mano conseguirlo?
• (R) Relevantes: ¿Es interesante para el equipo? ¿Nos ayudará a mejorar?
• (T) En Tiempo: ¿Cuándo tendríamos que tenerlo?

A la hora de revisar la siguiente retro será más fácil analizar si la acción ha tenido el impacto esperado y, si no ha sido así, nos llevaremos el aprendizaje y podremos proponer hipótesis nuevas para lograr el objetivo.

De nuevo, el uso de métricas nos ayudará a visualizar si estamos teniendo el impacto deseado en nuestra productividad, nuestras habilidades y en la calidad del producto.

Conclusión

Hacer bien una retrospectiva es importante y difícil a partes iguales.

Aunque muchos de los problemas que hemos comentado pueden darse en cualquier tipo de retrospectiva sin importar el número de personas involucradas, a la hora de enfrentarse a una retrospectiva en escalado habrá que prestar especial atención a las siguientes medidas:

• Retrospectiva en dos fases: realizar el evento en dos fases (y no tres) nos permite mantener las retrospectivas en los equipos más pequeños, y centrarnos posteriormente en los temas que atañen a más de un equipo sin perder tiempo extra.
• Limitar número de personas, número de temas y tiempo dedicado a cada tema: conseguir una reunión más efectiva y eficiente, limitando el número de personas, tratando pocos temas pero realmente importantes y centrándonos en ellos al máximo en un tiempo acotado.
• Evitar decidir por el equipo de desarrollo: cuando se gestionan equipos grandes, puede ser tentador tomar decisiones sin consenso para evitar pérdidas de tiempo. Sin embargo, gestionando bien las reuniones conseguiremos que el equipo forme parte de todo el proceso y, así, la responsabilidad de la mejora continua será compartida.
• Mucha atención a la comunicación: que la información fluya por todo el equipo es extremadamente importante y difícil en equipos grandes, así que no perdamos nunca la ocasión de documentar y de hablar de todo lo que consideremos relevante.
• Aplicar métricas: medir para entender, medir para mejorar. Las métricas siempre son útiles para analizar cómo funciona el equipo, si las acciones que vamos tomando son adecuadas y si nos ayudan realmente a mejorar. En el caso de equipos grandes se convierten en imprescindibles.

Os recomiendo parar a reflexionar cuanto antes sobre el estado de salud de vuestras retrospectivas en escalado, poder poner remedio a los males y asegurar la mejora continua.