Ejecución del PI

Introducción

Hemos visto que los objetivos del PI Planning (PIP) consistían en alinear el tren con sus equipos o trenes para garantizar un compromiso compartido con la visión estratégica de la empresa. Durante el PIP, cada equipo de los distintos trenes elabora un plan para el desarrollo de las funcionalidades que se entregarán durante el siguiente PI. La gestión de la dependencia entre equipos y la gestión de riesgos también se abordan durante el PIP para anticipar bloqueos y retrasos en el proceso de entrega. Tras la planificación del PI, los equipos saben bien lo que tienen que hacer en los siguientes tres meses.

Así, sprint a sprint, intentarán alcanzar los objetivos fijados durante el PI Planning. Recuerde que el PI es simplemente un periodo que contiene sprints y que puede extenderse de 8 a 12 semanas, es decir, de 4 a 6 sprints de 10 días cada uno, lo que son unos 3 meses. La configuración más común en España es de 5 sprints seguidos del sprint de Innovation & Planning (IP).

Todo lo que hemos visto en Scrum se practicará durante los sprints del PI. Para cada sprint (o iteración), habrá un Sprint Planning, un taller de Refinement, los Daily, una Sprint Review y una Retrospective. Durante el PI, todos estos eventos tendrán lugar al mismo ritmo que los sprints. No entraremos aquí en detalles sobre lo que hacen...

System Demo

He visto a equipos SAFe hacer demostraciones por separado; considero que es un error de base. Incluso si el último sprint (IP) del PI impone la System Demo, eso no es razón para dejar de hacer demostraciones juntos al final de cada sprint. La regla de oro es detectar los problemas lo antes posible y obtener feedback lo suficientemente rápido como para mejorar la capacidad de respuesta. Si espera al último sprint del PI para hacer una demostración general de la producción del tren, corre el riesgo de descubrir problemas de integración entre los distintos equipos en el último momento. Por eso es fundamental hacer demostraciones generales al final de cada sprint. El hecho de que todo funcione a la perfección en cada equipo no significa que los distintos componentes vayan a integrarse perfectamente una vez ensamblados. El mismo problema se plantea durante las pruebas de integración, cuando se ensambla el trabajo de varios desarrolladores en un mismo equipo. En este caso, hay que integrar el trabajo de varios equipos.

En el último sprint (Innovation & Planning) del PI, como hemos dicho, los equipos deben demostrar todas las funcionalidades que han implementado todos los equipos del tren: es la System Demo. Los Business Owner, Program Managers, Customers (Clientes) y PO, entre otros, deben estar obligatoriamente presentes para proporcionar un feedback rápido. No olvide invitar a algunos miembros del equipo de DevOps, por si surge algún problema técnico durante la ceremonia...

No puede evitar la System Demo, es la única manera de ver lo que realmente han producido todos los equipos del tren y la mejor manera de medir el PI. También dijimos que algunas empresas evitan hacer System Demo al final de cada sprint. No les imite, la System Demo debe realizarse absolutamente al final de cada sprint y en el último sprint del PI. En un tren, no se puede prever una integración de última...

Sincronización de los PO (PO Sync)

La versión 6.0 de SAFe habla ahora de la Sincronización de los PO, antes conocida como PO Sync. Este evento se utiliza para sincronizar el feedback de todos los Product Owner de un tren y normalmente es organizado por el RTE. Con periodicidad semanal, reúne a todos los PO del tren para examinar el progreso de la producción del ART. El Product Manager (PM) también puede organizar esta reunión, que dura entre 30 y 60 minutos. Los comentarios de los PO permiten conocer los avances. En función de los problemas comunicados, pueden tomarse medidas inmediatas para resolverlos. En este nivel se habla sobre todo de los problemas de la empresa y se discuten las funcionalidades que nos bloquean.

El RTE no entra en los detalles del nivel US o del código; quiere saber si las Features comprometidas en el PI van por buen camino. A nivel de equipo, es el Scrum Master quien tiene que asegurar que todo va bien tanto a nivel funcional como a nivel técnico, organizativo o relacional y también quien elimina los obstáculos que impiden al equipo alcanzar sus objetivos. Sin embargo, en la Sincronización de los PO, nos interesa el progreso del incremento a nivel funcional: ¿hay elementos de bloqueo en determinadas Features? ¿Es necesario hacer ajustes en el planning iniciado durante el PI Planning? ¿Hay cambios en las prioridades?

