Cómo hacer efectiva la mejora continua a través de la Retro en Scrum

Actualizado: jul 8



Si te lo perdiste, puedes escuchar la TALK ahora!



¿De qué tema hablar en momentos como este que estamos viviendo?... Esa fue la duda que me surgió cuando tuve que elegir mi BuiltAgileTALK…


Si tuviera que relacionar lo que estamos viviendo en estos momentos con la agilidad, uno de los aspectos que me saltan rápidamente a la cabeza es la RETRO. Y por qué? El estar confinados nos lleva, irremediablemente a la reflexión. A parar y a pensar y reflexionar sobre mucho de los hacemos. Y sí, lo mismo sucede en el día a día de los equipos ágiles, tan enfocados en producir, en avanzar, en cumplir con los requisitos del cliente, en aportar valor… Y todo eso está muy bien pero, porque siempre hay un pero, y es que debemos de parar, de vez en cuando, para reflexionar y para saber, no sólo si vamos en buena dirección sino también que en ese transitar también lo estamos haciendo correctamente.


Y por esta razón, hoy más que nunca, la retrospectiva cobra un papel fundamental para nuestros equipos y nuestras organizaciones. Porque la retrospectiva es, a la postre, el evento que nos permite saber si estamos yendo -como equipo- por el camino correcto y de manera correcta. Y para realizar una buena retro quisiera compartir con todos 2 puntos fundamentales, sobre los que más tarde ahondaré:


  1. Relación del Ciclo de Deming de Mejora Continua con los eventos de SCRUM en especial la RETRO.

  2. 5 consejos para mejorar la retro como punto de mejora


Respecto al punto 1 y partiendo de la base de que todas las empresas siguen “o debería de seguir” los principios LEAN de la Mejora Continua. Y la manera sencilla de explicaros como trabajar y como poner en marcha la mejora continua es a través del ciclo de Deming también conocido como Ciclo Plan-Do-Check-Act (PDCA). Podemos relacionar ciertos evento de SCRUM con cada una de las fases del ciclo PDCA, en este caso y para este artículo, vincularemos el evento de la retro con la fase de Act del ciclo de mejora.


La restrospectiva es el evento más importante que tenemos en la gestión ágil. Y dudaré en defender esta idea. Utilicemos tanto el marco SCRUM como cualquier otro marco de trabajo. Y en mi experiencia (y estoy segura que en la experiencia de muchos de lo que leéis esto) es el evento que menos importancia le damos y peor hacemos -en el mejor de los casos-, porque a veces, ni la hacemos.


No existe mejora si no somos capaces de hacer todas las fases del PDCA, y por tanto, no hay mejora en un proyecto/equipo ágil si no hacemos la retro. Y cuando hablamos de mejorar, y acordémonos de mi obsesión (y los que me conocen lo saben) y la que deberían de tener todos los que trabajan en proyectos y en equipo es en incrementar el APORTE DE VALOR y en ELMINAR DESPERDICIOS.





Respecto al punto 2, a continuación, vamos a describir una serie de consejos que la experiencia me han demostrado fundamentales a la hora de preparar y realizar una buena retrospectiva. Lo he llamado “Los 5 fundamentales para hacer una retro”. Comencemos


1. Establecer un TIME BOX. Y cumplirlo. Cuando tenemos un evento, sea de la naturaleza que sea, debemos de acordar un tiempo y este tiempo se tiene que cumplir sí o s. Y esto no es una. Cuestión menor, porque nada hace más improductivas las reuniones que tener la creencia de que no sirven para mucho porque se pierde mucho el tiempo. Aquí el problema nace que como desgraciadamente la retro no es un evento de entrega de valor directa al cliente y sí de mejora para posterior entrega de valor -pero no en el momento-, desgraciadamente, no le damos la suficiente importancia y vamos más a cubrir el expediente, a filosofear, a sacar temas que deberían de abordarse en otros foros, etc, y el tiempo pasa y pasa y nada sacamos en claro de la retro… Importante, el primer pinto para darle importancia y entidad a una reunión es ser rigurosos con el tiempo de la misma. Así que no olvidar que al comenzar la retro (y previamente informados en la convocatoria) se recuerda el time box establecido y la necesidad de ser rigurosos con él.


