¿Cuál podría ser una agenda de una PI Planning?

La PI Planning, usualmente en un entorno trimestral, sirve para la sincronización y alineamiento entre equipos, con negocio y con sistemas/arquitectura. Es una reunión abierta donde todos los interesados (negocio, sistemas, ...) y miembros del tren (ART) comparten información y se coordinan con la idea de reformular la visión, planificar el siguiente trimestre y obtener feedback sobre cómo están funcionado las cosas.

Una agenda resumen de lo que ha sido exitoso en mi experiencia sería algo así:

Agenda de una PI Planning con los puntos a tratar y quienes intervienen en cada paso - gracias Ángel por la foto

Día 1

7:30 - 8:00 Café y desayuno
Un café con desayuno tiene dos bondades, primero atrae, en nuestra cultura española es signo de relevancia, y segundo despierta nuestras mentes y nos predispone a ser más abiertos de mente.

8:00 - 9:00 Contexto de negocio
¿Cuantas veces hemos oído a los miembros de los equipos interesarse por los valores y la dirección de la empresa? No sobre informes de éxitos y ventas en el último año, sino sobre el propósito de la empresa y sobre su futuro. Es la ocasión ideal para que el CEO o un directivo dé una primera introducción poniendo contexto de negocio al trimestre junto al mensaje "¡esto va en serio y tenéis todo nuestro apoyo!".

9:00 - 10:00 Visión del producto y top features
¿Cuántas veces hemos visto como los desarrolladores de software codifican software en base a tareas aisladas y no entienden de lo que forma parte su trabajo? Los jefes de proyecto se quejan de trabajo duplicado y de decisiones desafortunadas que éstos toman. Esta es la ocasión ideal para hacer que todos se sientan parte de algo más grande, el producto o proyecto. Product Management expone la visión con los grandes rasgos del producto a construir y los principales objetivos de negocio a dar solución en el trimestre. Los miembros de los equipos así comprenden de qué forman parte y tomaran mejores decisiones en la construcción del software.

10:00 - 11:00 Visión de arquitectura y UX
Si queremos dar verdadera guía arquitectónica, de UX y sobre el contexto tecnológico, es responsabilidad de arquitectura, UX, sistemas y líderes técnicos comunicar, y con comunicar quiero resaltar que se trata de hacer entender y dar las herramientas necesarias para que los equipos de desarrollo se alineen y construyan eficientemente.

11:00 - 11:30 Descanso con icebreaker y café
Los icebreakers tienen la bondad de energizar a los asistentes, de darles ocasión de divertirse y conectar con los demás y sentirse más despiertos. Estos junto a un momento de distensión con un buen café prepara a los equipos para su primera sesión de trabajo.

11:30 - 12:00 Contexto del evento
El RTE, el coach ágil, expone el objetivo principal de la PI Planning, presenta la agenda y explica el funcionamiento de la misma.

12:00 - 15:00 Primera sesión equipos (breakout)
En la fase preparatoria se han distribuido tableros y post-its en áreas de trabajo independientes para cada equipo. En este paso los equipos dividen features en historias de usuario e historias técnicas (enablers) y las planifican a modo de borrador en los sprints del trimestre. También identifican sus objetivos para el trimestre, y toman nota de dependencias y riesgos que detecten.

Las dependencias que hayan emergido las resuelven con los otros equipos, si estos están en la sala, para luego ajustar las historias de usuario en los sprints en consecuencia. Principalmente son las dependencias resueltas las que determinan el orden de ejecución de las historias, estas se recogen en Program Board junto a las features.

15:00 - 16:00 Comida
La comida es la ocasión ideal para que la gente hablé de niños, fútbol y toda clase de temas terrenales y que se forjen relaciones y confianza. La comida es especialmente útil en caso de equipos deslocalizados, una ocasión para crear conexiones entre las personas de diferentes localizaciones y para potenciar su colaboración.

16:00 - 17:00 Revisión de los borradores de la planificación
De vuelta a la PI Planning los equipos presentan sus planes individuales a todo el tren, uno por uno exponen sus objetivos, capacidad, riesgos detectados y dependencias resueltas. No se muestran historias de usuario, lo importante es exponer qué objetivos de negocio se resuelven con estas.

