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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.