SAFe aplicado 3: Ejecución eficiente de un PI. Gestión, seguimiento y comunicación en SAFe

En este post hablaremos de cómo se cristaliza el avance de un ART: desde la Iteration Planning y los daily stand-ups que mantienen la sincronización interna, pasando por los rituales de seguimiento inter-equipo como el ART Sync, el Scrum of Scrums y el PO Sync.

Tambien analizaremos cómo los roles de Product Owner, Scrum Master y System Architect colaboran tanto en la entrega técnica como en la adaptación del plan a las condiciones reales, gestionando dependencias, riesgos y cambios de alcance con transparencia. Por ultimo discutiremos sobre el valor de las demos incrementales y el uso efectivo de herramientas colaborativas y como permiten a Business Owners y Product Managers tomar decisiones informadas y asegurar que cada entrega esté alineada con los objetivos globales del Program Increment.

EJECUCIÓN DEL PROGRAM INCREMENT: ITERACIONES DE EQUIPO Y ART SYNC

Con el plan en marcha, el ART pasa al modo de ejecución. El Program Increment (PI) suele estar compuesto por una serie de iteraciones (sprints) con una duración fija, normalmente de dos semanas, durante las cuales los equipos construyen e integran el trabajo planificado.
Organizar el ART durante la ejecución consiste en mantener la alineación, hacer seguimiento del progreso y gestionar cualquier problema o cambio que surja.
SAFe proporciona varias rutinas y artefactos para facilitar esto, y cada rol tiene responsabilidades continuas.

Equipos ágiles (desarrolladores/testers) y Scrum Masters

Cada equipo ejecuta el trabajo definido en su plan de iteración. La Iteration Planning marca el inicio de cada sprint de dos semanas: el equipo, guiado por el Scrum Master y el Product Owner, se compromete con un conjunto de user stories del backlog que pueden completar durante esa iteración.
El Product Owner se asegura de que se seleccionen las historias de mayor prioridad (a menudo las vinculadas a los PI Objectives) y aclara los detalles necesarios.
El Scrum Master facilita la reunión de planificación, asegurándose de que el equipo no se sobrecargue y que se registren las nuevas dependencias detectadas.

Durante la ejecución, los equipos realizan Daily Stand-ups (Daily Scrums) para sincronizarse internamente. En estas reuniones, el Scrum Master garantiza que los impedimentos se visibilicen. Si un miembro del equipo se bloquea o una historia depende de algo externo, el Scrum Master trabaja para eliminar ese obstáculo o lo escala al RTE si está fuera del control del equipo.
Los equipos usan herramientas ágiles como Jira o Rally para actualizar el estado de las historias, registrar avances y seguir las tareas, lo que proporciona transparencia.
El Scrum Master suele monitorear los burndown charts o los cumulative flow diagrams para comprobar si el equipo va en camino de cumplir los compromisos de la iteración.

Product Owner

Durante la ejecución, el Product Owner gestiona continuamente el Team Backlog. Colabora con el equipo en la refinación de historias para las próximas iteraciones (por ejemplo, en sesiones de backlog grooming, que normalmente ocurren a mitad de cada sprint).
Si durante la ejecución surgen aprendizajes que sugieren un cambio (por ejemplo, una feature más compleja de lo esperado o una nueva oportunidad), el PO comunica con el Product Manager para ajustar las prioridades.
El PO participa en la Iteration Review o Demo al final de cada sprint, donde el equipo muestra las historias completadas a los stakeholders (a menudo con presencia del Product Manager o incluso de algún Business Owner).
El Product Owner acepta formalmente las historias como “hechas” cuando cumplen con la Definition of Done y los criterios de aceptación.
Su rol conecta la ejecución diaria con el plan global, asegurando que cada historia entregada contribuya realmente al cumplimiento de las features y los PI Objectives.

System Architect / Engineering