2. Definir claramente el OBJETIVO DE LA RETRO. Vuelvo a repetir que -bajo mi opinión- es el evento más importante en la cultura agile… Pero este evento, adquirirá la importancia que se merece si definimos perfectamente el objetivo de la misma. La experiencia me dice que no hay mejor objetivo para trabajar la mejora que trabajar sobre los desperdicios que todos los equipos tenemos en nuestro día a día. Es decir; encontrar DESPERIDICIOS para eliminarlos con el claro objetivo de mejorar la eficacia y la eficiencia del equipo. Y una buena pregunta que nos debemos hacer como equipo para detectar desperdicios es: ¿Qué es lo que está doliendo al equipo?


Detallo algunos dolores propios que aparecen durante las retros. Y las he dividido en dolores hard y en dolores soft.


Algunos dolores HARD:

  1. Historias de usuario poco definidas o mal definida por el PO (falta de DOD), por lo que cuando entran a producción (es decir al sprint) pueden generar bloqueos.

  2. Mala estimación del equipo de las historias. Y derivado de ello, generar agobios por no llegar a terminar el sprint.

  3. Falta de sprint goal. El backlog es un cajón desastre y no sabemos hacía dónde vamos… Tenemos mil cosas para hacer y sin foco definido.

  4. La peor de todas, y muchas veces pasa, es que todos trabajen mucho más que pensar en generar valor…

  5. Falta de conocimientos o suficiente expertise en un tema puntual…


Algunos dolores SOFT:

a- Falta de responsabilidad colectiva y/o excesivo individualismo.

b- Dejar que los stakeholdes interrumpan nuestra marcha en el día a día con nuevos requerimientos. Tener reuniones en paralelo para informar a los stakeholders.

c- Tomar decisiones de manera unilateral sin consultar con el PO

d- Mala comunicación entre los miembros del equipo y escasa capacidad para converger ante la divergencia de posturas, opiniones, etc.



3. La dinámica de grupo durante la retro no es el fin sino el medio. OJO con la DINÁMICA a realizar. A todos nos encanta y nos gusta hacer dinámicas divertidas y entretenidas. Mejor divertirse que no. Pero no podemos caer en la trampa de confundir el qué con el cómo. El objetivo de la retro bien definido no es la dinámica en sí mismo, sino que la dinámica es un medio, es un camino para alcanzar ese objetivo… No es cuestión de pegar post it por bonitos que queden en la pared y en las fotos. Si hay que hacerlo se hace, pero se hace porque cumple con el objetivo que perseguimos.


Por ello y para definir y establecer la mejor dinámica a utilizar en una retro, debemos de tener en conocimiento un par de aspectos previamente:

  • El nivel de madurez del equipo -basado en lo niveles de Tuckman-. Obviamente, no es lo mismo trabajar una retro en un equipo que se encuentra en la fase de divergencia y conflicto que un equipo que ya está en la fase normativa. Para cada fase unas dinámicas son más apropiadas que otras.

  • Y, no menor, aunque el objetivo macro sea el identificar desperdicios, no es lo mismo trabajar dolores hard que dolores soft.





4. Obtener y definir, AL MENOS, UN EXPERIMENTO, UNA ACCION… Y su posterior PUESTA EN MARCHA. En el tiempo que tenemos y con el objetivo claramente establecido, tenemos la obligación de definir, al menos, una acción o experimento que nos ayude a solucionar algún dolor o desperdicio. Y digo al menos uno, ojalá podamos más, porque no podemos salir de una retro sin una acción de mejora a implantar. Porque toda retro que no termine con una acción a eliminar es un dolor en sí mismo y esa retro se habrá convertido en sí mismos en un desperdicio. Es decir, no habrá servido de nada. Un retro sin acción o acciones posteriores es como un precioso coche sin gasolina.


Y estas acciones o experimentos deben de ser lo más pequeño posible… Y, puestos a pedir y si es posible, que puedan ser realizados en el siguiente sprint para poder confirmar su eficacia y mejora en la siguiente retro.


5. Debemos de ESTAR TODOS y eso incluye al PO… No tiene sentido hacer una retro si no participan todos los miembros del equipo. Y por supuesto el PO, aunque esto último pueda generar ciertas reticencias. Pero bajo el principio de transparencia, y así ya lo indican las guías (tanto de scrummanager, como scrum.org y la Alliance) tras las nuevas revisiones, es muy aconsejable la participación del PO en la retro.








540 vistas

Contacto

Tel: 661 786 620

Mail: agile@builtagile.com

© 2019 BuiltAgile

  • Blanco Icono de Instagram
  • Blanco Icono LinkedIn
Suscríbete a nuestra newsletter