RETROSPECTIVAS Y LA IMPORTANCIA DE ESCUCHAR A LOS DESARROLLADORES

¿Que son las retrospectivas?

Consiste en una reunión del equipo de desarrollo dentro de las metodologías ágiles, para analizar dos iteraciones con el objetivo principal de mejorar el proceso de desarrollo. La reunión se utiliza para analizar la última iteración y reflexionar sobre ella y buscar acciones de mejora.

El foco principal de las retrospectivas es el equipo de desarrollo, analizando su manera de trabajar, preguntando por qué se han llegado o no a los objetivos de la iteración y por qué la versión entregada era lo que se esperaba o no.

Dentro de la reunión, el equipo debe responder principalmente a 3 puntos:

1. ¿Qué cosas han funcionado bien?

Es importante en las retrospectivas no centrarse solo en lo que ha ido mal durante la iteración. Analizar qué ha funcionado bien permitirá detectar puntos a potenciar o acciones que se deberán seguir realizando.

2. ¿Cuáles hay que mejorar?

El equipo debe identificar los principales problemas con los que se ha encontrado, no para buscar culpables, sino para encontrar soluciones. Entre todos los problemas encontrados, se debe votar para identificar aquellos problemas más importantes. Sobre estos problemas se desarrollará el plan de acción.

3. Plan de acción

El equipo buscará soluciones que el mismo equipo pueda realizar para resolver los problemas. Se trata de un compromiso que marcará la actuación del equipo o nuevas tareas que deberán ser añadidas en las nuevas iteraciones.

Problemas habituales en las retrospectivas

1. Obviar problemas

Muchas veces se obvian los problemas en las retrospectivas debido a que existen atajos para mitigarlos, porque parece no tener una solución sencilla o porque toca temas sensibles. Si se da alguna de estas situaciones, el scrum master deberá realizar preguntas abiertas intentando que surja el problema pero sin forzar la situación.

2. No escuchar al equipo

En algunas reuniones he observado que el scrum master o el product owner no le da importancia a algún problema concreto, incluso aunque todo el equipo esté de acuerdo. Esto puede ocurrir porque desde su punto de vista no es un problema real o le da menos importancia de la que le da el equipo. Para evitar esto hay que recordar que los problemas deben ser votados de forma democrática por todos sin importar su rol.

3. No dedicar suficiente tiempo

Las retrospectivas suelen tener un tiempo asignado para realizar la reunión (normalmente 2 horas). Es muy importante que si durante una reunión han salido problemas importantes se dedique el tiempo necesario a analizarlos en lugar de intentar cumplir la agenda. El tiempo dedicado a estos problemas va a ser el más productivo que se va a dedicar en la reunión.

4. Personalizar problemas

Los problemas con los que nos encontramos no afectan al equipo por igual. Es importante no señalar a la persona que se encontró el problema o a la que lo causó, sino recordar que se trata de un trabajo en equipo y todo el equipo es responsable de los resultados.

5. Monopolizar la reunión

Por el carácter de las personas, por su experiencia o por su relación con el resto, no todo el mundo participa igual en estas reuniones. Muchas veces se da el caso de encontrarnos con una persona que participa constantemente mientas que otras apenas dan su opinión. Es labor del scrum master balancear la reunión, dejando que todo el mundo escriba los puntos necesarios o moderando los turnos de palabra.

6. Minusvalorar opiniones contrarias

Es muy importante escuchar a todo el mundo y valorar lo que tienen que aportar. Si una de las personas del equipo siente que se menosprecian sus opiniones puede acabar por no exponer sus propios problemas y por lo tanto, que se dificulte en resolverlos o incluso que empeoren las relaciones de los miembros del equipo.

Retrospectivas fuera de las metodologías ágiles

Una de las mayores críticas al modelo en cascada es que la linealidad de los desarrollos evita que se pueda presentar feedback temprano en el desarrollo. Actualmente es bastante frecuente que en este tipo de proyectos se trabaje con prototipos, para que el usuario tenga un acceso temprano a los desarrollos. Sin embargo, en este tipo de proyectos se suele pedir feedback de los desarrolladores al final de la fase de desarrollo (y no siempre).

Aunque las reuniones de retrospectivas están muy ligadas a metodologías ágiles y a una estructura de equipo más homogeneizada, la filosofía de las retrospectivas debe poder abordarse en todo tipo de proyectos. Los 3 puntos principales (qué ha ido bien, qué se puede mejorar y acciones) se pueden realizar en un proyecto en cascada para intentar identificar riesgos más ligados al desarrollo del proyecto. La frecuencia con la que se podrá realizar, las acciones que se podrán tomar y la efectividad de las reuniones dependerán del tipo de proyecto, del equipo que lo forme, sus roles, etc. La idea principal es preguntar al equipo de desarrollo para mejorar la calidad del proyecto, la productividad y por lo tanto, la calidad de vida de todos los implicados.