En las implementaciones de Scrum en las que participé, siempre usamos Keep/Change o alguna variante, para guiar nuestras retrospectivas.
Después de 4 o 5 sprints, cuando los problemas más obvios y fáciles están solucionados, las reuniones de retrospectiva empezaron a ser menos productivas. No siempre por la misma razón. A veces teníamos problemas difíciles de resolver, que siempre nos afectaban, pero a los que no le encontrábamos la forma de solucionarlos; en otros casos, surgían muchos temas para mejorar, los anotábamos pero con tantos temas, no poníamos foco, y muchos de ellos volvían a aparecer en la próxima reunión, y en otros casos, nos parecía que no había mejoras posibles.
En todos los casos, el empuje inicial disminuyó o se perdió.
Hace unos meses leí el libro “Agile Retrospectives”, de Esther Derby y Diana Larsen, que me dio muchas buenas ideas para mejorar las reuniones. Organicé actividades de retrospectiva incluyendo estas técnicas con algunos de los equipos con los que trabajo, incluso como retrospectiva de la materia con los alumnos de la facultad, donde fue la 2da mejor clase en la votación de los alumnos (la primera fue un Open Space). Creo que la mejor forma de aprender lastécnicas es probándolas, viendo que funciona en cada situación.
1 comentario:
Genial, gracias por tu trabajo de traducción!!
Justo hace unos días comentaba una retrospectiva anual basándome en ese libro y en el de "Software for your head". Con esos dos libros, tienes muchísimo material brillante para reuniones y retrospectivas salgan adelante adecuadamente.
Publicar un comentario