En los últimos años trabajando como agile coach me he encontrado con una conversación recurrente en diferentes compañías, ¿Como escalar la agilidad en mi empresa? y antes de responder esta pregunta me gustaría poner sobre la mesa dos premisas importantes, primero que no existe una Bala de Plata, lo que ha funcionado en un contexto no significa en va a funcionar en otro y lo segundo no puedes escalar algo que no tienes o no existe, es decir, si no has adoptado agilidad en a nivel micro (equipos que diseñen y desarrollen soluciones, productos o incrementos de calidad constantemente), me lo pensaría dos veces antes de pensar adoptar algún framework de escalado, porque lo único que vas a escalar son los posibles oportunidades de mejora que hoy ya tienes.
¿Cuándo realmente necesitamos empezar a hablar de escalar la agilidad?
Realmente no hay un parámetro que nos hable de ello, basado en mi experiencia existe una situación que nos puede dar un pista; cuando existen más de dos equipos trabajando en una solución y empezamos a perder enfoque, transparencia, comunicación y sincronización. Por lo tanto podemos decir que si somos más personas colaborando se tornan más complejo las interacciones.
Respondiendo a la pregunta de ¿cómo escalar la agilidad?. Existen diferentes Frameworks que nos pueden ayudar o guiar en el camino de escalar la agilidad y aunque todos comparten principios ágiles, su enfoque y aplicación práctica varían significativamente. Este artículo brinda una visión práctica desde la experiencia con el fin de que te pueda guiar a la hora de elegir, aquí te dejo visión general de los framework que he usado
SAFe (Scaled Agile Framework)
Es un marco prescriptivo y estructurado que busca alinear estrategia y ejecución en toda la organización. Introduce nuevos niveles (Program, Large Solution, Portfolio) y roles para facilitar la coordinación y la entrega de valor en grandes entornos empresariales.
Ventajas:
- Alineación estratégica clara usando sus artefactos, eventos y Roles.
- Funciona en organizaciones grandes que necesitan estructura para empezar.
- Marco robusto para gestionar portafolio, programas y equipos
- Facilita auditorías y compliance
Posibles desafíos:
- El gran desafío suele ser evitar una adopción mecánica sin evolución cultural real. Puede generar burocracia excesiva si se aplica de forma rígida.
- Requiere una gran inversión en formación y cambio cultural.
Experiencia práctica real:
Un grupo financiero en Chile, SAFE nos permitió alinear, enfocar y sincronizar más de 15 equipos en diferentes países, usando como pilar estratégico la Product Increment Planning, sin embargo los primeros pasos fueron lentos y la adopción de los nuevos eventos y roles fue un gran desafío. Aquí la clave es la formación clara y sencilla, fomentando la adopción incremental del marco.
LeSS (Large-Scale Scrum)
Se basa en los principios de Scrum, promoviendo la simplicidad organizacional y la eliminación de roles y capas innecesarias. Favorece una estructura plana y equipos multidisciplinarios que comparten un único Product Backlog.
Ventajas:
- Promueve la reducción de capas intermedias (Jefes), lo cual brinda gran autonomía a los equipos.
- Utiliza un solo Product Backlog y promueve la colaboración directa entre equipos para gestionar dependencias. Aquí, la sincronización es más orgánica y basada en la comunicación directa.
- Funciona para sincronizar entre 3 y 10 equipos
Posibles desafíos:
- No es para todos. Requiere una mentalidad profundamente ágil, pero donde hay madurez y compromiso con la mejora continua, puede liberar un enorme potencial.
- Como solo tenemos un Product Backlog, es necesario tener un Gran Product Owner.
- Puede generar gran resistencia al cambio en organizaciones con estructura arraigadas
- La coordinación entre equipos depende mucho de buenas prácticas adoptadas y comunicación informal.
Experiencia práctica real:
Startup en Colombia. 6 equipos trabajando con scrum, LeSS nos permitió escalar sin perder velocidad. Al principio, el único Product Owner tuvo dificultades para gestionar todo el backlog, pero tras reforzar el equipo con business analysts y reforzar las prácticas técnicas, la entrega se estabilizó.
Nexus
Creado por los autores de Scrum, también parte de Scrum pero con un enfoque técnico. Está diseñado para coordinar entre 3 y 9 equipos que trabajan en un único producto, con énfasis en la integración continua y la gestión de dependencias técnicas.
Ventajas:
- Es menos intrusivo en términos organizativos, añade pocos roles (como el Nexus Integration Team) lo que permite una adopción más progresiva sin grandes cambios en la jerarquía.
- Foco en la integración técnica, fomenta refinamientos cruzados, integración diaria y una fuerte disciplina técnica para evitar cuellos de botella y conflictos en el código.
- Ideal cuando varios equipos técnicos trabajan sobre un único producto y tienen buenas prácticas de ingeniería. Su principal limitación es el alcance reducido (no abarca áreas de negocio ni estrategia).
Posibles desafíos:
- No impone grandes cambios estructurales, pero sí exige una cultura técnica avanzada (prácticas de CI/CD, calidad, pruebas automatizadas) para que la integración funcione
- Escalabilidad acotada.
- Poco conocido, requiere formación formal.
- Depende de prácticas como el DOD bien definido y compartido para lograr las integraciones de la solución
Experiencia práctica real:
Empresa Retail mediana (650 personas) en Chile , Nexus permitió mejorar la calidad del producto al introducir prácticas de integración continua entre equipos. Sin embargo, hasta que no reforzamos la definición de DoD, las integraciones de la solución al inicio y al finalizar el sprint no se realizaron con éxito.
Reflexión final
No existe un marco perfecto, solo uno más adecuado a la situación, cultura y objetivos de cada organización. Escalar la agilidad es más que elegir un framework. Es rediseñar la forma en que colaboramos, priorizamos y aprendemos a nivel organizativo. Como Agile Coach, mi consejo es claro: Empieza pequeño, experimenta, aprende y evoluciona. No te cases con un framework; cásate con los principios valores.
Referencias
