Por Alcibíades Cabral y Félix Bragado
Muchos equipos asocian la retrospectiva con el momento de jugar y hacer dinámicas, sin saber muy bien para qué están haciendo una dinámica concreta ni por qué invertir tiempo en este evento. Por eso suele ser el primer evento que se elimina cuando el deadline se acerca o hay más bugs que evolutivos en nuestro Product Backlog (otro día hablaremos por qué en un Scrum Team, ni lo uno ni lo otro debe existir tal y como lo conocemos)
Precisamente, para cualquier agilista que se precie, un equipo que ha eliminado la retrospectiva de sus eventos huele a todo menos a Alto Rendimiento.
Cómo siempre digo, puede que estés leyendo este artículo por dos motivos:
a. Porque, en esta ocasión, mi compañero Felix Bragado te lo haya compartido.
b. Porque estés buscando dinámicas para la retrospectiva que tienes dentro de dos días. (Spoiler: en este post no las vas a encontrar)
Por suerte, aquí y ahora, vamos a abordar:
- ¿De donde viene la retrospectiva y que relación tiene con el Agile Manifesto?
- ¿Que persigue?
- ¿Por qué es un gran error su eliminación cuando algo va mal?
Empecemos!
¿De donde viene la retrospectiva y que relación tiene con el Agile Manifesto?
Es bueno que nos pongamos en contexto y entendamos por qué Scrum incorpora un evento con un nada despreciable timebox de 3 horas dentro del framework. Para ello, deberemos desempolvar nuestro Agile Manifesto, y situar nuestro índice sobre el principio nº 12.
Cómo aquellos lectores familiarizados sabréis, y nunca me cansaré de repetir, Agile NO es una metodología, es un mindset formado por 4 valores y 12 principios que se encuentran alineados con multitud de frameworks, entre ellos Scrum (qué por cierto, es anterior al Agile Manifesto)
Precisamente, el último principio del Manifiesto enlaza directamente con la Retrospectiva, o dicho de otro modo, la retrospectiva es el evento que tiene el Scrum Team para Reflexionar y Ajustar.
¿Os suena el término Kaizen?
¿Que persigue la Retrospectiva?
Tal y como nos indica la Scrum Guide, el propósito de la restropectiva 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 a la forma en la que el Equipo Scrum desempeña su trabajo.
Es importante tener en cuenta que, a partir de la versión de 2017 de la Guía de Scrum, es obligatorio que al menos un ítem de mejora forme parte directamente del siguiente Sprint Backlog.
¿Por qué es un gran error su eliminación cuando algo va mal?
Dicho todo lo anterior, al eliminarlo debido a falta de tiempo o al requerir mayor dedicación a la corrección de errores, no estamos dando al equipo el espacio y el tiempo necesarios para inspeccionar y adaptar como están trabajando, y eso sólo puede llevarnos a más incumplimientos y más errores (círculo vicioso)
Por cierto, en Scrum no está prescrito que deba realizarse este evento a través de dinámicas con post-it y gomets. No obstante, esta es la mejor forma de generarentendimiento compartido y poner foco durante la sesión en nuestras fortalezas y debilidades.
Si eres Scrum Master, siempre debes plantearte que es necesario inspeccionar y posteriormente buscar una dinámica que tenga ese propósito, nunca al revés. Si tu foco es innovar en tus dinámicas, cambiarlas constantemente y hacerlas cada vez más vistosas y divertidas, por encima de reflexionar y ajustar con el equipo con un propósito concreto, obtendrás una fotos muy chulas al finalizar la sesión pero nada de mejora continúa.
Un buen Scrum Master debe plantearse qué necesita el equipo en cada momento a la hora de elegir la mejor forma de guiar la retrospectiva. Al formar parte del equipo, el Scrum Master conoce de primera mano los diferentes problemas que han ocurrido durante el Sprint y debe destinar parte de la sesión a guiar al equipo en la inspección de esos problemas. Pongamos varios ejemplos:
En cierto equipo Scrum, el Scrum Master observó durante el sprint que había una clara división en el Development Team por silos de conocimiento. Dependiendo del área de actuación que tenían los desarrolladores, Front o Back, se posicionaban a defender su trabajo aunque ello perjudicara al incremento entregado al final del sprint. Además, en las dailys se escuchaban frases como "Lo mío esta hecho" o "Es que tu parte no encaja bien con mi desarrollo". En particular, una persona estaba sufriendo en su trabajo diario este enfrentamiento y estaba pasándolo mal a nivel personal. Durante el Sprint el Scrum Master hizo una sesión de coaching individual con esta persona y, con las conclusiones, una sesión de coaching grupal breve. En ese caso, el objetivo era cohesionar al equipo de forma inmediata, por lo que se añadió a la retrospectiva una dinámica de cohesión de equipo que ayudara a tener un equipo más integrado y reducir los conflictos internos. En la retrospectiva se encontraron ideas para mejorar el ambiente y se eligieron las más prometedoras para implantarlas durante el siguiente sprint. El objetivo de esta retrospectiva era cohesionar el equipo, para avanzar en mejorar el rendimiento del mismo siempre teniendo en cuenta que la calidad no es negociable.
En otro equipo Scrum, el incremento entregado después de un sprint fue casi nulo por no haber terminado casi ninguna de las Historias de Usuario comprometidas. El Scrum Master usó la dinámica del Barco de Vela para ofrecer una oportunidad al equipo de expresarse y detectar qué había ido mal durante el sprint, con la conclusión de obtener un incremento tan pequeño. En la sesión se detectaron muchos puntos de mejora y de ellos se eligió, de forma consensuada entre todo el equipo, que la calidad del contenido de las Historias de Usuario era baja, que las estimaciones asociadas a las historias habían resultado ser erróneas y que el equipo necesitaba ser más transparente en las dailys para evitar bloqueos. Para mejorar se decidió usar el patrón de Business Driven Development en el desarrollo de las historias de usuario, mejorar la calidad del tiempo dedicado en la sprint Planning a aclarar el contenido de las Historias, realizar sesiones de refinamiento dentro del sprint para tener una visión más clara del producto a desarrollar y ser más transparentes en las Dailys de cara a evitar impedimentos que retrasen el trabajo. El objetivo de esta retrospectiva era buscar los motivos por los que el incremento había sido tan bajo y darles solución en el siguiente sprint.
En general, a nuestro equipo nos gusta ver las retros como un triángulo cuyos vértices serían:
(1) Una parte inicial en la cual se crea el clima adecuado para que el equipo se sitúe respecto a las situaciones vividas en el sprint y a aquello que en opinión de cada uno debe adaptarse. Para ello es bueno dejar unos minutos para que:
- Individualmente cada persona del equipo piense, por ejemplo, en el mejor y en el peor momento del sprint
- Grupalmente los miembros del equipo construyan una línea de tiempo con "momentos destacados" del sprint para celebrar los éxitos o detectar las oportunidades de mejora.
- Cualquier técnica que permita que el equipo se ponga en situación
(2) Una vez que estamos situados, mediante alguna dinámica se facilita el afloramiento de los aspectos a potenciar o a mejorar
(3) Para terminar se consensúa un plan de acción
Por supuesto en una retro siempre debería revisarse el estado de las acciones de mejora ya emprendidas en sprints anteriores y si nos han permitido mejorar como equipo.