Durante todo el PI, el System Architect se mantiene involucrado para guiar a los equipos en decisiones técnicas y de arquitectura.
Puede organizar sesiones de sincronización técnica (Architectural Sync) o talleres cuando varios equipos necesitan coordinarse sobre un problema común (por ejemplo, una integración entre componentes).
Si el ART ha asignado capacidad para trabajo técnico o enablers, el arquitecto supervisa que esas tareas se estén realizando.
También vela por la gobernanza técnica, asegurando que los equipos sigan los estándares acordados y utilicen correctamente la infraestructura compartida.
Si surgen riesgos técnicos (por ejemplo, problemas de rendimiento en pruebas), el arquitecto trabaja con los equipos para resolverlos de forma temprana.
Además, puede preparar actualizaciones arquitectónicas para el siguiente PI y compartir con el Product Manager información preliminar sobre posibles nuevos enablers a incluir en el backlog.
En esencia, actúa como consultor y guía técnica para mantener la alineación arquitectónica durante la ejecución.

Release Train Engineer (RTE)

El rol del RTE durante la ejecución es coordinar el progreso global del ART y facilitar la resolución de problemas entre equipos.
Su herramienta principal es el ART Sync, que ocurre con una cadencia regular (a menudo semanal). Este evento combina dos reuniones clave: el Scrum of Scrums (SoS) y el PO Sync.
En la práctica, pueden realizarse por separado o de forma consecutiva.

• Scrum of Scrums (SoS):
  Es una sincronización semanal para los Scrum Masters, facilitada por el RTE, donde se revisa el progreso de los equipos y se plantean impedimentos o dependencias surgidas.
  Cada Scrum Master (o delegado) da una breve actualización sobre lo que el equipo logró en la última iteración, lo que planea hacer a continuación y cualquier ayuda que necesite.
  El RTE usa este foro para identificar problemas que afectan a varios equipos y garantizar que se aborden.
  Por ejemplo, si el Equipo A se retrasa porque espera algo del Equipo B, el RTE interviene para informar al Equipo B y ayudar a ajustar prioridades o encontrar una solución.
  También comunica cambios o riesgos a nivel de programa. Esta reunión mantiene la transparencia y coordinación en tiempo real entre equipos.

• PO Sync:
  Es una sincronización semanal paralela enfocada en el progreso del contenido del producto. Participan el Product Manager, los Product Owners y, en ocasiones, los Business Owners u otros stakeholders.
  En el PO Sync se revisa el avance del ART frente a los PI Objectives y las features. Se analizan preguntas como:
  ¿Las features van en camino de completarse según lo planificado?
  ¿Se necesita ajustar el alcance o intercambiar features entre equipos?
  El Product Manager puede aprovechar para compartir nueva información de clientes o cambios del mercado que puedan afectar las prioridades.
  Los POs informan sobre el estado del desarrollo de las features desde la perspectiva de sus equipos y, en conjunto, pueden re-priorizar el Program Backlog si es necesario.
  También se evalúan los riesgos o ajustes de alcance a nivel de programa (por ejemplo, si una historia lleva más tiempo de lo previsto y podría poner en riesgo un objetivo del PI).
  Este foro mantiene alineadas la parte de negocio y la parte técnica durante toda la ejecución.

El RTE suele facilitar tanto el SoS como el PO Sync y asegura que la información fluya entre ambos.
Los problemas del SoS que impliquen cambios de alcance se comunican en el PO Sync, y viceversa.
En SAFe 5, ambos pueden combinarse en una sola reunión de ART Sync para ganar eficiencia, pero lo importante es que tanto la visión de proceso (Scrum Masters) como la de contenido (Product Owners y Product Manager) estén sincronizadas de forma regular.

SEGUIMIENTO Y COMUNICACIÓN

El RTE y el Product Manager realizan conjuntamente el seguimiento del progreso general del PI.
Muchos ARTs utilizan un Program Kanban o paneles de control en sus herramientas ágiles para visualizar el estado de cada feature (por ejemplo, columnas como “En progreso”, “Aceptado por producto”, “Completado”).
El RTE mantiene esta visión global, actualizando el estado cuando una feature se entrega completamente o destacando bloqueos importantes.
Las System Demos, al final de cada iteración, ofrecen evidencia tangible del progreso: software funcionando.
Estos incrementos integrados son la principal medida de avance del ART, más importante que cualquier plan detallado.
El RTE se asegura de que haya una System Demo al final de cada iteración (o incluso con más frecuencia).
En ella, todas las nuevas features de los equipos se integran (normalmente con apoyo del System Team) y se presentan a los Business Owners, Product Manager, clientes (si aplica) y otros stakeholders.
El RTE facilita o coordina la presentación de esta demo, que mantiene el foco en la integración y la calidad, ayudando a detectar problemas de integración o desalineaciones tempranas.

