Por si hay algún despistado, hago una breve introducción de lo que es Scrum:
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
Los tres pilares sobre los que se soporta Scrum son transparencia, inspección y adaptación.
Scrum propone cuatro ocasiones formales en las cuales potenciar la inspección y la adaptación:
- Reunión de planificación del Sprint (Sprint Planning Meeting)
- Scrum diario
- Reunión de revisión del Sprint (Sprint Review Meeting)
- Reunión de retrospectiva (Sprint Retrospective)
En esta ocasión quería centrarme en la última de ellas, la retrospectiva. Es la más desconocida para la mayoría de la gente puesto que no interviene directamente en el desarrollo del incremento del Sprint (o del proyecto si no se trabaja con Sprints) y no se suele realizar pero pienso que es muy importante si queremos aprender de nuestros aciertos y de nuestros errores.
Es una reunión que se realiza al acabar cada Sprint, en la cual los miembros del equipo de Scrum discuten sobre el Sprint que acaba de finalizar.
En Kabel se está haciendo (o se intenta hacer) algo parecido al final de cada proyecto con las “lecciones aprendidas” pero cuanto antes detectemos los puntos de mejora, antes podremos mejorar.
El objetivo de esta reunión es mejorar de manera continua la productividad y la calidad del producto que se está desarrollando. El equipo analiza cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a los que se comprometió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente (en la Reunión de revisión del Sprint) era lo que se esperaba o no.
Un ejemplo de la estructura de una reunión de retrospectiva podría ser la siguiente.
1. Puesta en escena
- El Scrum Master/Jefe de proyecto explica el objetivo de la retrospectiva y enumera los diferentes pasos y tiempos que va a tener la reunión.
2. Identificación de problemas
- El Scrum Master/Jefe de proyecto hace un resumen de los hechos, objetivos conseguidos (o no) y decisiones más relevantes del período o proyecto a analizar con la finalidad de mejorar en el siguiente. Se apoya en datos objetivos utilizando para ello, por ejemplo, la lista de requisitos priorizada, la lista de tareas de la iteración, las actividades realizadas, los gráficos de progreso del proyecto o de la iteración, etc.
- Los miembros del equipo proponen problemas adicionales mediante, por ejemplo, una lluvia de ideas (brainstorming). El Scrum Master/Jefe de proyecto va anotando los problemas.
- El equipo agrupa los diferentes problemas según tengan una afinidad o relación y da nombre a cada grupo.
- El equipo vota qué grupos de problemas afectan más a los objetivos del proyecto.
- Las típicas preguntas que se suelen intentar resolver en esta reunión son:
- Si los miembros del equipo han trabajado bien juntos o no
- Si el equipo hizo más o menos de lo previsto o no
- Si el equipo tenía todas las habilidades y recursos que necesitaba para hacer el trabajo más o menos de lo previsto o no
- Si los miembros del equipo entendieron los requerimientos o no
- Si el equipo pudo completar el Sprint en línea con los requerimientos o no
- Que podría mejorarse o eliminarse en el siguiente incremento de funcionalidad
- Qué se ha aprendido.
- Cuales son los problemas que podrían impedirle progresar adecuadamente.
- Que piensa el equipo de usar Scrum
3. Descubrimiento de causas
- Para los grupos de problemas más votados, el equipo analiza por qué se están produciendo hasta encontrar las causas básicas.
- Notar que en ningún momento se trata de buscar culpables, si no de ver qué partes del proceso de trabajo, de interrelaciones y de colaboración, tanto intraequipo como con terceros, deben ser mejoradas para que el problema no se repita.
4. Plan de acción
- El equipo propone soluciones para las causas que producen la mayoría de los problemas del proyecto. Para ello puede volver a utilizar una lluvia de ideas. Su selección final puede estar basada en una votación o en criterios como coste, esfuerzo o tiempo de realización, satisfacción del cliente, sostenibilidad de la solución, etc.
- Se generan las tareas necesarias y se introducen en la lista de requisitos priorizada del proyecto (Product Backlog) o la lista de tareas de la siguiente iteración (Sprint Backlog).
5. Qué ha funcionado bien
- Una retrospectiva no sólo debe fijarse en la solución de problemas, si no también hacer reconocimiento de las cosas que fueron bien e identificar las que hay que potenciar más. Para ello, se puede aplicar un proceso muy similar al anterior.
6. Conclusiones de la reunión
- Se resumen las principales conclusiones y decisiones.
- Se revisa si se ha conseguido el objetivo de la reunión.
- Se analiza qué ha ido bien y qué hay que mejorar de la dinámica de la retrospectiva para que la próxima sea mejor.
Una reunión de este tipo suele durar en torno a las 3 horas, dependiendo de la experiencia del equipo en este tipo de reuniones, distribuidas de la siguiente manera:
- Puesta en escena: 15 minutos
- Identificación de problemas: 60 minutos
- Descubrimiento de causas: 30 minutos
- Plan de acción: 45 minutos
- Qué ha funcionado bien: 15 minutos
- Conclusiones de la reunión: 15 minutos
Los principales beneficios de la realización de este tipo de reuniones son incrementar la productividad en el proyecto, la calidad del producto (cosa que permite hacerlo crecer de manera sostenida) y potenciar el aprendizaje del equipo de manera sistemática, iteración a iteración, con resultados a corto plazo, además aumenta la motivación del equipo dado que participa en la mejora del proceso, se siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir eliminando lo que molesta e impide que sea más productivo.
