Agility at Scale: Scrum Beyond the Team

A few months ago I worked with an organization that was convinced it had a problem with Scrum. "It doesn't work," they told me in our first meeting. When I sat down with one of their teams, I discovered the opposite: that team worked beautifully, delivered every two weeks, and morale was high. The problem wasn't the team. It was everything happening around it: eight other teams that depended on one another, a rigid annual plan, and a leadership team that kept asking for exact dates twelve months out. What was broken wasn't Scrum, but the idea that it could be copied verbatim from a team to the entire company. Over these years I've seen the pattern repeat so many times that it's worth pausing to understand it.

The short version: Scrum is designed for a small, autonomous team, and at that scale it works very well. When you move up to the level of several teams and the whole organization, dependencies, coordination, and governance appear that a single framework doesn't solve. Scaling agility isn't multiplying ceremonies, but redesigning how work is coordinated, decided, and funded.

Why does Scrum work so well within a team?

Scrum elegantly solves a narrow problem: how to get a group of five to nine people to deliver value incrementally, inspect what they did, and adapt. Almost all of its strength comes from three conditions that occur naturally at that scale.

• A single backlog and a single owner: the Product Owner prioritizes, and everyone pulls from the same list. There's no ambiguity about what matters most.
• High-bandwidth communication: nine people talk face to face. A question is resolved in thirty seconds by swiveling your chair.
• A manageable complexity limit: the team fits in one room, the work fits on one board, and the sprint fits in everyone's head.

When these three conditions are met, Scrum feels almost magical. The mistake is to think that magic is transferable through simple repetition. If you want to review the fundamentals of the framework at the team level, I wrote earlier about how to apply Scrum well from the very first sprint; here I'm interested in what happens when there are many teams at once.

What exactly breaks when scaling?

The problem isn't that Scrum "stops working." It's that the three conditions above disappear one by one the moment we go from one team to ten. What was trivial becomes costly.

• Dependencies multiply. With one team there are no external dependencies. With ten teams sharing a single platform, each story can touch the work of three others. What used to be resolved by swiveling your chair now requires negotiation.
• The single backlog fragments. Ten Product Owners appear with ten local priorities, all reasonable, none aligned with a single product vision.
• Communication stops being free. The number of possible conversations grows quadratically. What was a chat among nine people becomes a matrix of meetings among ninety.
• Integration becomes the bottleneck. Each team can finish its sprint and, even so, the product doesn't work because the pieces don't fit together.

None of these problems are about attitude or discipline. They're structural problems that arise simply by growing. That's why the answers also have to be structural.

What changes at the organizational level?

Scaling agility forces decisions that didn't even exist within a single team. In my experience, there are four fronts every organization has to resolve explicitly, no matter which framework it adopts.

• Alignment of priorities. Someone has to connect the teams' backlogs with the business objectives. This usually takes the form of joint, recurring planning where the teams synchronize on what they're aiming for in the next block of work.
• Dependency coordination. You need a space where dependencies between teams are made visible and managed before they blow up, not after.
• A shared definition of "done." If each team understands "done" in its own way, integration never closes. Quality has to be defined at the product level, not the team level.
• Funding by value stream. As long as the budget is allocated by annual project, the organization will remain agile in execution and rigid in investment. It's the most common contradiction and the hardest to resolve.

Frameworks like SAFe, LeSS, or Nexus are trying precisely to address these four fronts. They're worth knowing, but with a caveat: they're starting points, not recipes. Adopting a scaling framework to the letter tends to reproduce the same original mistake at a larger size.

What are the most common mistakes when scaling?

These are the missteps I see most often when an organization tries to take Scrum beyond the team. Recognizing them in time saves months of frustration.

• Confusing more ceremonies with more agility. Doubling meetings coordinates nothing; it only consumes the time teams need to deliver.
• Scaling without having consolidated a single team. If Scrum doesn't yet work in one cell, multiplying it only multiplies the disorder.
• Leaving the chain of command intact. "Autonomous" teams that still ask permission for every decision aren't autonomous; they're the same org chart with new vocabulary.
• Buying a framework as if it were software. Installing SAFe doesn't transform the culture; it describes practices that still have to be adapted and earned.
• Forgetting middle managers. They're the ones whose role changes most when scaling and, if no one supports them, they become the main brake out of sheer survival.

What is agile governance and why does it matter?

When I talk about agile governance, I don't mean more control, but changing the nature of control. Traditional governance asks, "Did you follow the plan?" Agile governance asks, "Are we delivering value and learning fast?" It's a profound shift in what leadership looks at and demands.

• From milestones to outcomes: measuring value delivered and customer behavior, not percentage of progress against a frozen plan.
• From approvals to boundaries: giving teams a clear decision-making framework so they don't have to escalate every step upward.
• From reports to transparency: live dashboards instead of reports that arrive late and dressed up.
• From cost control to investment management: reviewing frequently where to put the money, based on what the market keeps confirming.

Without agile governance, leadership keeps asking for certainties the method no longer delivers, and teams end up manufacturing fictional plans to reassure their bosses. It's the perfect recipe for "agile" to lose credibility at the top.

When should you combine agility with project management?

Here I'm deliberately undogmatic. Agility doesn't replace project management in every context; it coexists with it. There's work that benefits from Scrum and work that still needs a more predictive approach, especially when there's regulation, fixed-price contracts, physical integrations, or external dependencies with immovable dates.

In practice, large organizations operate in a hybrid mode: agile teams delivering increments, within a portfolio framework that does need coordination, budget, and accountability. Formal project management practices, such as those systematized in the PMI body of knowledge, remain very useful for governing the portfolio, managing cross-cutting risks, and communicating with stakeholders who think in terms of projects. The art lies in knowing which layer moves at which speed, without forcing the entire company to move at the same rhythm.

Frequently asked questions

Do I need a framework like SAFe to scale Scrum?
Not necessarily. A framework gives you a common language and a starting point, but the underlying problem (dependencies, alignment, governance) has to be solved in your context. Many organizations progress well by combining practices from several frameworks and discarding what doesn't serve them.

How many teams can I coordinate before needing additional structure?
As a rule of thumb, as long as the teams fit in the same planning room and share a clear product, coordination is light. Beyond a handful of interdependent teams, it's worth introducing explicit synchronization and governance.

Is scaling agility a matter of method or of culture?
Both, but culture weighs more. Practices are learned in weeks; the willingness to delegate decisions and tolerate uncertainty takes much longer. If leadership doesn't change how it governs, no framework will save it.

Can I keep Scrum in the teams and project management in the portfolio?
Yes, and it's usually the most sensible approach in large organizations. The key is to define clearly the boundary between the two layers so they don't contradict or duplicate each other.

The first step

If your organization feels that Scrum "doesn't scale," it's most likely that the method is fine and what's missing is organizational design around it. Before adopting a complete framework, it's worth doing an honest diagnostic: where the real dependencies are, which decisions keep escalating when they shouldn't, and how work is funded today. At SUMāTO we support that diagnostic with a consultant's judgment, looking at the whole organization and not just the ceremonies. If you'd like to discuss it with your specific case on the table, write to us and let's schedule a conversation. The first step is almost never to scale faster; it's to understand well what needs to scale.