Cuando hay problemas, la ceremonia del Sprint Retrospectives es la primera que el equipo abandona. A muchos nos pasó de no darle tanta importancia a esta reunión, hasta que vivimos y experimentamos su utilidad en uno o más proyectos. Ver al equipo crecer y mejorar Sprint a Sprint es algo increíble y reconfortante. Irónicamente, esta ceremonia es más valiosa cuando estamos bajo presión o las cosas no salen como uno esperaba, ya que nos permite visualizar esos problemas y tomar acción para resolverlos. Hay que mantener la disciplina y el la Retrospective tiene que hacerse siempre al final de los Sprints sin importar el ruido al rededor del equipo y del proyecto.
Los valores de Scrum tienen que ser aplicados con rigor en las Retrospectives. Sin transparencia o honestidad nunca vamos a llegar al fondo de los problemas. Sin coraje, el equipo no va a querer afrontar los problemas. Sin respeto los problemas no van a ser presentados constructivamente y sin dedicación y compromiso a nadie le va a importar resolver los problemas para salir de la situación en la que estamos.
Para tener una buena Retrospective, es bueno que el equipo venga preparado con una lista de temas a charlar sobre el proceso, la comunicación, las herramientas, el scope, la calidad, los ambientes, sus capacidades y cualquier otro tema relacionado. Una forma de lograr esto es utilizar una herramienta colaborativa (Google Spreadsheet por ejemplo) para que el equipo vaya dejando sus notas durante el sprint ahí. Como ScrumMaster hay que reforzar y recordar al equipo durante el Sprint que vayan aportando sus pensamientos en esa herramienta para que la reunión sea exitosa.
Durante la Retrospective, es bueno enfocarse en dos preguntas: ¿Qué puede mejorar? y ¿Qué salió bien? Proyectando los comentarios en la herramienta colaborativa, podemos separar en dos los resultados basándose en esas preguntas, mientras vamos leyendo los comentarios y discutiendo entre todos sobre ellos.
Finalmente, sobre los puntos a mejorar, no hay que comprometerse a tratar todos los problemas para la próxima Retrospective. Todos los problemas de las sesiones (y las cosas que salieron bien) tienen que documentarse, y solo hay que elegir no más de tres problemas a tratar. Cuando uno promete de más y luego no cumple, pierde credibilidad. Acciones tienen que acordarse basándose en esto tres problemas y miembros del equipo tienen que ser asignadas como sus respectivos dueños. El ScrumMaster tiene que tenerlas en cuenta para que se traten durante el siguiente Sprint.
Para cerrar, pase lo que pase, mantengamos la disciplina y estas ceremonias para asegurar que el equipo mejore y los problemas se traten ordenadamente como el framework de Scrum nos pide.
