Hacer que las retrospectivas sean efectivas en un proyecto de larga duración

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!

Respuestas (5)

Hay varias cosas que puede hacer para animar sus retrospectivas y seguir obteniendo valor de ellas:

  • Pídale a otra persona que facilite la retrospectiva. Por ejemplo, los miembros de un equipo, un maestro de Scrum de otro equipo, un entrenador ágil, etc. Un nuevo facilitador puede conducir a otros tipos de discusiones, ideas y puntos de vista, temas o enfoques de mejora.
  • Cambia el escenario de la retrospectiva. Salga, salte a un centro de reuniones o instalación cercana, visite un museo, cene juntos, cualquier cosa que pueda ayudar a los miembros del equipo a salir de la rutina diaria y refrescarse.
  • Cambie la audiencia: haga una retrospectiva con las partes interesadas, los clientes, la gente de operaciones o cualquier otro grupo de personas con las que colabore el equipo. Cuando la audiencia cambia, el alcance y la perspectiva también cambian; se convierte en una retrospectiva a nivel de proyecto, retro de extremo a extremo, DevOps retro, Business - IT retro, etc.
  • Haga una retrospectiva sobre cómo ha ido mejorando como equipo. Esto incluye reflexionar sobre la forma en que se están realizando retrospectivas y también sobre cómo se realiza el seguimiento con acciones de mejora.
  • Celebra los éxitos. Para un equipo que ha estado junto durante tanto tiempo, debe haber cosas que van muy bien, así que tómese el tiempo para explorarlas y aprender más sobre las cosas que van bien. Encuentra las fortalezas de tu equipo.
  • Y sí, cambia el ejercicio retrospectivo que usas (aquí tienes una caja de herramientas con ejercicios retrospectivos )

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!

Y la versión actualizada de mi respuesta se puede encontrar en mi publicación de blog 5 consejos para seguir obteniendo valor de las retrospectivas ágiles: benlinders.com/2016/…
Realmente aprecio la respuesta!
Una palabra de precaución acerca de traer personas fuera del Equipo Scrum. No haga esto a menos que haya una muy buena razón y el Equipo Scrum esté 100% de acuerdo con ello. El Retro es solo para el Equipo Scrum; es crucial que siga siendo un lugar seguro para expresar quejas y hacer el trabajo duro de mejorar. Además, visite planes-for-retrospectives.com . He encontrado que es un gran recurso para ideas retrospectivas.
Jason: Puedes hacer tanto retrospectivas de equipo como retrospectivas de proyectos, no se excluyen entre sí sino que se apoyan mutuamente.

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.

Me encanta el blog de Mike. Estoy absolutamente de acuerdo en que Retros aún puede ser beneficioso, solo quiero asegurarme de que lo aprovechemos al máximo. ¡Gracias por la respuesta!

¡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.

¡Gracias por la respuesta! Trato de cambiar cada vez, o al menos semi-regularmente. Definitivamente he encontrado situaciones que me han llevado a usar cierto formato.

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 :)

La sugerencia de detener los retros estaba más pensada como un ejemplo extremo. Yo mismo soy un gran admirador de Retromat. ¡Gracias por la respuesta!
¡Absolutamente! ¿Conoces Piedra Papel Tijera? Básicamente, todo el equipo golpea dos veces con el puño cerrado la palma abierta y luego, al mismo tiempo, arrojan la cantidad de dedos que representan cómo sienten que algo salió. Cuantos más dedos, mejor. Es una forma rápida de medir cómo se siente el equipo acerca de algo. Siempre hago un Puño de Cinco después de Sprint Planning, por ejemplo.

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.

¡Gracias por la respuesta! ¿Puedes describir un poco más el método "Puño de cinco"?
Me interesa saber qué procesos de Scrum detesta. Mientras leo la guía de Scrum, no hay ninguno... solo elementos de un marco. Roles, Eventos, Artefactos, etc. Eso no quiere decir que los Equipos Scrum no puedan convertirse en procesos pesados ​​en la forma en que desarrollan su software; sin embargo, esto es parte de un equipo que practica el arte de la simplicidad en la forma en que refinan su trabajo en conjunto, no algo que impone Scrum.
@JDRoger Tenía la intención de agregar este comentario aquí... de alguna manera terminó arriba... ¡Absolutamente! ¿Conoces Piedra Papel Tijera? Básicamente, todo el equipo golpea dos veces con el puño cerrado la palma abierta y luego, al mismo tiempo, arrojan la cantidad de dedos que representan cómo sienten que algo salió. Cuantos más dedos, mejor. Es una forma rápida de medir cómo se siente el equipo acerca de algo. Siempre hago un Puño de Cinco después de Sprint Planning, por ejemplo.