La Sprint Retrospective es uno de los elementos clave de Scrum y posiblemente uno de los más denostados. Muchos equipos han acabado en retrospectivas sin futuro que apenas les servían para evolucionar y que se acaban convirtiendo en un “baño de lágrimas”. Ahora bien, sabemos que la Sprint Retrospective es un elemento clave para la mejora continua. ¡Os damos varios trucos clave!
Consejo 1: Tener un Propósito
El objetivo de una Retrospectiva es conseguir mejorar algún aspecto del equipo. Cuando nos enfrentamos a problemas complejos existen múltiples maneras de trabajar y de organizarse. No existe la mejor “manera de trabajar” sino que tenemos que ir buscando lo que nos funciona paso a paso. Los equipos cambian continuamente en su composición, propósito, contexto y cliente lo que provoca que cada uno de ellos sea único y que tenga que encontrar sus propias formas de trabajo.
El propósito de la Sprint Retrospective es facilitar un espacio en el que podamos tratar aquellas elementos que no están funcionando y buscar nuevas soluciones.
Es cierto que los equipos a veces entran en un punto muerto donde apenas consiguen mejorar. En estos casos, aconsejo espaciar las respectivas pero nunca evitamos el tener ese pequeño espacio de reflexión grupal como punto de mejora.
Consejo 2: Mejora poco a poco
Un error típico de los equipos cuando arrancan es el tratar de solucionar todos sus problemas en la primera Sprint Retrospective. Es clave en una retrospectiva tratar de buscar algún punto de mejora e ir iterando.
La retrospectiva es una herramienta de mejora continua que nos va a acompañar a largo plazo y en cada momento podemos ir probando nuevas ideas. Lo importante es estudiar aquel elemento clave que podemos cambiar más rápido y que creamos que nos va a dar un mayor impacto.
Existen equipos que por norma solo introducen un cambio en cada retrospectiva con el ánimo de poder evaluarlo de manera independiente.
Consejo 3: Métrica de rendimiento
Las métricas de rendimiento de un equipo son útiles en una retrospectiva, de hecho son el mejor momento para utilizarlas. El rendimiento muchas veces toca los subjetivo y solo un equipo puede entender esas métricas.
He visto a muchas empresas utilizar este tipo de métricas para evaluar a los diferentes equipos cometiendo un gran error de sesgo. Estas métricas son ideales para que un equipo reflexione sobre cómo está trabajando y busque acuerdos de mejora. Incluso cuando en un equipo una métrica de rendimiento señala a un compañero o compañera es el propio equipo el que debe de buscar la manera de solucionarlo aunque sea expulsando al miembro del equipo.
Recordemos que el objetivo final de una respectiva es la entrega de valor y esto supone un mayor impacto en negocio. La Sprint Review la utilizamos para analizar ese impacto negocio pero es en la Sprint Retrospective donde tenemos que alcanzar nuevas maneras de funcionar que también contribuyan a ese impacto.
Por ejemplo, buscar maneras de acelerar la entrega de valor o la comunicación entre los requisitos y la entrega.
Consejo 4: De qué podemos hablar
Está claro que las personas son importantes y su salud mental y estado moral es esencial para el rendimiento de un equipo. Pero los equipos utilizan herramientas y esas herramientas se pueden inspeccionar en la respectiva para buscar adaptaciones que nos faciliten un mejor trabajo.
La respectiva ayuda mucho a la definición de done, por ejemplo, que marca el cómo queremos trabajar. Podemos analizar nuestras herramientas como Jira, excel o trello. Incluso podemos analizar los informes y los diferentes reportes que nos solicitan el negocio. Todas las herramientas forman parte de nuestra manera de trabajar y analizar cómo están funcionando y puntos de mejora es clave en nuestro objetivo. No hace falta que en todas las respectivas cambiamos las herramientas pero sí que de vez en cuando lo podamos inspeccionar.
Consejo 5: Fluye con lo que no puedas cambiar
Por último, hay equipos que abandonan la perspectiva cuando llegan a un momento en el que les cuesta ver puntos de mejora. Esto pasa porque los elementos que más daño y dolor les hacen dependen de personas ajenas al equipo. Tenemos que empezar a aprender a convivir con aquellos elementos dentro contexto que no podemos cambiar. Si yo vivo en una zona lluviosa tengo que aceptar que va a llover.
Es por esto que este tipo de elementos hay que transparentarlos, hay que hablarlos pero hay momentos en los que tenemos que aparcarlos para centrarnos en aquellos que sí podemos cambiar.
No podemos evitar que mi cliente me llame a primera hora exigiendo cambios pero sí que puedo medir esos cambios y tratar de buscar a su responsable para hacerle entender que tanta modificación tiene un impacto muy negativo en el equipo.
Es decir, siempre podemos buscar nuevas formas que nos faciliten el trabajo y que nos ayuden a mejorar.
Usen siempre los momentos de retrospectiva aunque no sean formales para recibir feedback y buscar puntos de mejora evitemos quedarnos en las críticas y avancemos hacia la acción.
Y tú ¿qué consejos darías para una buena retrospectiva?
En lo personal, me gusta explorar las áreas de lo que «hicimos bien» y lo que «no hicimos tan bien» con preguntas abiertas al equipo para que cada uno me responda desde su perspectiva.
En ocasiones llegamos a tocar un par de puntos de cuestiones técnicas (ingenieros de software al fin) de forma muy breve (pongo toda mi energía para que no se extienda). Trato de enfocar la mayoría del ejercicio a mejoras en cómo estamos implementando Scrum y la interacción en el equipo.
¡Buen artículo!