Blog

Scaled Agile Framework (SAFe) es un marco de trabajo integral y públicamente disponible diseñado para ayudar a grandes organizaciones a adoptar y escalar las metodologías ágiles a nivel empresarial. En esencia, SAFe aborda el desafío de implementar Agile en organizaciones grandes y complejas que necesitan coordinar el trabajo de múltiples equipos ágiles para entregar soluciones de software y sistemas a gran escala.

¿Por qué SAFe?

Las metodologías ágiles tradicionales como Scrum o Kanban son muy efectivas para equipos pequeños y auto-organizados. Sin embargo, cuando una empresa tiene cientos o miles de empleados trabajando en diferentes productos, proyectos o líneas de negocio, la coordinación y la alineación se vuelven extremadamente complejas. SAFe surge como una solución para mantener la agilidad a nivel de equipo, mientras se proporciona una estructura para la alineación, la colaboración y la entrega de valor en toda la organización.

Conceptos Clave y Componentes de SAFe:

SAFe se basa en una serie de principios Lean-Agile y DevOps, y está estructurado en varios niveles que definen roles, responsabilidades, artefactos y eventos. Aunque existen diferentes configuraciones de SAFe (Essential, Large Solution, Portfolio, Full SAFe), los niveles principales y los componentes comunes son:

1. Nivel de Equipo (Team Level):

   • Aquí es donde los equipos ágiles (generalmente equipos Scrum o Kanban) desarrollan y prueban las funcionalidades del producto.
   • Cada equipo es auto-organizado y multifuncional, entregando incrementos de valor en iteraciones cortas (sprints).
   • Roles: Scrum Master, Product Owner, Equipo de Desarrollo.
   • Artefactos: Backlog del Equipo, Iteration Goals, Incremento de Software.

2. Nivel de Programa (Program Level):

   • Este nivel organiza a los equipos en lo que se conoce como Agile Release Trains (ARTs). Un ART es un “equipo de equipos” que colabora para entregar soluciones completas.
   • Los ARTs planifican juntos en un evento clave llamado PI Planning (Program Increment Planning), que es una reunión de varios días donde todos los equipos del ART se alinean en torno a objetivos comunes para el próximo incremento de programa (generalmente de 8 a 12 semanas).
   • Roles: Release Train Engineer (RTE – el “Scrum Master” del ART), Product Management, System Architect/Engineer, Business Owners.
   • Artefactos: Program Backlog, Program Increment (PI) Objectives, Solution Demos.

3. Nivel de Solución (Large Solution Level – Opcional):

   • Para soluciones extremadamente grandes y complejas que requieren la colaboración de múltiples ARTs, SAFe introduce el nivel de Solución.
   • Aquí, se coordina el trabajo de varios ARTs a través de un Solution Train.
   • Roles: Solution Train Engineer (STE), Solution Management, Solution Architect/Engineer.
   • Artefactos: Solution Backlog, Solution Vision.

4. Nivel de Portafolio (Portfolio Level):

   • Este es el nivel estratégico, donde la empresa define y prioriza el flujo de valor para sus productos y soluciones.
   • Alinea la ejecución ágil con la estrategia empresarial y el presupuesto.
   • Roles: Epic Owners, Enterprise Architect, Lean-Agile Center of Excellence (LACE).
   • Artefactos: Portfolio Epics, Lean Budgets, Portfolio Kanban.

Principios Fundamentales de SAFe:

SAFe se basa en una serie de principios, incluyendo:

• Adoptar una perspectiva económica: Entender el impacto financiero de las decisiones y prioridades.
• Aplicar el pensamiento sistémico: Ver la organización como un sistema interconectado.
• Asumir la variabilidad y preservar las opciones: Tomar decisiones más tarde y basarse en datos empíricos.
• Construir de forma incremental con ciclos de aprendizaje rápidos: Entregar valor continuamente y aprender de cada iteración.
• Establecer hitos basados en la evaluación objetiva de los sistemas de trabajo: Medir el progreso a través de la entrega de valor real.
• Visualizar y limitar el trabajo en curso (WIP), reducir el tamaño de los lotes y gestionar las colas: Mejorar el flujo y la eficiencia.
• Aplicar cadencia y sincronización: Regular el ritmo de trabajo y coordinar los esfuerzos.
• Desbloquear la motivación intrínseca de los trabajadores del conocimiento: Empoderar a los equipos y fomentar la autonomía.
• Descentralizar la toma de decisiones: Tomar decisiones a nivel adecuado para una mayor agilidad.
• Organizar alrededor del valor: Estructurar la organización para entregar valor al cliente de manera eficiente.

Beneficios de SAFe:

• Alineación estratégica: Ayuda a que todos los equipos trabajen hacia los mismos objetivos empresariales.
• Mejora de la comunicación y colaboración: Facilita la interacción entre equipos y departamentos.
• Mayor visibilidad y transparencia: Permite a la organización tener una visión clara del progreso y los impedimentos.
• Entrega de valor más rápida: Acelera el ciclo de desarrollo y la entrega de productos al mercado.
• Mayor calidad: Fomenta la calidad integrada en cada etapa del desarrollo.
• Adaptabilidad al cambio: Permite a las grandes organizaciones responder rápidamente a los cambios del mercado.

Críticas a SAFe:

A pesar de sus beneficios, SAFe también ha recibido críticas, a menudo relacionadas con:

• Complejidad y burocracia: Algunos argumentan que SAFe introduce demasiada estructura y procesos, lo que puede ir en contra de la agilidad.
• Costos de implementación: Requiere una inversión significativa en capacitación y herramientas.
• Enfoque “top-down”: Aunque promueve la auto-organización, su naturaleza jerárquica a veces se percibe como menos adaptable que enfoques puramente bottom-up.
• Resistencia al cambio: Implementar SAFe implica un cambio cultural importante, que puede ser difícil de lograr en organizaciones grandes.

