Scaling Agile comes up in nearly every class I teach. The questions range from the granular (“How often should we hold Scrum of Scrums?”) to the existential (“Does SAFe ever actually work?”). But the one I hear most often sounds the simplest: why does scaling make everything so hard?

My answer is that scaling isn’t one problem. It’s three, and they arrive at different moments in your delivery cycle. Every scaling framework on the market (think SAFe, LeSS, Nexus, Scrum@Scale) is essentially a set of opinions about how to handle these three problems. Understanding them first is what lets you evaluate the frameworks instead of just adopting one.

Here they are:

1. The up-front challenge: how you decide and parse product vision across the structure.
2. The mid-sprint challenge: how you handle cross-team dependencies once work is in flight.
3. The back-end challenge: how you gather and use feedback at each level of the structure.

Let’s address them in order.

Challenge 1: How do you parse product vision across many teams?

The first problem any team-of-teams hits is how product vision gets visualized and made available to the teams doing the work. Two questions carry most of the weight: how many layers of product backlog will there be, and how many layers of Product Owners will manage them?

How many product backlogs should a scaled organization have?

A team-of-teams situation complicates refinement and planning immediately. Throughput of product backlog items (PBIs) goes up, which means a Product Owner now has to get significantly more PBIs to “ready” in time for Sprint Planning. And you have to decide who even attends refinement; every developer on every team, or representatives from each?

Option A: one unified product backlog. All teams contribute to refinement, and all teams pull from the same queue when planning sprints. This is the structure in Large Scale Scrum (LeSS) and Nexus.

• Advantages: much greater clarity about how individual team actions serve the product goal, and shared understanding of what reprioritization does across the whole system.
• Disadvantages: more sprint time ceded to overhead discussions, and significantly larger planning meetings, which are generally harder to facilitate well.

Option B: hierarchical backlogs. Product goals live at two or more levels, with higher-level goals in a program or portfolio backlog decomposed into team-sized PBIs in team backlogs. This is the structure in Scrum at Scale, LeSS Huge, and SAFe.

• Advantages: teams focus attention on refining only what’s in their queue.
• Disadvantages: it becomes much harder to see how an impediment on one team affects the program, and team-level PBIs drift away from any real understanding of the product goal they serve.

How many Product Owners do you need?

For every backlog you create, you need to decide who owns that queue.

A single Product Owner. If you’ve kept a unified backlog, you can keep a single PO with all the usual responsibilities. LeSS and Nexus work this way. Product vision stays clear and decision authority is unambiguous. The risk is obvious: one person can be swamped by refinement across many teams while also maintaining open lines with several stakeholder groups whose needs only partly overlap.

Split strategic and tactical POs. Even with one backlog, you can split the function. A Strategic PO owns forest-level direction and priority; a Tactical PO sits on each team handling tree-level refinement. I’m not aware of a formal framework that specifies this, but it’s how I handled some of my earliest scaling work. It frees up real PO attention for team-level planning and mid-sprint decisions, but you have to be deliberate about which level decides what. Otherwise, you’ve just built a new source of confusion.

A PO per backlog level. SAFe and Scrum@Scale declare Product Owners for each level of backlog in use. Decision authority is crisp. The side effect is that whole-program vision gets murkier, and the lowest-level POs lose the ability to nimbly readjust toward value when an opportunity or obstacle shows up.

Challenge 2: How do you handle cross-team dependencies mid-sprint?

Assume you’ve solved the up-front problem and organized vision across your teams. You immediately hit the next one: dependencies that surface during the iteration.

Start by reducing them. Hold rigorously to cross-functional teams. Ruthlessly restate PBIs to remove dependencies, using placeholder elements where you can. This work matters more than any coordination mechanic you bolt on afterward.

But some dependencies survive, and some you never saw coming. You need an event that surfaces problems too large for one team to solve and pulls in support to resolve them.

Scrum of Scrums. Used by Scrum@Scale, Nexus, and SAFe. Each team sends representatives to speak and listen on behalf of colleagues, in a pattern much like the Daily Scrum. Frequency varies by framework.

• Advantage: every team gets regular insight into what’s happening elsewhere, and there’s a shared forum for self-organizing around cross-team impediments.
• Disadvantage: these meetings devolve into long-winded status briefings with alarming reliability. If nobody in the room is solving anything, you’ve built a reporting ritual, not a coordination mechanism.

“Just go talk.” LeSS recommends dropping the formal event. Teams collaborate ad hoc as needed and pull others in when the problem requires it. Teams may also send a listener to another team’s Daily Scrum for awareness.

• Advantage: no meetings for meetings’ sake.
• Disadvantage: it only works if teams understand the organization well enough to know who to huddle with. That requires strong cross-program clarity of vision and team function, which usually means the organization is already serious about coaching itself to be less scaled over time.

Challenge 3: How do you preserve feedback loops at scale?

