¿Cómo puede un Scrum Master hacer dos retrospectivas durante SAFe PI Planning?

Como Scrum Master para dos equipos dentro de SAFe, tengo la programación estándar al pie de la letra. Puedo asistir a todas las reuniones periódicas y los equipos funcionan relativamente bien. Sin embargo, estamos trabajando en un entorno ágil escalado y hay un evento que regularmente me hace querer clonarme a mí mismo: PI Planning.

En otras palabras, el evento en el que todos los equipos Scrum que están desarrollando un gran proyecto se reúnen físicamente para ajustar su planificación para los próximos dos meses. Esto incluye una retrospectiva y una sesión de planificación. Si bien la planificación es factible (ventana de tiempo más grande y mucha preparación), liderar dos equipos a través de una retrospectiva común dentro del mismo intervalo de tiempo de treinta a sesenta minutos es un desafío. Sí, las preguntas son las mismas para los más de 100 participantes, pero se supone que nosotros, como Scrum Masters, debemos liderar y alentar a nuestro equipo, asegurarnos de que se cumplan los límites de tiempo, etc.

En el pasado, resolví esto colocando físicamente a ambos equipos uno al lado del otro, pero descubrí que las discusiones de los dos equipos los distraían mutuamente y que yo corría como el proverbial "pollo sin cabeza".

Como la regla general parece ser "Scrum Master = 1/2 trabajo de tiempo completo", supongo que hay muchos SM con problemas similares.

¿Cómo puede una persona hacer malabares con dos equipos cuando el trabajo secuencial es imposible?

¿Ambos equipos tienen retro juntos? Si no, ¿es necesario hacer el retro al mismo tiempo?
@ppasler: todos los equipos están haciendo una retrospectiva juntos sobre el último incremento del programa, cada equipo trabaja dentro del equipo y luego los resultados se presentan a la audiencia general. No puedo hacer dos retros, porque no estoy haciendo las preguntas. Sin embargo, haré que ambos equipos piensen en el general "qué salió bien, qué salió mal, qué vamos a hacer mejor" de antemano, con la esperanza de que necesiten menos orientación en el evento real.
Veo, esto es una especie de scrum de scrums retro, echa un vistazo a esto: scrumalliance.org/community/articles/2016/february/… No tengo experiencia, pero esto tiene mucho sentido para mí.
Los equipos de 50 personas no suenan muy ágiles, incluso dentro de SAFe. También parece que su planificación de PI no es lo suficientemente larga (la recomendación es de 1,5 a 2 días), no hace suficientes desgloses o aprovecha el rol de ingeniero de ART. scaledagileframework.com/pi-planning
@CodeGnome no mis equipos, todos los participantes en el tren de lanzamiento ágil. Estoy trabajando con una docena de desarrolladores. Y estoy de acuerdo, 50 por equipo suena extraño. Nuestra Planificación PI es ca. 2 días, que puedo hacer malabarismos muy bien; por lo general, tengo tiempo para apoyar mi RTE. Es solo lo retro lo que me marea.

Respuestas (1)

TL;DR

No soy un gran admirador de SAFe, por lo que es posible que prefiera una respuesta de alguien que lo sea. Con esa advertencia fuera del camino, creo que el error fundamental es que su ingeniero de ART está combinando la retrospectiva de iteración (que debería ser un evento separado) con el evento de planificación de PI . Los equipos no deben realizar retrospectivas de iteración dentro de PI Planning en absoluto.

La única retrospectiva definida dentro de PI Planning es la Retrospectiva de planificación , que está a cargo del Value Stream Engineer , no del Scrum Master . Por lo tanto, su problema puede resolverse adhiriéndose al marco definido, en lugar de incluir retrospectivas adicionales en el evento incorrecto.

La planificación de PI no debe incluir una retrospectiva de iteración

La planificación de PI es similar en intención (si no práctica) a la reunión de planificación de Sprint de Scrum . Tiene una agenda definida , como se muestra a continuación.

Agenda de planificación de PI estándar

Sin embargo, tenga en cuenta que la retrospectiva definida en la agenda es una retrospectiva de planificación , no una retrospectiva de iteración . ¡No hay retrospectiva de iteración en PI Planning en absoluto!

Retrospectiva de la planificación de PI: la definición de "planificación de PI"

De acuerdo con el marco, la Retrospectiva de Planificación se describe en PI Planificación de la siguiente manera (énfasis mío):

Planificación retrospectiva y avance. Finalmente, el RTE dirige una breve retrospectiva de la reunión para capturar lo que salió bien, lo que no salió bien y lo que se puede hacer mejor la próxima vez. Después de esto, se discuten los próximos pasos, incluida la captura de objetivos e historias en las herramientas de gestión de proyectos Agile, la programación de las próximas actividades y eventos clave... ¡y la limpieza de la sala!

Lo que no queda tan claro como debería es que esta retrospectiva es para reflexionar sobre el evento de planificación de PI, no sobre la iteración. Como tal, no es una sesión de grupo o un conjunto de reuniones simultáneas, y no tiene que ejecutarse de la misma manera que una retrospectiva de iteración.

Retrospectiva de la planificación de PI: la definición de "planificación posterior a PI"

Sin embargo, el marco ofrece una definición ligeramente mejor que se encuentra en Planificación previa y posterior a PI . Los elementos de la agenda reciben un contexto separado dentro de la Planificación posterior a la PI, lo que ayuda a aclarar el propósito de los elementos de la agenda enumerados.

Agenda de Planificación Post-PI

Además, la definición del elemento de la agenda aquí utiliza el mismo encabezado de sección para el elemento de la agenda, pero también describe quién es el propietario del elemento de la agenda como Value Stream Engineer (VSE) :

Planificación retrospectiva y avance. Finalmente, el Value Stream Engineer dirige una breve retrospectiva de la reunión para capturar lo que salió bien, lo que no y lo que se podría hacer mejor la próxima vez. Después de esto, se discuten los próximos pasos, incluida la captura de objetivos, el uso de herramientas de gestión de proyectos y la finalización del cronograma de las próximas actividades y eventos clave.

Debido a que proporciona contexto y un propietario para el tema de la agenda, esta descripción parece mucho más clara. Sin embargo, tenga en cuenta que también difiere de la otra definición al asignar este trabajo al ingeniero de flujo de valor (VSE) en lugar del ingeniero de tren de lanzamiento (RTE). En cualquier caso, el propietario del elemento de la agenda no es el Scrum Master y, por lo tanto, usted no es quien tiene que administrar la retrospectiva o hacer malabarismos con los participantes.