17:00 - 18:00 Revisión de managers
Business Owners, Product Managment, RTE, arquitectos y otros líderes y directivos han recibido un plan impregnado de realidad que probablemente no cuadre al 100% con sus deseos expresados mediante las features... es un momento de aprendizaje sobre lo que es factible y decidir que hacer para el segundo día de la PI Planning.

Día 2

7:30 - 8:00 Café y desayuno
Ocasión ideal para que los asistentes reconecten de nuevo y esté preparados para afrontar el día con energía y proactividad.

8:00 - 9:00 Ajustes para los planes
En base a lo que los managers hayan aprendido sobre la factibilidad éstos devuelven a los equipos ajustes como cambios en la visión, variación en las prioridades de negocio y movimientos de personas y de recursos.

9:00 - 11:00 Segunda sesión equipos (breakout)
Segunda sesión de trabajo en la que los equipos hacen ajustes en sus planes, Business Owners les habrán marcado valor de negocio a sus objetivos para que les sirva de guía, siguen resolviendo dependencias y detectando riesgos.

11:00 - 11:30 Descanso con icebreaker y café
Momento necesario para descansar y reponer energías.

11:30 - 12:30 Revisión de los planes finales
Después de una segunda revisión probablemente los planes individuales de los equipos se hayan acercado lo suficiente al deseo expresado por las top features. Business Owners aceptan los planes y dan su visto bueno, si no fuera el caso habría que retrabajar.

12:30 - 13:30 Gestión de riesgos
Antes de llegar a la fase final se tratan los riesgos detectados por los equipos que afecten al tren: cada uno de ellos se clasifica según una matriz ROAM (Resuelto, Asignado gestor - Owned, Aceptado y Mitigado).

13:30 - 14:00 Voto de confianza
Con una técnica muy simple, levantando en el mismo instante una mano con 1 a 5 dedos extendidos (desde 1 que significa sin confianza en el plan a 5 que significa un plan perfecto), todo el mundo da feedback de su nivel de confianza en el plan obtenido. Todos han participado durante dos día en el evento, todos deberían de estar convencidos de que el plan funcionará, y si hubiera alguien que no confiara deberemos aclarar sus preocupaciones antes de empezar el PI.

Si el voto de confianza indica un buen plan
Se han podido aclarar y resolver las preocupaciones de quienes hayan levantado 1 y 2, si es que los ha habido.

14:00 - 15:00 Retrospectiva sobre todo el evento
Con espíritu de mejora continua la PI Planning termina con una retrospectiva ligera. En tres tableros con tres temas, lo que ha ido bien, lo que no y lo mejorable, se recogen ideas que finalmente cada asistente puede votar, usualmente con 3 palitos o estrellitas a repartir libremente. La idea es recoger feedback que RTE con Scrum Masters trataran durante el PI para la siguiente PI Planning.

15:00 - 17:00 Comida con cervezas para team-building
Una buena sesión de PI Planning se merece un buen manjar y que el CEO o directivo invite a cervezas ;-)

Si el voto de confianza indica que hay que retrabajar el plan
Las preocupaciones han levantado temas de mayor calibre que hay que despejar antes de seguir, una posible agenda podría ser la siguiente:

Quiero aprovechar el post para agradecer al grupo de RTEs lo
mucho que he aprendido de ellos :-) Thanks! Alexey, Yann,
Guy-Alexandre, Denis, Matt, Alex, Lionel, Sébastien y Benoît

14:00 - 15:00 Retrabajo
15:00 - 16:00 Comida

16:00 - hh:00 Retrabajo

hh:00 - hh:30 Voto de confianza

hh:30 - Retrospectiva sobre el evento

Pudiera ocurrir que aún con retrabajo un nuevo voto de confianza indicara que el plan no fuera factible. En ese caso hay que parar, escalar, averiguar causas raíz, resolver y planificar una PI Planning posterior. Para que un PI tenga éxito y se produzca la mejora continua no podemos empezar en ningún caso en falso, estamos hablando que 100 personas pueden fallar y eso no debemos de permitirlo.