Over the past few years working as an Agile Coach, I have often encountered the same recurring question across different organisations: “How do I scale agility in my company?”
Before attempting to answer, I usually highlight two important premises:
- There is no silver bullet. What works well in one context does not necessarily work in another.
- You cannot scale what does not exist. If agility has not yet been adopted at the micro level—meaning teams consistently design, develop, and deliver solutions, products, or quality increments—I would think twice before adopting a scaling framework. Otherwise, all you will be scaling are the existing areas for improvement.
When do we actually need to start talking about scaling agility?
There is no universal metric that dictates the right moment. However, based on my experience, a key indicator emerges when more than two teams are working on the same solution and we begin to lose focus, transparency, communication, and synchronisation. The more people involved, the more complex the interactions become.
How can we scale agility?
Several frameworks provide guidance on scaling agility. Although all of them are rooted in agile principles, their focus and practical application vary considerably. In this article, I offer a practitioner’s perspective on three widely used frameworks to help guide your decision.
SAFe (Scaled Agile Framework)
SAFe is a prescriptive, structured framework designed to align strategy and execution across the organisation. It introduces additional levels (Programme, Large Solution, Portfolio) and roles to facilitate coordination and value delivery in large enterprise environments.
Advantages
- Provides clear strategic alignment through defined artefacts, events, and roles.
- Works well in large organisations that need structure to get started.
- A robust framework for managing portfolios, programmes, and teams.
- Facilitates audits and compliance.
Potential challenges
- Risk of mechanical adoption without genuine cultural evolution.
- Can create excessive bureaucracy if applied rigidly.
- Requires significant investment in training and cultural change.
Practical experience
In a financial group in Chile, SAFe enabled us to align, focus, and synchronise more than 15 teams across different countries. The Product Increment Planning was a strategic pillar. However, the early stages were slow, and adopting new events and roles proved challenging. The key was providing clear, simple training and fostering incremental adoption of the framework.
LeSS (Large-Scale Scrum)
LeSS builds directly on Scrum principles, promoting organisational simplicity and the elimination of unnecessary roles and layers. It supports a flat structure and multidisciplinary teams sharing a single Product Backlog.
Advantages
- Reduces hierarchical layers, empowering teams with greater autonomy.
- Uses a single Product Backlog and encourages direct collaboration across teams to manage dependencies, leading to more organic synchronisation.
- Works effectively with 3 to 10 teams.
Potential challenges
- Not suitable for everyone. It demands a deeply agile mindset, but where maturity and commitment to continuous improvement exist, it can unlock enormous potential.
- A single Product Backlog requires a highly capable Product Owner.
- May face resistance in organisations with entrenched structures.
- Coordination between teams relies heavily on good practices and informal communication.
Practical experience
In a Colombian start-up, six Scrum teams scaled effectively with LeSS while maintaining delivery speed. Initially, the sole Product Owner struggled to manage the backlog, but strengthening the team with business analysts and improving technical practices helped stabilise delivery.
Nexus
Created by the authors of Scrum, Nexus also builds on Scrum but with a stronger technical focus. It is designed to coordinate 3 to 9 teams working on a single product, emphasising continuous integration and the management of technical dependencies.
Advantages
- Minimal organisational disruption, adding only a few roles (e.g. Nexus Integration Team), allowing progressive adoption without major hierarchy changes.
- Strong emphasis on technical integration, promoting cross-team refinement, daily integration, and strict technical discipline to prevent bottlenecks and code conflicts.
- Well-suited for technical teams working on a single product with strong engineering practices.
Potential challenges
- Requires advanced technical culture (CI/CD, quality, automated testing) for integration to succeed.
- Limited scalability beyond technical coordination.
- Less widely known, so formal training is often necessary.
- Relies heavily on a well-defined, shared Definition of Done to ensure solution integration.
Practical experience
In a mid-sized retail company in Chile (approx. 650 staff), Nexus improved product quality by introducing continuous integration practices across teams. However, until the Definition of Done was reinforced, solution integrations at the start and end of sprints were not consistently successful.
Final Reflection
There is no perfect framework—only the one that best fits the context, culture, and objectives of your organisation. Scaling agility is not merely about choosing a framework; it is about redesigning how we collaborate, prioritise, and learn at the organisational level.
As an Agile Coach, my advice is simple: Start small, experiment, learn, and evolve. Don’t marry a framework—marry the principles and values.
