Retrospectivas ágiles

En el marco de trabajo Scrum se realizan diversas reuniones a lo largo de un Sprint, una de las que más valor aporta es la reunión Sprint Retrospective.

Estas reuniones pueden ser realizadas en metodologías o marcos ágiles, pero también se pueden realizar en otros desarrollos incrementales.

Las reuniones Sprint Retrospective se realizan al final del Sprint después de haber presentado la demo del incremento desarrollado al Product Owner y a los demás interesados.

No se puede predecir qué resultados se obtendrán en una retrospectiva, pero si se realizan adecuadamente y todos los miembros están involucrados siempre aportará valor al equipo, incluso si el equipo ya hace un buen trabajo.

Esta reunión se realiza con el objetivo de introducir mejoras en el siguiente Sprint mediante las que se conseguirá mejorar el trabajo en equipo y la satisfacción de sus miembros, se mejorarán los resultados y se aprenderá a manejar y solucionar problemas que puedan aparecer a lo largo de los Sprints para no volver a repetirlos.

Los miembros del equipo serán los encargados de revisar sus métodos y debatir que ha ido bien durante el Sprint, que fue mal y proponer mejoras.

 En cada Sprint pueden surgir muchas mejoras, el equipo debe priorizarlas y decidir alguna para introducir en el siguiente Sprint, es decir, ellos son los que se comprometen a realizar la mejora. Lo más recomendable es elegir una para poder llevarlo a cabo satisfactoriamente.

Las reuniones de Scrum Retrospective pueden estructurarse de la siguiente manera, lo que facilita que no se pase por alto algún aspecto importante y se tenga un orden en la manera de pensar que sucedió en el Sprint:

Lo primero que se debe fijar es un escenario, es decir se debe comunicar a los miembros del equipo el tiempo del que se dispone (estas reuniones tienen definido un time-box de duración que está en 1 hora por semana del Sprint, aunque puede ser orientativo en algunas ocasiones) y porqué se realizan estas reuniones y cómo se llevará a cabo. Normalmente se tiende a olvidar contar el porqué de las cosas y nos centramos más en el cómo. Es importante que los miembros del equipo conozcan porqué se llevan a cabo estas reuniones y el valor que aportan para que estén involucrados en estas y sientan necesidad de ellas. Es importante que los miembros del equipo conozcan el porqué de estas reuniones y cómo se realizarán. Se puede dedicar un tiempo para mostrar las mejoras que se han ido produciendo en los Sprints pasados gracias a las retrospectivas.

Si los miembros del equipo no se toman las retrospectivas en serio no serán muy útiles y todo seguirá igual en el siguiente Sprint.

Se debe crear un ambiente colaborativo para que a lo largo de la reunión fluyan las conversaciones entre ellos. Para ello se pueden realizar dinámicas iniciales en las que todos deban hablar para romper el hielo.

Una buena práctica es conocer brevemente las expectativas de cada miembro sobre esta retrospectiva, el tener una expectativa sobre la reunión hace que estas sean más útiles, para lo que contamos con diversas dinámicas.

Una vez que se presenta el escenario llega el momento de generar ideas, esta recopilación de datos muestra que sucedió durante el Sprint. Es realizada por todos los miembros del equipo. Para llevar a cabo la recolección de datos se pueden realizar diversas dinámicas, en las que cada miembro del equipo individualmente apunte su punto de vista y después realizar una puesta en común, lo que conseguiremos con esto es ampliar la perspectiva de lo que ha ocurrido.

Podemos recopilar datos sobre las reuniones que se han llevado a cabo, sobre las User Storys realizadas y tareas y otros aspectos que los miembros del equipo consideren importantes.

También son muy importantes los sentimientos, en las metodologías ágiles se da mucha importancia a las personas se los valora más que a los procesos y herramientas, por tanto, si nos fijamos o las personas nos cuentan cómo trabajaron, cómo se sintieron a lo largo del Sprint se puede crear un mejor ambiente de trabajo y realizar mejoras en los siguientes Sprints ya que conocemos lo que preocupa a los equipos. Existen diversas dinámicas que nos ayudarán a conocer cómo se sienten.