GESTIÓN DE CAMBIOS

A pesar de toda la planificación, pueden ocurrir cambios durante el PI: una nueva regulación, una dependencia que no se cumple, o una prioridad de negocio que varía.
El Product Manager, junto con los Business Owners y el RTE, gestiona los cambios de alcance significativos a través del Program Backlog y los comunica a los equipos en el PO Sync.
Los ajustes menores (como intercambiar historias entre equipos) pueden resolverse de manera inmediata.
Lo importante es que los cambios se hagan con transparencia: todos deben saber si se agrega un nuevo ítem o si cambian las prioridades.
En algunos casos, incluso los PI Objectives pueden actualizarse, aunque en general se procura minimizar los cambios dentro del PI para mantener el enfoque.

DEVOPS Y LIBERACIONES

Durante la ejecución, si el ART practica entrega continua, pueden realizarse releases o despliegues bajo demanda.
El RTE apoya el pipeline de DevOps, coordinando actividades de liberación entre equipos cuando es necesario.
Por ejemplo, si varios equipos deben coordinar una entrega conjunta o una integración tardía, el RTE y el System Architect se aseguran de que se realice sin fricciones.
Fomentan una cultura de Built-in Quality, en la que cada incremento sea potencialmente liberable.
Algunos trenes incluso liberan ciertas features a los usuarios durante el PI si están listas, siguiendo el principio de “develop on cadence, release on demand”.
El Product Manager y los Business Owners deciden qué features se liberan y cuándo, pero la infraestructura del tren (con soporte de DevOps) debe permitir que la decisión de liberar sea de negocio, no técnica.

Durante la ejecución del PI, las herramientas son fundamentales para mantener a todos alineados.
Los equipos y los Product Owners actualizan el estado y las dependencias en Jira (por ejemplo, vinculando una historia del Equipo B con una historia del Equipo A de la que depende, de modo que la dependencia sea visible).
Muchos ARTs también utilizan un espacio compartido en Confluence o una plataforma similar para documentar los PI Objectives, las notas de las demos y los registros de riesgos, facilitando así su consulta.

Los tableros visuales (como Jira Advanced Roadmaps o las vistas de portafolio de Rally) permiten obtener una vista general del progreso hacia los PI Objectives en todos los equipos, la cual el RTE puede revisar en cada ART Sync.
Esta comunicación continua garantiza que no haya sorpresas al final del PI y que el ART pueda adaptarse si algo se desvía del plan.

Al final de la fase de ejecución (normalmente después de 5-6 iteraciones, según la duración del PI), el ART debería haber entregado las Features planificadas y cumplido los PI Objectives (o al menos saber por qué no se lograron y tener un plan para el trabajo restante).
La última iteración suele ser una Innovation & Planning (IP) Iteration, un periodo de buffer donde los equipos pueden innovar, trabajar en spikes o hackathons, y prepararse para el siguiente PI.
También es cuando el ART realiza su taller de Inspect & Adapt.

A medida que el ART despliega sus entregables y enfrenta los imprevistos, llega el momento de reflexionar y mejorar. El ciclo de ejecución no termina con la última iteración, sino que abre la puerta al momento clave donde el aprendizaje colectivo se convierte en evolución organizacional. En el siguiente post de la serie abordaremos el evento Inspect & Adapt, vital para analizar resultados, detectar áreas de mejora y fortalecer el ciclo virtuoso de aprendizaje y desarrollo ágil del tren y sus equipos.

POSTS DE LA SERIE SAFe APLICADO

1. Organiza tu SAFe ART paso a paso: roles, preparación y claves de éxito

2. PI Planning en SAFe: cómo alinear equipos y stakeholders en un plan común

3. Ejecución eficiente de un Program Increment: gestión, seguimiento y comunicación en SAFe

4. Inspect & Adapt en SAFe: mejora continua y retrospectiva efectiva de ARTs

5. Artefactos y herramientas SAFe: claves para la alineación y transparencia en equipos ágiles

6. Checklist definitivo y recapitulación: cómo sobrevivir y triunfar en tu primer PI SAFe