Cómo hacer una reunión retrospectiva muy productiva

Cómo hacer una reunión retrospectiva muy productiva

Es posible que existan tantas formas de conducir las reuniones retrospectivas como equipos existen en el mundo. Hoy intentaremos describir una buena fórmula para hacer de la reunión retrospectiva una reunión muy productiva y beneficiosa para el rendimiento del equipo.

Scrum define un conjunto de reuniones para crear dinámicas más positivas y potenciar el rendimiento del equipo. La reunión retrospectiva es la reunión que se realiza al final de todo sprint. Esta reunión tiene como objetivo trabajar de forma colectiva en la mejora continua del proceso. En concreto el propósito de esta reunión es:

  • Inspeccionar cómo fue el último sprint en cuanto a personas, relaciones, procesos y herramientas.
  • Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras.
  • Crear un plan para implementar las mejoras en la forma en la que el equipo desempeña su trabajo.

Para empezar todo integrante del equipo debería responder a las preguntas:

Qué deberíamos empezar a hacer al siguiente sprint?

En este punto entran todas las cosas innovadoras o que por cierta curiosidad queremos probar. Puede que sean soluciones comprobadas que intuímos que deberíamos usar.

Qué deberíamos hacer más?

Este punto alimenta los puntos de la pregunta anterior de sprints anteriores. Es el espacio para todas aquellas cosas que estamos haciendo o usando y que queremos que mejoren. Son prácticas que creemos que requieren más refinamiento y que nos gustan mucho.

Qué deberíamos continuar haciendo durante el siguiente sprint?

Como secuencia lógica de la etapa anterior llega el nivel de maduración. Estamos en el punto de continuar haciendo. Son aquellas cosas que venimos haciendo y que nos brindan valor. Son puntos que debemos seguir haciendo pero que no es una preocupación actual mejorarlo, está bien como está.

Qué deberíamos hacer menos?

Ahora aparecerán aquellas cosas que en su día fueron respuesta al qué deberíamos empezar hacer pero que no nos generan el valor esperado. Es el momento en el que le damos una segunda oportunidad pero empezamos a ser conscientes que tal vez no nos funcionen. También pueden entrar algunos puntos burocráticos que el equipo debe hacer y que no aportan valor.

Que deberíamos dejar de hacer al siguiente sprint?

En este punto seleccionamos las cosas que llevan unos sprints en la etapa anterior y que podemos eliminarlas. El equipo debe tener la autonomía de ver si una práctica no le aporta valor o no le gusta optar por eliminarla.

Estamos hablando de una reunión muy orientada a mejorar la forma de actuar del equipo. No estamos planteando una reunión centrada en los sentimientos. Tampoco se centra en como nos hemos sentido durante el desarrollo del sprint. Cada una de las ideas generadas van directamente relacionadas al comportamiento. El equipo escogerá empezar a hacer alguna cosa, dejar de hacerla o continuar haciéndola.

Es muy probable que muchos de vosotros estéis pensando que es importante trabajar primero en los sentimientos de las personas. Incluso algunos consideráis que no podemos saber cómo mejorar sin haber tratado antes cómo se sienten las personas. Es cierto. Conducir la reunión de una forma tan operativa responde a dos puntos. Por un lado en muchos casos podemos identificar qué hacer directamente y por el otro no siempre es posible trabajar en los sentimientos de las personas.

Al final de la retrospectiva, para que el equipo mejore, deberíamos haber identificado las mejoras a implementar en el siguiente sprint. El hecho de implementarlas provoca que el equipo pueda ser autocrítico en busca de la mejora en el proceso. Crearemos un sistema enfocado a la autoinspección y adaptación constante.

Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!

También te puede interesar...
Pitu Sabadí
Pitu Sabadí
TDD and Agile enthusiast - CEO at Pease Networks

CEO en Please Networks. Fullstack developer y believer en la vida real. Me gusta el trabajo en equipo y conseguir objetivos colectivos. Desarrollando con PHP y AngularJS. AWS para la infraestructura. Amante del agile y el TDD. Training Cloud y Scrumízate mis proyectos personales.