¿Cómo puede un Scrum Master hacer dos retrospectivas durante SAFe PI Planning?
Estefania
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?
Respuestas (1)
Todd A. Jacobs
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.
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.
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.
SAFe, ¿es necesario que los desarrolladores reúnan sus propios requisitos?
¿La mejor manera de realizar un seguimiento de quién está en el cargo? [cerrado]
¿Podemos asignar tiempo a los puntos de la historia?
¿Cómo puedo manejar a los empleados desmotivados y desmotivados en mi equipo Scrum?
Tratar con el tiempo no programado en Project
¿Cómo convencer a la gerencia de cambiar las prácticas de facturación poco éticas?
¿Cómo hacer que la gente se sume a Scrum/agile?
Hacer que las retrospectivas sean efectivas en un proyecto de larga duración
Cómo encajan el control de calidad, el frontend, el desarrollo backend y la administración del sistema en el marco de gestión de Scrum
¿Cuándo mencionar las limitaciones de tiempo en mi capacidad para trabajar?
ppasler
Estefania
ppasler
Todd A. Jacobs
Estefania