Soy ScrumMaster para una empresa de software y tenemos un proyecto que está entrando en su Sprint 35. Si bien aprecio el valor de las Retrospectivas, cada vez es más difícil obtener buenas perspectivas de nuestros eventos de Retrospectivas. Hemos acortado las reuniones para evitar perder mucho tiempo, e incluso las reuniones cortas no parecen tener tanto contenido (o contenido de calidad) como antes.
Me pregunto qué estrategias usan las buenas personas de PMX para continuar obteniendo valor de Retrospectives, incluso para un proyecto de muy larga duración. ¿Hay diferentes formatos que usas a medida que un proyecto dura más y más? ¿Qué conocimientos debemos buscar más adelante en un proyecto? ¿Dejas de hacer Retros por completo?
¡Gracias por cualquier idea!
Hay varias cosas que puede hacer para animar sus retrospectivas y seguir obteniendo valor de ellas:
No espere hasta que la gente se aburra en las retrospectivas. Cambie su ejercicio, entorno, facilitador, etc. con frecuencia para que su gente se mantenga fresca y siga presentando acciones de mejora útiles. ¡Mantenga valiosas sus retrospectivas ágiles!
Mike Cohn escribió en su blog sobre esto recientemente.
Sus comentarios incluyeron probar diferentes formatos de retrospectiva y hacer que un Scrum Master de un equipo diferente se encargue de la retro.
Mike enfatiza que incluso un equipo Scrum que ha estado junto durante 10 años se beneficia de las retrospectivas.
¡Gran pregunta! Si bien las retrospectivas son un componente crítico de la mejora continua, se vuelven ineficaces con el tiempo si se utiliza el mismo enfoque cada vez.
Este hilo tiene un montón de diferentes formatos retrospectivos en las respuestas, por lo que no los repetiré: Diferentes formas de ejecutar Retrospectivas
En cuanto a cuándo cambiar, desea cierta consistencia para que el equipo se acostumbre, pero si comienza a volverse mundano, debe cambiarlo. Para muchos equipos eso termina siendo alrededor de 4 o 5 sprints, pero vea qué funciona para usted. También hay algunos formatos entre los que es fácil cambiar. El más/menos/delta, el barco retro y la estrella de mar retro tienen un concepto similar, por lo que cambiar entre ellos es fácil. Pasar de un enfoque retro de estrella de mar a un enfoque de 4L es un cambio de mentalidad más grande y debe hacerse con más cuidado.
Además, como Scrum Master, puede encontrar situaciones que requieran una determinada técnica. Si los últimos sprints han sido realmente de poca energía en el equipo, hacer una retro que pregunte qué fue emocionante y qué fue frustrante hace que el equipo hable sobre esos elementos de una manera que "lo que salió bien" no lo haría.
No, siempre debes seguir haciendo retrospectivas. Es uno de los 12 principios básicos de Agile :
A intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia.
Siempre hay algo que mejorar o probar diferente para ser más eficaz. Todavía no he visto el equipo perfecto.
Uno de mis equipos tuvo un gran éxito con Retromat para darle vida a sus retrospectivas. Retromat genera un nuevo formato retrospectivo fresco para cada momento, pruébalo :)
El proceso por el proceso es una mala idea, y una de las grandes desventajas de scrum es que es un proceso muy pesado. Por esta razón, creo que está bien no aguantar el retro de vez en cuando, especialmente si el sprint ha ido bien. No necesita celebrar una reunión especial para celebrar las victorias, ya que las victorias se pueden celebrar en cualquier momento. Tenía un equipo que estaba en su sprint 67 y el equipo tenía una química excelente y era un equipo muy exitoso. Casi siempre sostenía el retro, pero de vez en cuando durante el stand up el día del retro hacía un Puño de Cinco sobre el éxito del sprint y si los puños eran unánimemente Cinco ofrecía que se saltara el retro. Me gusta el scrum. Scrum es una forma divertida de desarrollar software, pero detesto el proceso.
Mi consejo para ti es que pruebes el método Fist of Five, busques Fives unánimes y luego hagas la oferta de saltarte el retro. Tal vez no siempre, pero de vez en cuando está bien.
benlinders
JDRoger
jason.t.knight
benlinders