Agilidad

SAFe y agilidad a escala: cuándo y cómo pasar de Scrum al Scaled Agile Framework

Por Codevista InnovationsPublicado el 12 de octubre de 2026Actualizado el 15 de octubre de 202610 min de lectura

SAFe (Scaled Agile Framework) tiene sentido cuando varios equipos ágiles entregan juntos una misma solución y las dependencias, las prioridades divergentes y la integración tardía anulan lo que cada equipo gana con Scrum. Añade una estructura, el Agile Release Train; un evento de planificación común, el PI Planning; y una gestión de cartera Lean, a cambio de roles y eventos adicionales. Antes de adoptarlo, compruebe que su problema nace realmente de la coordinación entre equipos y que la dirección está dispuesta a implicarse personalmente.

¿Cómo saber si Scrum ya no es suficiente?

Scrum está pensado para un equipo reducido capaz de entregar por sí solo un incremento utilizable. Mientras un producto quepa en uno o dos equipos, aplicar mejor Scrum o pasar a Kanban suele resolver lo esencial (consulte nuestra comparativa Scrum o Kanban). Las dificultades cambian de naturaleza cuando varios equipos trabajan sobre la misma solución:

• Dependencias en cadena: un equipo espera una API, un entorno o una validación de otro, y el sprint termina sin un incremento utilizable.
• Prioridades desalineadas: cada Product Owner optimiza su propio backlog, nadie arbitra entre equipos y el negocio recibe fragmentos de funcionalidades que, por separado, no sirven para nada.
• Una integración dolorosa: cada equipo da su trabajo por «terminado» por su cuenta y, al final del trimestre, el ensamblaje se parece punto por punto a la antigua fase de integración del ciclo en V.
• Ninguna visibilidad para la dirección, que acaba exigiendo planificaciones detalladas a seis meses, en contradicción con los sprints.

Una prueba sencilla: repase los impedimentos señalados en las últimas retrospectivas. Si se refieren sobre todo al funcionamiento interno de cada equipo, el problema no es la escala. Si remiten sistemáticamente a otro equipo, a un arbitraje que falta o a una integración tardía, plantearse la agilidad a escala pasa a ser legítimo.

Lo que añade SAFe: Agile Release Train, PI Planning y cartera

El Scaled Agile Framework no sustituye a Scrum ni a Kanban en el nivel de los equipos: los organiza en torno a un flujo de valor común. La referencia oficial, que es la que vale para la terminología y evoluciona de una versión a otra, se publica en scaledagileframework.com.

El Agile Release Train (ART)

Un ART es un equipo de equipos ágiles, estable en el tiempo, que comparte la misma misión, el mismo ART Backlog y la misma cadencia. Su tamaño se limita a propósito, del orden de 50 a 125 personas según la referencia oficial, para que todos puedan planificar en la misma sala. El Release Train Engineer (RTE) es su facilitador, el Product Management prioriza las features, el System Architect define la visión técnica y los Business Owners representan los intereses del negocio y validan los objetivos.

El PI Planning

El PI (Planning Interval, antes Program Increment) agrupa varias iteraciones, seguidas de una iteración de innovación y planificación (IP Iteration). Al comienzo de cada PI, todos los equipos del tren se reúnen para el PI Planning, normalmente durante dos días: descomponen las features, hacen visibles las dependencias en el ART Planning Board y se comprometen con unos PI Objectives. Durante el PI, la System Demo muestra el incremento integrado de todo el tren; el PI se cierra con un Inspect & Adapt.

El nivel de cartera

En la configuración Portfolio SAFe, la Lean Portfolio Management financia flujos de valor en lugar de proyectos uno a uno, y las Epics pasan por un Portfolio Kanban antes de aprobarse. A menudo es ahí donde se produce el verdadero cambio para una dirección general, porque afecta al presupuesto y a la gobernanza, no solo a la forma de trabajar de los equipos.

¿Cuánto cuesta SAFe en ceremonias y organización?

El coste de SAFe no se reduce a una factura de formación. Se mide sobre todo en tiempo y en atención:

• Roles nuevos (RTE, Product Management, System Architect), desempeñados por personas con disponibilidad real, no añadidos a un puesto que ya está completo.
• Eventos adicionales: PI Planning, System Demo, Inspect & Adapt, sincronizaciones periódicas entre equipos y refinamiento previo de las features.
• Un vocabulario común que toda la organización debe adoptar, lo que implica formación para equipos, mandos y directivos.
• Un marco propietario: SAFe es una marca de Scaled Agile, Inc., que expide las certificaciones oficiales; esto pesa en el presupuesto de formación y certificación.
• Un riesgo de burocracia si el marco se aplica mecánicamente, artefacto por artefacto, sin preguntarse qué aporta cada uno.

Este coste se justifica cuando sustituye coordinaciones informales que ya resultan caras: reuniones de crisis, arbitrajes por escalado, semanas perdidas en integración. No se justifica para dos equipos que podrían simplemente compartir un backlog y una revisión.

SAFe, LeSS, Scrum@Scale o Kanban: ¿qué alternativas existen?

SAFe es el marco más completo y más prescriptivo, pero no el único. Las alternativas no son ni mejores ni peores por principio; simplemente apuestan por otras cosas:

• LeSS (Large-Scale Scrum): un único Product Owner y un único Product Backlog para varios equipos, con muy pocos roles añadidos. Exige madurez técnica y un rediseño de la organización.
• Scrum@Scale: una extensión modular de Scrum que hace crecer la organización mediante redes de equipos conectadas entre sí.
• Nexus: el marco de Scrum.org para unos pocos equipos Scrum que trabajan sobre un mismo producto, con un equipo de integración dedicado.
• Un Kanban de cartera bien gestionado: hacer visibles todas las iniciativas en curso, limitar el trabajo en curso en el nivel de la dirección y arbitrar a intervalos regulares. Suele ser el primer paso menos costoso y prepara el terreno para cualquier marco posterior.

SAFe encaja sobre todo en grandes estructuras que necesitan roles explícitos, una gobernanza de cartera y un lenguaje común con la dirección. Para un producto que sostienen tres o cuatro equipos, un marco más ligero suele resultar más proporcionado.

¿Por qué fracasa una implantación de SAFe?

Los fracasos se parecen mucho de una organización a otra:

• Trenes organizados por departamento en lugar de por flujo de valor: reproducen los silos con otro nombre.
• Equipos que no dominan Scrum: sin iteraciones estables ni una Definition of Done compartida, la escala amplifica el desorden.
• Un PI Planning impuesto: la dirección llega con un alcance y una fecha cerrados, sin tener en cuenta la capacidad que anuncian los equipos.
• Prioridades que cambian a mitad de PI sin pasar por el Product Management, lo que vacía de sentido los PI Objectives.
• Prácticas técnicas débiles: sin integración continua ni pruebas automatizadas, la System Demo enseña pantallas, no un sistema integrado.
• Un marco adoptado por imagen, sin medir el flujo ni los resultados de negocio.

Ninguna de estas causas se debe al marco en sí: son organizativas. Por eso la preparación pesa más que la elección entre SAFe y sus competidores.

¿Cómo preparar un primer PI Planning?

Un primer PI Planning se prepara a lo largo de varias semanas. Los pasos esenciales:

1. Identificar el flujo de valor y los equipos que contribuyen a él, incluidas las funciones de soporte imprescindibles (seguridad, operaciones, cumplimiento normativo).
2. Nombrar y formar los roles clave: RTE, Product Management, System Architect, Business Owners, así como los Scrum Masters y Product Owners de los equipos.
3. Construir el ART Backlog: features priorizadas, con criterios de aceptación e hipótesis de valor de negocio. Los requisitos normativos, como la protección de datos personales en virtud de la ley marroquí 09-08 (loi 09-08), figuran en él desde el principio, no al final del PI.
4. Preparar la visión que la dirección presentará en la apertura: contexto de negocio, objetivos, restricciones e hitos conocidos.
5. Calcular la capacidad de cada equipo, teniendo en cuenta vacaciones, días festivos y la parte reservada al mantenimiento.
6. Organizar la logística: sala o herramienta colaborativa, ART Planning Board, orden del día cronometrado y responsables de decisión presentes de principio a fin.

Durante el evento