El RTE también...

Sincronización de los Coaches (Scrum of Scrums)

Del mismo modo, la ceremonia de Scrum of Scrums (SoS) ha pasado a llamarse Sincronización de los Coaches. Los Scrum Masters son también coaches (o entrenadores) ágiles en la nueva visión de SAFe.

Mientras que la sincronización de los PO se centra en los aspectos de negocio, la de los Coaches se dirige especialmente a los aspectos técnicos: no solo los obstáculos técnicos, sino también la madurez de los equipos en términos de agilidad. En esta reunión, que dura entre 30 y 60 minutos, el RTE convoca a los Scrum Master de los diferentes equipos del tren. El protocolo de debate es similar al del Daily Scrum. Aquí, el RTE se centra en lo que un equipo en particular ha logrado desde la última reunión con su Scrum Master, y lo que el equipo ha hecho y planea hacer entre ese momento y la siguiente reunión. El RTE necesita saber si hay el más mínimo bloqueo, porque él tiene la gran responsabilidad de eliminar los obstáculos que podrían hacer descarrilar el tren. Se apoya con confianza en los Scrum Master, pero cuando el problema no puede resolverse dentro de un equipo, la Sincronizacion de los Coaches permite identificar rápidamente ese problema para que el RTE y otros compañeros puedan ayudar.

Si se plantea un problema complejo durante la sesión, el RTE organiza una reunión...

Iteración IP

En el capítulo "Vamos a tomar un tren SAFe en marcha", vimos un ejemplo de planning del trabajo en el sprint IP. El siguiente diagrama resume todo lo que se puede hacer en este sprint IP:

La iteración Innovation and Planning (IP) es el último sprint de cada PI. Durante los diez días de este sprint final, se proponen actividades diversas. El evento más importante de este sprint es, obviamente, el PI Planning, que tiene lugar durante dos días.

Otro evento importante es el Inspect & Adapt (I&A), que se divide en tres partes: una dedicada a la System Demo, otra a medir la productividad del PI, y la parte final, una Retrospective en la que también tratamos de resolver las cuestiones pendientes. Ahora que se acerca el PI Planning del siguiente PI, obviamente estamos muy centrados en prepararlo para resolver los últimos temas. También aprovechamos este periodo para trabajar en innovación y hacer seguimiento tecnológico. Si el trabajo de desarrollo no se ha completado, los equipos pueden finalizar las tareas ahora; pero, sobre todo, no cometa el error de programar la demostración general en función de cuándo se prevé acabar los elementos pendientes de desarrollar. En la agilidad todo se mide por plazos para evitar anuncios del tipo: "Ya casi hemos terminado, en dos días estaremos listos", seguidos de una semana de retraso.

Se fijan las fechas de la System Demo y los equipos se alinean para ultimar lo que queda por hacer; pero admitámoslo, sacar tiempo de este último sprint para los retoques finales es una muy mala costumbre. Si es necesario, puede empezar con lo que estaba previsto en Stretch, pero para el resto, es mejor terminar todo antes del último sprint de IP.

El mecanismo bien engrasado

El diagrama anterior describe toda la cadena de producción, desde la idea estratégica hasta su implementación.

Empezamos con un Roadmap global con una visión a dos años vista, por ejemplo. Este Roadmap global se valida durante el primer PI Planning, pero los equipos ya han empezado a trabajar en él unos meses antes. Una vez más, no se llega con las manos vacías para construir el Roadmap durante el primer PI Planning. Una vez definida esta visión a largo plazo, cada equipo empieza a diseccionar sus macro Epics. La mejor herramienta para esto es el Story Mapping, que nos permite desglosar nuestras Epics y Features hasta el nivel más bajo, es decir, el nivel de User Story. Desglosaremos lo suficiente para poder alimentar todos los sprints de nuestro PI. Una vez se llega al PI Planning, validamos nuestro planning. A continuación, rellenamos nuestro Product Backlog con todas las US de los diferentes sprints planificados durante el PI Planning. Una vez que el Backlog está listo, se inicia nuestro Sprint Planning y el sprint puede comenzar. De esta manera, se ejecutan los diferentes sprints del PI, hasta llegar al siguiente PI Planning.

Durante el PI, nos hemos encargado de preparar este futuro PI Planning extrayendo las nuevas US del Story Mapping o desglosando nuevas Epics y Features del Roadmap global con la ayuda del Story Mapping. Así, usted estará listo...