Una vez que tenemos recopiladas todas las ideas llega el momento de analizarlas y ver qué fue exitoso, qué fue mal y porqué se produjo. En esta parte se seleccionan algunos de los problemas que el equipo ha señalado y se piensan posibles soluciones mediante las que podemos mejorar.

Una vez que se tienen los problemas identificados y se han planteado las ideas de mejora que podemos aplicar en el siguiente Sprint.

Por último, cuando ya se ha decidido que mejora se realizará en el siguiente Sprint hay que poner final a la retrospectiva tiene que quedar claro el objetivo que se quiere conseguir en el siguiente Sprint y cómo se llevará a cabo. Es importante que estas mejoras estén identificadas y visibles a lo largo del Sprint para que los miembros del equipo no olviden trabajar para conseguir el objetivo que se fijó en la retrospectiva.

Al final de la retrospectiva podemos dedicar algunos minutos a realizar una retrospectiva de esta para que las siguientes sean más productivas y eficaces.

La labor del Scrum Master en esta reunión es apoyar, ayudar y guiar al equipo para que ellos sean capaces de identificar que ha ocurrido durante el Sprint y sepan identificar sus fortalezas y debilidades.

Las retrospectivas pueden ser guiadas por un Scrum Master o el Scrum master puede ceder la dirección de la retrospectiva a alguno de los miembros del equipo, o delegar alguna tarea.

El Scrum Master debe dejar que las conversaciones entre estos fluyan y evitar conducirlos a un resultado predeterminado. Debe dejar que los equipos debatan y descubran ellos solos ya que si ven por ellos mismos que los afecta se involucrarán más.

Para que las retrospectivas sean exitosas debemos tener en cuenta además algunos aspectos:

Los equipos deben ser participativos y deben comunicarse y conversar entre sí.

Todos los miembros del equipo deben intervenir, en muchas ocasiones pasará que alguien “lleve la voz cantante” y alguien permanezca cayado o intervenga poco, aquí la labor del Scrum master será hacer que esto cambie y enseñar a escuchar y a valorar las opiniones del resto de compañeros y a fomentar que todos participen y se sientan cómodos y valorados.

Para la comunicación del equipo se debe utilizar una conversación no violenta, evitando la culpabilidad y las quejas ya que son prácticas destructivas, todos son el equipo y los problemas o los fallos son de todos. En vez de invertir el tiempo en quejas y en buscar culpables lo que se debe hacer en la retrospectiva es buscar soluciones, tomar nota y trabajar para que no vuelva a suceder.

Para que una retrospectiva sea exitosa se puede tener acuerdos de trabajo, es decir, utilizar “normas” para que las retrospectivas no sean interrumpidas, evitar quejas y buscar culpables…

Lo conveniente es que, si se utilizan acuerdos de trabajo, sean definidos por los miembros del equipo, para que los sientan suyos, los acuerdos son la forma en la que quiere trabajar el equipo, ellos deben estar de acuerdo, estas “normas” no deben ser impuestas.

Siguiendo esta estructura y estos aspectos conseguimos q al principio el equipo esté motivado y que comprenda la utilidad de estas retrospectivas lo que hará que este se involucre en esta reunión. Después los miembros del equipo conocerán las diferentes opiniones y puntos de vista del resto de miembros del equipo de los temas tratados para entre todos decidir cuáles de los problemas o debilidades del equipo se van a mejorar en el siguiente Sprint y entre todos trazar un plan para conseguirlo.

No todos los equipos son iguales, por tanto, no todas las dinámicas ni todas las partes de la estructura funcionan bien para todos los equipos, es recomendable comenzar siguiendo esta estructura y después ir adaptándola a nuestras necesidades y nuestro equipo ya que hay que tener en cuenta que el equipo va a ir evolucionando y mejorando a lo largo de los Sprints.