El desarrollo habitual alterna sesiones plenarias y trabajo por equipos: presentación del contexto de negocio, de la visión de producto y de la visión de arquitectura, y después talleres en los que cada equipo construye su plan de iteraciones. Una revisión de los planes provisionales y una sesión de resolución de problemas con la dirección permiten ajustar el alcance. El segundo día, los equipos presentan sus planes finales, los riesgos se tratan según el método ROAM (Resolved, Owned, Accepted, Mitigated) y un voto de confianza cierra el ejercicio. Un voto bajo no es un fracaso: es la señal de que hay que replanificar antes de comprometerse.

Cuando los equipos están repartidos entre varias sedes, en Casablanca, en otras ciudades de Marruecos o en el extranjero, un formato híbrido bien equipado funciona, siempre que los Business Owners sigan localizables para arbitrar durante los dos días.

Lo que la dirección debe comprometer para que SAFe funcione

SAFe no se puede delegar en el departamento de sistemas de información. La dirección general debe:

• Participar: los Business Owners asisten al PI Planning, a la System Demo y al Inspect & Adapt, y asignan un valor de negocio a los PI Objectives.
• Financiar flujos de valor en lugar de proyectos, lo que obliga a revisar el ciclo presupuestario.
• Proteger el PI: nada de urgencias reintroducidas sin arbitraje y pocas iniciativas en paralelo.
• Impulsar la transformación: designar un equipo de dirección del cambio, que la referencia oficial denomina Lean-Agile Center of Excellence (LACE), y darle tiempo y autoridad.
• Formarse en liderazgo ágil y aceptar que harán falta varios PI antes de que un tren encuentre su ritmo.

Las áreas de RR. HH., finanzas o marketing se ven implicadas en cuanto los flujos de valor las atraviesan (consulte la agilidad más allá de TI). Para una pyme, un enfoque más ligero suele encajar mejor en una transformación digital progresiva.

Codevista Innovations ofrece una formación SAFe para las organizaciones que superan el marco de un solo equipo, y una formación Scrum para consolidar las bases, presencial en todo Marruecos, híbrida o a distancia. Nuestro expediente de cualificación ante la OFPPT, el organismo público marroquí de formación profesional, está en curso, por lo que estos programas aún no pueden financiarse con sus Contratos Especiales de Formación (CSF). Para valorar si SAFe se ajusta a su situación, contacte con nuestro equipo.

Preguntas frecuentes

¿Cuántos equipos hacen falta para justificar SAFe?

No existe un umbral mágico. Un Agile Release Train reúne varios equipos ágiles que entregan una misma solución, del orden de 50 a 125 personas según la referencia oficial. Con dos o tres equipos, un backlog común, revisiones conjuntas o un marco ligero como Nexus o LeSS suelen bastar. El criterio decisivo es el grado de dependencia entre equipos y la necesidad de una planificación común visible para la dirección.

¿Qué diferencia hay entre el PI Planning y el Sprint Planning?

El Sprint Planning afecta a un solo equipo y a una iteración. El PI Planning reúne a todos los equipos de un Agile Release Train, junto con el Product Management, la arquitectura y los Business Owners, para planificar en conjunto un Planning Interval de varias iteraciones. Hace visibles las dependencias y desemboca en unos PI Objectives. Después, cada equipo mantiene su propia planificación de iteración dentro del PI.

¿Hay que dominar Scrum antes de pasar a SAFe?

Sí, es muy recomendable. SAFe se apoya en equipos capaces de entregar un incremento funcional en cada iteración, con roles claros y una Definition of Done compartida. Si los equipos ya tienen dificultades con los fundamentos, escalar amplifica los problemas en lugar de resolverlos. Por eso, consolidar Scrum o Kanban en el nivel de los equipos suele ser el primer paso.

¿Puede la OFPPT financiar una formación SAFe en Marruecos?

El mecanismo existe: los Contratos Especiales de Formación (CSF) de la OFPPT permiten a la empresa recuperar parte de sus gastos de formación. El expediente de cualificación de Codevista Innovations está en curso; mientras tanto, sus programas, entre ellos la formación SAFe, no pueden acogerse a esta financiación. Las condiciones de acceso y el procedimiento los fija la OFPPT: compruébelos directamente con el organismo antes de iniciar el trámite. Nuestro artículo sobre la financiación CSF explica el funcionamiento.