El último de los 12 principios ágiles dice “A intervalos regulares, el equipo reflexiona en cómo volverse más efectivo, luego retoca y modifica sus comportamientos acordemente”
Está entonces claro que para poder llevar a cabo los valores ágiles el equipo debe regularmente validar y retocar lo que se requiera. Comúnmente el equipo de desarrollo quienes tienen regularmente estas reuniones, y aunque en este artículo veremos una forma de organizar una reunión de retrospectiva, la misma no tienen una única forma de hacerse.
Actualmente las retrospectivas se usan en todas las caras de negocio y rubros. Hacer retros en campaña de marketing, reuniones y presentaciones con la alta gerencia o el directorio, incluso en la vida personal como filosofía de vida.
La reunión de retrospectiva
Este momento clave es donde el equipo en conjunto reflexiona y evalúe oportunidades de mejora para las siguientes etapas, sprints, etc. La retrospectiva se basa en la mejora continua y evita que caigamos en el conformismo como, por ejemplo, no hacer la retrospectiva por que el equipo considera que ya trabaja bien.
El propósito de la retrospectiva básicamente es:
o Evaluar cómo le fue al equipo en el último sprint, iteración o tarea (work item).
o Separa las cosas que salieron bien y las que no.
o Crear e implementar el plan de mejora para el siguiente sprint.
La retrospectiva debe brindar un espacio seguro para enfocarse en la introspección, adaptación y mejora. Para que sea exitosa tiene que haber un ambiente donde la gente se sienta apoyada y animada para opinar lo que piensa.
La retrospectiva debe ser una experiencia positiva para los participantes, compartiendo el feedback de cada uno, deshacerse de las frustraciones y concentrarse en trabajar todos para proponer soluciones y mejoras. El facilitador puede obtener mucha información del equipo y cómo son las interacciones entre los miembros de este, como los desafíos individuales que tuvieron dentro del último sprint. En una retrospectiva exitosa, debe de terminar con una lista de las mejoras detectadas y como así el responsable de la mejora para trabajar en el siguiente sprint.
Acá, en lo particular, quiero aclarar que, en mi experiencia, no siempre el ambiente se presta para opinar, ya sea por la introversión de ciertos integrantes como el preconcepto de que si no es “jefe” o tiene un cargo no puede/debe opinar. El Scrum master/facilitador es el responsable de hacer que este espacio de la retrospectiva sea propicio para que todas las voces sean escuchadas y respetadas.
Cosas a tener en cuenta en una retrospectiva
Dado que scrum es flexible, ciertas cosas de las retrospectivas pueden modificarse a gusto, pero hay otras que conviene tratar de mantener, como ser que se respete la duración de la reunión, asistentes y el formato en general.
¿Cuando y cuánto tiempo?
La periodicidad de la reunión la dará la duración del sprint pactada, generalmente 2 semanas, pero puede ser de 1 a 4 semanas (Si usamos Kanban pueden ser una vez al mes hasta trimestrales las retros). La duración de la reunión se desprende directamente de la duración del sprint, y según la guía de scrum se estima 45 minutos por semana que tenga el sprint. Si el sprint es de 2 semanas, la duración de la retro debe ser de al menos 90 minutos y no debería de tomar más de 2 horas. La guía de Scrum aclara que, para una retro de un sprint de 1 mes, debería de ser de 3 horas (180 minutos) y no debería de superar las 4hs.
¿Quiénes participan?
Todo el equipo y el facilitador es el que conduce la reunión. Deben estar comprometidos a respetar, tanto esta, como las otras ceremonias. El facilitador puede ser el scrum master, el product owner, incluso puede rotar dentro de las personas del equipo, como así puede ser otra persona que no es del equipo. No es que cualquiera puede hacerlo, el que lo haga, debe comprender el marco de trabajo (Scrum por ejemplo) como sus herramientas ágiles (Estructuras liberadoras o técnicas de facilitación) para lograr una retrospectiva exitosa. Tipicamente las retrospectivas son llevadas por el scrum master o el líder de proyecto, trayendo a un facilitado externo puede hacer la dinámica de la retro cambie, mas aún que el facilitador no está viciado con suposiciones ni preconceptos.
Qué hacer
Como se explicó, se puede hacer las retrospectivas de varias maneras, con distintas herramientas, pero generalmente se usan estos pasos básicos o checklist
1. Crear una lista de lo que salió bien y lo que se podría mejorar. Se puede usar una pizarra o incluso usando unos sticky notes y pegarlos en la pared.
2. Armar una lista con las mejoras, ordenadas por importancia o lo que se quiera trabajar primero. Se pueden descubrir temas comunes y agruparlos para poder tener así un mapa claro de los mismos.
3. Hablar sobre formas de mejorar los puntos de la lista, si son muchos quizás no puedan tomarse todos esos temas para el siguiente sprint, pero no tengan miedo de que haya muchos, ya que eso pasa, por lo que hay que tomar los que se consideren más importantes.
4. Crear un plan de acción para las mejoras. Al final de reunión el quipo tuvo que haber encontrado algunas ideas factibles de llevar a cabo, asignadas a responsables y con fechas límites para estas mejoras (puede ser una fecha dentro del sprint que viene o para el final mismo).
El punto 4 es clave, sin esto, en la próxima retrospectiva muy probablemente surjan nuevamente los mismos puntos de mejora. Al asignar personas encargadas y fechas límite evitamos estancarnos en un círculo como así también la frustración de sentir que no se logró mejorar nada en el sprint.
Un ejemplo de una mejora que pueda surgir podría ser que, ante la mínima duda de algo, en vez de suponer o asumir, se consulte. Esto es algo que sucede en los proyectos, pero es también inherente en las interacciones/comunicación entre las personas. Estos malentendidos y suposiciones pueden llevar a que un requerimiento se implemente de una manera distinta de como se quiso en realidad.
Conclusión
Muchos que están comenzando o quieren empezar con frameworks como scrum o Kanban y deben estarse preguntando “¿Pero realmente funciona la retrospectiva?;¿No se enoja o toma a mal la gente cuando se discute lo que salió mal?;¿Cómo hago para que eso no pase?; etc.”.
El éxito de un equipo de srcum es igual al éxito de cualquier equipo (Fútbol, Rugby, Hockey, etc.), depende del equipo en sí y en su totalidad. El srcum master (como un director técnico) puede hacer lo mejor de su lado, pero si el equipo no es sincero y no tiene ganas de mejorar no se puede obligar a que alguien cambie el chip o la mentalidad (mindset). Algunos equipos o personas les toman más tiempo que a otras adaptarse, por lo que no pierdan la fe en ellas, más si vienen de otro paradigma de trabajo como ser un proyecto que usa Cascada (Waterfall o Sashimi que sería un waterfall solapado). Con el paso de los sprints, los integrantes del equipo reacios a las retrospectivas van a irse ablandando al ver que el equipo mejora, que hay menos errores y que el equipo es más unido y maduro.
En cuanto a la gente que puede enojarse. La retro no es para apuntar con el dedo a las personas que hicieron algo mal, es un espacio para ver los puntos o cosas, en general, que no salieron bien y ver qué podemos mejorar para que no pase nuevamente. El srcum master o facilitador debe dejar en claro esto a todo el equipo, que errores cometemos todos, lo importante es aprender de ellos y no repetirlos. Como siempre digo “de un error del que no se aprende, es un error desperdiciado”.