En resumen, SAFe es un marco diseñado para ayudar a las organizaciones a escalar la agilidad más allá de los equipos individuales, proporcionando una hoja de ruta para la coordinación y la entrega de valor en entornos complejos. No es una solución universal, y su éxito depende en gran medida de una implementación cuidadosa, una comprensión profunda de sus principios y un compromiso con el cambio cultural.

El planteamiento sobre la “muerte inevitable” de las metodologías ágiles es una afirmación fuerte y que se ha discutido en el ámbito del desarrollo de software. Si bien es cierto que se han presentado desafíos y críticas, hablar de una “muerte” puede ser prematuro y quizás exagerado. Es más preciso hablar de una evolución, adaptación y la necesidad de una implementación más madura y consciente.

Aquí desglosamos los puntos que mencionas y la realidad actual:

1. “Se han enfrentado a la realidad de los números y las necesidades cada vez mayores”:

• La escala: Las metodologías ágiles nacieron en contextos de equipos pequeños y proyectos con requisitos cambiantes. Cuando se intentan aplicar a proyectos de gran envergadura, con múltiples equipos, dependencias complejas y regulaciones estrictas (como en el sector financiero o de salud), surgen dificultades. Los marcos ágiles “escalados” como SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum) o Nexus han surgido precisamente para abordar este desafío, aunque no están exentos de críticas.
• La previsibilidad: En ciertos entornos, la necesidad de una planificación y previsibilidad más a largo plazo, ligada a presupuestos y compromisos contractuales, choca con la naturaleza iterativa y adaptativa de lo ágil. Esto no significa que lo ágil sea inútil, sino que requiere una forma diferente de gestionar las expectativas y los acuerdos.

2. “Lo cual lleva a las personas del equipo de trabajo a un burn out”:

• Ritmo insostenible: Si las metodologías ágiles se implementan sin un enfoque en el ritmo sostenible y la salud del equipo, es muy probable que se produzca el burnout. La presión por entregar valor continuamente, la falta de tiempo para la refactorización, la deuda técnica acumulada y la sobrecarga de trabajo son factores que contribuyen a ello.
• Mala interpretación del “ágil”: Algunas organizaciones confunden “ágil” con “rápido a cualquier costo” o “sin planificación”. Esto lleva a exigir a los equipos entregas constantes sin darles el soporte, los recursos o el tiempo de descanso adecuados.
• Cultura organizacional: El burnout no es inherentemente un problema de las metodologías ágiles, sino más bien un síntoma de una cultura organizacional que no prioriza el bienestar de sus empleados. Una verdadera cultura ágil debería fomentar la colaboración, la autonomía, el aprendizaje y un ritmo de trabajo que permita la sostenibilidad a largo plazo.

3. “Esto debido a que se enmascara la prioridad del proyecto y se sobrepone a la necesidad del desarrollador”:

• Falta de balance: Es cierto que el enfoque ágil pone énfasis en la entrega de valor al cliente. Sin embargo, una implementación madura de lo ágil debería encontrar un balance entre las necesidades del proyecto y las necesidades del equipo.
• La importancia del “Equipo Auto-Organizado”: Un principio fundamental de Scrum (una de las metodologías ágiles más populares) es el equipo auto-organizado. Esto implica que el equipo tiene un alto grado de autonomía para decidir cómo va a hacer el trabajo y cuánto trabajo puede asumir de manera sostenible. Si esta autonomía es ignorada o suprimida, el burnout es una consecuencia lógica.
• El rol del Product Owner y el Scrum Master: El Product Owner es responsable de maximizar el valor del producto, pero el Scrum Master es responsable de asegurar que el equipo esté funcionando de manera efectiva y sostenible, eliminando impedimentos y protegiendo al equipo de interrupciones o sobrecarga. Un buen Scrum Master es crucial para evitar el burnout.

¿Muerte o Evolución?

En lugar de una “muerte”, lo que estamos presenciando es una maduración y adaptación de las metodologías ágiles:

• Enfoque en la sostenibilidad: Cada vez hay más conciencia sobre la importancia de un ritmo de trabajo sostenible, el bienestar del equipo y la prevención del burnout.
• Agilidad cultural: Se reconoce que la agilidad no es solo un conjunto de procesos, sino una mentalidad y una cultura organizacional. Sin un cambio cultural profundo, las implementaciones ágiles superficiales están destinadas al fracaso.
• Hibridación: Muchas organizaciones están adoptando enfoques híbridos, combinando elementos ágiles con prácticas más tradicionales cuando sea apropiado.
• Énfasis en el valor real: Más allá de la velocidad, se busca la entrega de valor real y la adaptación constante a las necesidades cambiantes del mercado.
• Diversificación: Han surgido y se han consolidado diferentes enfoques y marcos ágiles (Kanban, Scrumban, etc.), que ofrecen más flexibilidad para adaptarse a distintos contextos.

Conclusión:

Las metodologías ágiles no están “muriendo”, pero están siendo desafiadas a evolucionar y a ser implementadas de una manera más inteligente y humana. Los problemas de burnout y la tensión entre las necesidades del proyecto y del desarrollador son, en muchos casos, el resultado de una mala implementación o una falta de comprensión profunda de los principios ágiles, más que una falla inherente a las metodologías en sí mismas.

El futuro de la agilidad reside en su capacidad para adaptarse a contextos más complejos, para priorizar la sostenibilidad y el bienestar de los equipos, y para integrarse de manera efectiva con la estrategia y la cultura organizacional.