This is the last challenge and possibly the most important.

A real strength of single-team Scrum is that every sprint ends with two feedback events: a Sprint Review, where the team gets feedback on the value it delivered, and a Sprint Retrospective, where it inspects its own growth. Scaling complicates both considerably.

Teams need to keep inspecting their contribution to product goals. The program simultaneously needs a way to understand the holistic contribution of all teams, fast enough to inform refinement at both levels. Teams generally keep their own retrospectives, but the program needs a mechanic for issues no single team can solve.

Surveying the popular frameworks, the answers look broadly similar. The real divide is cadence.

Single-sprint cadence (Nexus, Scrum@Scale, LeSS)

Program-level feedback happens every sprint. Teams plan a collective sprint, execute their portion individually, then hold a combined Sprint Review so everyone gains shared understanding of what capabilities were added across all teams. That discussion often includes technical lessons learned, so other teams can avoid the same pitfalls.

Teams then run their own retrospectives, followed by a program-level retrospective with representatives from each team plus coaching, leadership, and stakeholder support.

• Advantage: teams and program get product and process feedback every single sprint, on a rhythm of a few weeks. That’s the nimbleness business agility depends on.
• Disadvantage: program-level meetings add overhead to every iteration, cutting into working time.

Multi-sprint cadence (SAFe)

Program-level feedback happens at the end of a longer cycle. A group of teams, known as an Agile Release Train, holds a two-day PI Planning event to map milestones, objectives, and dependencies for the next Program Increment, usually about three months. Teams then execute sprints independently. The final iteration, the Innovation and Planning Sprint, is for finishing commitments, running innovation games, and preparing for the next planning event. Product- and program-level retrospectives sit on the front of the planning agenda, before new themes are introduced.

• Advantage: maximizes team working time during individual sprints.
• Disadvantage: as generally realized, teams don’t get a whole-product view of how their work contributes to the whole. And program-level retrospectives happen roughly four times a year, which tends to produce superficial reviews of metrics rather than genuine adaptation.

How do SAFe, LeSS, Nexus, and Scrum@Scale compare?

The pattern worth noticing: frameworks that keep a unified backlog and a single PO buy clarity at the cost of coordination overhead. Frameworks that add hierarchy buy scale and clear authority at the cost of vision and responsiveness. There’s no option that gives you both. Anyone selling you one is selling you something else.

So what should an enterprise actually do?

There are no magic bullets. The single best piece of advice I can give about scaling Agile is: don’t.

Invest in making teams as independent and cross-functional as possible, removing the multi-dependencies that made scaling look necessary in the first place. Map your value streams and restructure so that teams contain entire streams, rather than streams running through many teams. Shift institutional focus away from maximizing output and within-team productivity, toward visualizing outcomes and cycle-time-to-value.

If you fail that (and most organizations will, at least initially), the next best advice is to treat any scaling framework as a starting point, not a goal. You will have to tailor the mechanics until you find a structure that actually functions and produces some semblance of agility.

I call the target minimum viable bureaucracy: the smallest set of rules you actually need to get out of your own way. MVB isn’t something you install. It’s something you discover through experimentation, which means empiricism, not dogma, has to stay your primary mindset.

You don’t have to go it alone, either. A coach with real scaling experience can save significant time, money, and heartache. More importantly, it can help you focus attention on the questions that matter most at each of these three challenges.

Frequently asked questions about scaling Agile

Why is scaling Agile so difficult?
Because it creates three distinct problems at once: parsing product vision across multiple backlogs and Product Owners, managing cross-team dependencies during the sprint, and preserving fast feedback loops at both team and program level. Most scaling failures come from adopting a framework’s answers without first understanding the questions.

Which scaling framework is best?
None of them, universally. Each makes a different set of tradeoffs across those three challenges. The better question is which tradeoffs your organization can actually absorb, and whether you could reduce dependencies enough that you don’t need to scale at all.

How often should you hold Scrum of Scrums?
Frameworks differ, and frequency matters less than function. The test is whether impediments actually get resolved in the meeting. If teams are reporting status rather than solving cross-team problems, adding or removing sessions won’t fix it.

Do you need a Product Owner for every team when scaling?
No. LeSS and Nexus maintain a single Product Owner across a unified backlog. SAFe and Scrum@Scale declare POs at each backlog level. The single-PO model preserves vision clarity but risks overwhelming one person; the multi-PO model clarifies authority but tends to obscure whole-program vision.

What is minimum viable bureaucracy?
The smallest set of rules and coordination structures an organization genuinely needs to deliver. It’s discovered through experimentation rather than adopted from a framework, and the goal is always to need less of it over time.

Looking for enterprise Agile coaches who’ve done this before?

From planning a transition to rescuing a transformation that’s gone off the rails, from individual teams to very large enterprises, our coaches have the skills to help you succeed.