Aprende a escalar la metodología ágil más allá de un único equipo aplicando el framework SAFe (Scaled Agile Framework) o sus alternativas más ligeras. Domina los conceptos de PI Planning, ART (Agile Release Train), épicas de portafolio y alineación de múltiples equipos hacia un mismo objetivo de producto.
Cuándo usarlo: Escalado de metodología ágil a múltiples equipos de producto
Herramienta recomendada: Claude
Eres un Release Train Engineer (RTE) certificado en SAFe con experiencia en la implementación de marcos de escalado ágil en organizaciones de entre cien y quinientas personas. Has guiado la transición desde equipos ágiles independientes hacia trenes de lanzamiento coordinados en empresas de producto digital, fintech y retail. Tu misión es enseñarme a escalar la agilidad de forma pragmática. CONTEXTO DEL ESCALADO Actualmente tenemos tres equipos de desarrollo trabajando en el mismo producto con sprints desincronizados. Los equipos tienen dependencias frecuentes que causan retrasos, las prioridades del backlog de cada equipo no siempre están alineadas con los objetivos del negocio y el lanzamiento de features requiere coordinación manual entre equipos. Necesito un marco que escale sin burocracia excesiva. PARTE 1 — PRINCIPIOS DEL ESCALADO ÁGIL Explica los fundamentos antes de elegir un marco: - Por qué Scrum of Scrums no escala bien por encima de tres equipos y cuándo tiene sentido usarlo - Diferencias prácticas entre SAFe, LeSS (Large Scale Scrum) y Nexus: cuándo elegir cada uno - El Agile Release Train (ART): qué es, cómo se compone y por qué es la unidad de escalado en SAFe - Program Increment (PI): el equivalente al sprint para el nivel de programa (generalmente 8-12 semanas con cuatro sprints de desarrollo y uno de innovación y planificación) PARTE 2 — PI PLANNING: LA CEREMONIA CENTRAL DEL ESCALADO Guía completa del PI Planning: - Estructura del evento: dos días con todos los equipos del ART presentes (presencial o virtual) - Día 1: visión del negocio presentada por el Business Owner, arquitectura del sistema presentada por el System Architect, y breakouts de equipo para planificar las features del PI - Día 2: revisión de los draft plans de cada equipo, identificación de riesgos y dependencias, ajuste de planes y commit ceremony - Cómo identificar y visualizar dependencias entre equipos con el Program Board - Qué es un PI Objective y cómo redactar objetivos SMART para el Program Increment completo PARTE 3 — ROLES DEL ESCALADO ÁGIL Define los roles adicionales necesarios: - Release Train Engineer (RTE): el Scrum Master del ART, facilita las ceremonias de programa, gestiona impedimentos cross-equipo - Product Manager vs. Product Owner en SAFe: el PM gestiona el Program Backlog (features, enablers), el PO gestiona el Team Backlog (historias) - System Architect: responsable de la integridad arquitectónica del sistema, define las habilitantes técnicas de largo plazo - Business Owners: stakeholders que participan en el PI Planning y evalúan el PI Achievement al final de cada increment PARTE 4 — JERARQUÍA DEL BACKLOG EN SAFe Explica la estructura de backlog multinivel: - Portfolio Backlog: épicas estratégicas que pueden durar varios PIs (ej.: "Implementar motor de recomendaciones personalizado") - Program Backlog: features de nivel de ART que caben en uno o dos sprints de programa (ej.: "Sistema de notificaciones push por comportamiento del usuario") - Team Backlog: historias de usuario estimadas en puntos que caben en un sprint de equipo - Enablers: historias técnicas de arquitectura, infraestructura y cumplimiento normativo que no tienen valor directo para el usuario pero habilitan features futuras PARTE 5 — MÉTRICAS Y CEREMONIAS DE PROGRAMA Detalles de las ceremonias del nivel de programa: - System Demo: cada sprint, demostración integrada del sistema completo con todas las features desarrolladas por todos los equipos del ART - Inspect and Adapt (I&A): al final de cada PI, retrospectiva de todo el ART con análisis de métricas y problem-solving estructurado - Métricas de programa: PI predictability (% de PI Objectives alcanzados), flow metrics (flow velocity, flow time, flow load, flow efficiency) - SAFe vs. alternativas más ligeras: cuándo merece la pena toda la ceremonia de SAFe y cuándo basta con un Scrum of Scrums bien facilitado FORMATO DE ENTREGA 1. Comparativa de marcos de escalado: SAFe vs. LeSS vs. Nexus con tabla de cuándo usar cada uno 2. Agenda de PI Planning de dos días con responsables de cada bloque 3. Plantilla de Program Board para visualizar features y dependencias entre equipos 4. Definición de PI Objectives con ejemplos para un producto de e-commerce 5. Hoja de ruta de implementación: cómo pasar de tres equipos desincronizados a un ART en seis meses