There's something I keep hearing in coaching conversations that I don't believe anybody's saying on a bigger stage yet. Organizations that spent three years implementing some kind of scaling framework are now quietly pulling it all apart. And as I dig deeper on this, because I work with a lot of teams doing this, it's not necessarily because the scaling failed. It's because it worked, and then it just kept going. Now the structure they built to solve a coordination problem has itself become the coordination problem.
I'm Lance Dacy, and at Big Agile I help product organizations deliver high value with the least amount of friction. That's my tagline for agility. Today I want to turn the scaling topic upside down and talk about descaling — specifically, when the right leadership direction is less structure, not more.
This conversation is happening behind closed doors in enterprise leadership teams right now, and I believe almost no one is offering practical guidance on how to do it without creating more chaos. So in this article I'll walk you through the three most common sources of bloat I've found in scaled agile environments, give you a three-question diagnostic you can run in any part of your process this week, and close with one concrete action you can take.
How a Scaling Win Becomes a Scaling Trap
Picture this. Three years ago, an organization I was working with had eight Scrum teams. They were stepping over each other, releases were breaking, and nobody could really see what was happening across the teams. We tried to build out a roadmap planning process and coordination meetings, but it just wasn't working. So leadership made what I thought was a reasonable call back then. Let's bring in some form of scaling framework.
Before they actually diagnosed what they needed, they brought in SAFe, the Scaled Agile Framework, basically bought it off the shelf. They trained everybody, stood up the ceremonies, and hired release train engineers when we still found it hard to even hire Scrum Masters. So let's just go hire a bunch of release train engineers. It was a big conundrum.
They built out these governance layers, and I'm going to be honest with you, for a while it actually helped. Visibility improved. The chaos settled down. People seemed pretty excited because now they had a shared language for what was going on.
Now fast forward to a while ago when I checked in on those same eight teams. They now spend more hours per sprint in coordination meetings than actual product work. A priority change someone wants to make in the roadmap used to take a conversation. Now it takes three review cycles from a product operations committee. The teams aren't chaotic anymore, but they're certainly not fast either. They're well managed.
When delivery slows down, the instinct is to add more structure. Another sync, another review, another role. But in most cases, the slowness is not caused by a lack of structure. It's caused by too much structure.
Scrum is founded on empirical learning and lean thinking, which is about reducing waste and focusing on the essentials. If you're not regularly asking what is essential and what is waste, your process will accumulate weight over time. Every process does. That's not necessarily a failure. It's organizational gravity. And we've talked before about ossified and calcified processes — frameworks that are good in the beginning but then just keep building and building.
So I want to walk you through three ideas that help us understand this problem better and challenge it.
Idea 1: Simplification Beats Process Stacking
The first guidance comes from the LeSS community. LeSS stands for Large Scale Scrum. It was created by Craig Larman and Bas Vodde, and they have been saying something for years that I think most organizations are not ready to hear.
The goal of scaling is not to add more process on top of teams. It's to simplify the organization so that Scrum can actually work at scale. That's why it's called LeSS. Large Scale Scrum, doing more with less. They call it descaling through organizational simplification.
The core insight is this. Complicated organizations with many roles, processes, and artifacts are slow to adapt. Simple organizations have the potential to adapt quickly, which is really what we want.
That sounds obvious. You say it out loud and it's like, yeah, tell me something I don't know. But think about what most scaling implementations actually do. They add roles. They add ceremonies. They add artifacts. They add governance layers. They do basically the opposite of simplifying. They do it with good intentions, but good intentions don't reduce cycle time. And in hyper-competitive product delivery, that's the goal.
So the question for leaders is this. Before you start adding anything to the system, ask whether it's going to simplify, or just manage the complexity you already have. Those are very different things.
Idea 2: Coordination Is an Economic Question
The second idea comes from Don Reinertsen's work on product development flow. If you've not read his book, Principles of Product Development Flow, it's a hard read but a great one. Reinertsen is actually a big advocate for coordination. A lot of people think he's not, but in the book he's clear that he loves cadenced meetings, short and frequent, because they keep transaction costs low and feedback faster.
His point is not that meetings are bad. His point is that coordination is an economic question, not just a process question. Are we gaining anything from this? Every sync, every review, every handoff costs something. When the cadence is predictable and the cost is low, coordination is cheap. That's a good thing. Collaborative working sessions help us move faster.
Here's what happens in most scaled organizations. You start with one useful sync meeting. Then somebody adds a presync to prepare for the sync. Then somebody else adds a readout after the sync to brief leadership. Now you have three meetings doing the job of one. Transaction costs have tripled, but the value has not.
Reinertsen would say the problem is that you stopped doing the math. We just started putting governance in place without asking whether the cost of coordination is lower than the cost of the misalignment it's trying to prevent. That's an economic question you have to ask. When you stop asking it, you default to more meetings, and that overshoots almost every time. It feels like a warm blanket. People are talking and doing things, but it really isn't accomplishing what you think it is.
Idea 3: Bureaucratic Drag and Decision Latency
The third idea comes from a different angle. Gary Hamel is a management professor with a lot of research on bureaucracy. His book Humanocracy is specifically about what he calls bureaucratic drag. Hamel's research team surveyed over 10,000 professionals and found something that should bother every leader watching this.
The average respondent works in an organization with six management layers. In large organizations, frontline employees can sit under eight or more. Every layer adds a checkoff, a sign-off, or some form of decision latency. Hamel's research shows that every new challenge in a bureaucracy tends to spawn a new oversight function, a new compliance role, a new review board, a new required report. The TPS reports.
Each one makes sense on its own. But when it all adds up, decision making slows down until the cost of the structure exceeds the value of the coordination it's trying to provide.
Here's why this matters specifically for scaled agile approaches. A lot of the governance layers you'll find in SAFe or any scaling framework were added for visibility. Leadership wanted to see what was happening, and that's legitimate. You'd want that too. So that's not the problem.
But visibility layers can become latency layers. If no one is making decisions based on the information they're producing, then it's a wasteful activity, and waste is the foundation of what lean is trying to eliminate. If a report exists and nobody changes their behavior because of it, that report is not transparency. It's overhead. We talked about this in the measures-that-matter video a few episodes back.
The EARN Test: A Three-Question Diagnostic
So what do we do about this? I want to give you a diagnostic you can use in any part of your process. Any ceremony, any role, any artifact. I'm calling it the EARN test, for lack of a better name, and it has three questions.
Question 1: Does this remove an impediment, or does it just manage the complexity we created?
That's a big separator. Think about a daily standup that helps a team spot a blocker and resolve it within hours. That removes an impediment. It makes the system faster.
Now think about a scrum of scrums, another common scaling technique. It exists only because teams are organized by component instead of by product or value stream. That manages the complexity of the org chart we created. It does not make the system faster. It just keeps things from getting worse. And keeping things from getting worse is not a strong argument for a recurring two-hour meeting.
Question 2: If we removed this tomorrow, what would actually break?
Not what might break. Not what could theoretically go wrong. What would stop working this sprint?
I ran this exercise with a leadership team just last week. The answers are always revealing. For some things, the answer is immediate. "If we didn't have this coordination activity, we would ship conflicting database migrations." Great. Let's keep that. We don't want to do that. For other things, the answer is vague. "People will lose visibility into what other teams are doing."
That's not breakage. That's discomfort. And discomfort is not a reason to keep something that costs 40 hours of engineering time a month.
Question 3: Could we get 80% of this value with something lighter?
This is the redesign question. Maybe you do need cross-team coordination, but you don't need a two-day program increment planning event to get it. Maybe a 90-minute session with six delegates does the job. If you have 40 people on a release, let every team send one or two delegates instead. Maybe you do need visibility into delivery progress, but an automated dashboard replaces the weekly status report that three people spend half a day compiling. I've been there.
The goal is not to eliminate everything. It's to right-size it. The right amount of structure is the minimum necessary for teams to learn and deliver at the speed the business needs, not the maximum amount that leadership can tolerate.
Three Places the Bloat Hides
I want to give you three places to point the diagnostic first, because this is where the bloat hides in almost every organization I coach.
1. Ceremonies that exist because of the org chart
You know the ones. They're not because of how the work flows. They're org chart meetings. If you reorganized teams around value streams rather than components, half of your cross-team syncs would disappear overnight, because we'd be organized correctly. Those meetings are compensating for a structural choice we made. Most engineers are more comfortable with a component-based approach because they like working that way, but those structures aren't actually supporting the work.
2. Governance that started as transparency but became latency
Steering committees, portfolio reviews, what I call stage-gate approvals. Ask yourself, when was the last time one of those reviews actually changed a decision? If you can't remember, you're paying for a review that reviews nothing. A lot of times those are people reviewing changes they have no idea about.
3. Roles that drifted from enabling teams to managing process
I see this all the time with SAFe. If your release train engineer spends 80% of their week compiling status reports and 20% removing impediments, you don't have a release train engineer. You have a project coordinator with a SAFe title to make everybody happy.
Pro-Flow, Not Anti-Structure
Descaling is not an ideology. I'm not anti-SAFe. I'm not anti-structure or anti-process. I'm pro-flow. Flow means work moves through the system with the least amount of friction necessary.
If your framework is reducing friction, keep it. If it's adding friction, fix it. If you cannot tell the difference, that's the first problem to solve.
Agile is the ability to organize and optimize ourselves to deliver the highest business value work items as early as possible with the least amount of cost and friction. Business agility is the ability to deliver at the rate the business needs work delivered. That rate varies from organization to organization.
Your Action This Week
Next week, pick one recurring cross-team ceremony. Just one. Pull up the last three instances of it, and for each one answer three questions.
First, did this meeting produce a decision? Not information. A decision. Something someone did differently because of it.
Second, could the same result have been reached asynchronously, in a shared document or a Slack thread? We all love to do that anyway. Why not do it for the right reasons?
Third, what is the actual cost of this meeting in engineering hours per month? Number of people, times the duration, times the frequency. Write it down. That's hidden waste we don't think about.
I used to calculate meeting costs by averaging salaries and saying, "Hey, this meeting costs $8,200. If you owned this business, would you pay $8,200 for that meeting?" I'm not trying to slam anybody. I just want us to be cognizant. Professionals have to evaluate better ways to deliver products. It's a hyper-competitive world, and what separates us from the competition is not being lazy and not just saying, "Oh, I just come to work every day." It's really trying to make the system better. That's all of our responsibility.
If the meeting produced real decisions that could not have happened any other way, great. It earned its place. If it did not, you now have evidence to discuss redesigning it or cutting it altogether.
The organizations that will move fastest over the next two years are not the ones with the most sophisticated scaling framework. They are the ones with the courage to look at their structure, the psychological safety to talk about it, and the willingness to say this no longer earns its cost. Even if you've done a framework and paid a lot of money for it, maybe it's time to dismantle some of it.
Descaling is not retreat. It's a discipline. The discipline to keep only what helps teams learn and deliver, and let everything else go.
For more on the systemic dynamics behind this — including why so many enterprise scaling rollouts plateau the way they do — Age-of-Product's "Scaling Agile: The Uncomfortable Truth" is a sharp companion read.
Ready to Right-Size Your Scaling Framework?
If your teams or your organization are wrestling with descaling, improving flow, or figuring out the right amount of structure, we'd love to help. That's what we do at Big Agile. Training, coaching, and support for product teams and leaders — including AI integration and implementation. Our passion is real outcomes with less friction.
Explore our upcoming classes, courses, and coaching engagements.