Every Agile coach has a story like this one. I started working with a product organization about two months ago, and the first thing they told me — almost proudly — was that they had gone through a full-scale Agile transformation about a year prior.
Then came the rest of it.
They had removed their business analysts. They had eliminated their dedicated testers. They had collapsed the QA function entirely. The reason? "Scrum calls everyone a developer."
And technically, that's true. The Scrum Guide does use the word "developer" to describe anyone on the Scrum team who's committed to creating the product increment. But it was never an instruction to fire your testers. It was never a mandate to eliminate specialized skills. "Developer" in Scrum is basically a hat you wear on the team. It describes your relationship to the work, not your career title or your skill set.
This organization had read "Agile" as "remove structure, remove roles, remove governance, remove oversight." And for about 18 months, it kind of looked like it was working.
Then the cracks showed up. And that's when they called me.
When the Cracks Show Up
A breaking change hit production because nobody reviewed it. A compliance audit flagged three teams that had drifted off the security baseline. Two senior engineers burned out because every decision — even small ones — got escalated, since nobody knew who was allowed to make the call.
These people had removed structure without replacing it. And the vacuum filled itself with politics, heroics, and invisible bottlenecks that were harder to fix than the process they took away.
This is what most organizations got wrong about Agile, and I'll admit I got it wrong along the way too. Agile was never "no process." It was always minimal viable process. Minimum viable bureaucracy. Enough structure to enable the work, but not so much that it becomes the work.
Scale Changes the Game
Everything I just said works pretty cleanly when you have a few teams on a single product stream. Three teams, four teams, maybe even five or six. You can keep them organized around customer outcomes, share context easily, and the structure stays light.
Now imagine 100 teams. That's a different story entirely.
What happens at scale is predictable. Engineers are smart and risk-aware. They look at hundreds of people pushing code into shared systems, and they naturally start to organize around the technology stack. The Java team. The database team. The platform team. The front-end team. The back-end team. The API team. Because that's how you contain risk when people are making all those code changes.
It feels logical from inside engineering. But what it produces is a sub-optimized situation. Each team optimizes for its own efficiency and its own risk profile. And the customer? The customer ends up watching an elaborate relay race. A request gets handed off through five teams before anything substantial reaches them. By the time they see something usable, the original need has changed and the technology has changed.
That's the component team trap, and it shows up in almost every organization that scales past a certain size.
I want to be honest about scale: when you grow, you do get more process and overhead. I don't think there's any version of a 100-team organization that runs as lean as a three-team organization. But "more" should still mean "minimum." We add what we need, and not one ceremony, not one role, not one approval gate more.
The principle that keeps you honest: scale and optimize for customer outcomes. Anything that takes you away from that — even in the name of engineering efficiency — needs further evaluation. Who are we here for? The engineers or the customers?
Communities of Practice: The Underused Structure
There's a way to scale without falling into the component team trap, and it's one of the most underused structures I see in enterprise agility. I call them communities of practice. They go by a lot of names.
The idea is simple. Engineers with similar skills need to collaborate. I don't have to be on your Scrum team to share a code pattern with you. All of your Java developers can form a community of practice and establish patterns, principles, and shared standards. Your testers — if you haven't gotten rid of them — do the same thing. You can have a virtual architecture team that provides oversight to particular technology stacks while every member is still embedded in a product team doing customer-facing work.
Even Agile coaches do this. We have communities of practice where we share what's working, what's not, and the gnarly problems that get us stuck. We need a safe place to talk about those too.
I want to be frank: this is not an easier way to work for engineers. It takes more deliberate collaboration, more conversations outside your immediate team, more effort to maintain consistency across products. That feels inefficient at the local level. But it's optimized for the customer that's paying for the work. And that is the question worth asking constantly. Who are we here for?
What the Research Is Telling Us
This isn't just my observation. Verbat Technologies published a piece earlier this year called "Agile After 2025: Why Enterprises Are Quietly Adding Structure Back." The core observation was that enterprises are not abandoning Agile, the way everybody seems to be screaming. They are restructuring. They're reintroducing governance layers, compliance checkpoints, architectural oversight. Not because they want waterfall back, but because unmanaged agility at enterprise scale introduces real risk.
I have the scar tissue to prove it.
The Scrum Guide itself says it is purposefully incomplete. It defines the minimum. It does not say "stop here and add nothing else." I was teaching a class with another coach a while back, and he described the Scrum Guide as a skeleton — you have to put the meaty parts on the skeleton yourself. I think that's a good way to look at it.
Throughput and stability are correlated, not opposed. The highest-performing teams in the DORA research deploy multiple times a day, recover from failures in under an hour, and maintain change failure rates below 5%. It can be done. But the same research also found that teams with well-defined responsibilities and clear decision-making authority perform better across almost every metric.
There's engineering to it, but there's also structure.
And here's something worth sitting with: increased AI adoption without fundamentals like small batch size and robust testing actually decreased delivery stability by over 7% in the latest data. More speed without structure makes things worse. We know this intuitively. We just don't articulate it well.
You need both proactive and reactive controls to maintain flow. Correct sizing of the highway reduces congestion — that's proactive structure. But cars still break down, so you need to clear problems quickly — that's reactive structure. One without the other doesn't work.
What Sustainable Velocity Actually Looks Like
Sustainable velocity is not maximum speed. It's the highest speed your organization can maintain without accumulating technical debt, relationship debt, or delivery risk that slows you down later.
Mike Cohn tells a story in Succeeding with Agile about a game studio called High Moon Studios. They tracked what happened when they required overtime before a trade show. Velocity went up the first week. It dropped the second week. By the third week, it was barely above normal. By week four, velocity was actually below what the team produced at a sustainable pace.
You can sprint. You cannot sustain a sprint.
The organizations that tried to sustain maximum speed with zero structure are the ones now scrambling to add guardrails. And I'm here to help. The question isn't whether you need structure. The question is whether you're adding structure that protects flow, or structure that impedes flow. There's a big difference.
Five Minimum Viable Structures That Protect Flow
Here are five structures I've seen enable sustainable velocity for most technology teams. Each one protects flow without adding bureaucracy.
1. Clear Decision Rights at the Team Level
Most teams are not slow because they lack talent. They are slow because nobody knows which decisions they own. Decentralized decisions require both the authority to decide and the information to decide correctly.
On the Boeing 777 program, they calculated a cost-versus-weight trade-off rule and pushed it down to individual engineers. Thousands of small decisions got made quickly and correctly because engineers had a decision rule, not a decision committee. They had guardrails.
2. Automated Quality Gates
If the only thing between your code and production is a human reviewer's calendar, your lead time is at the mercy of someone's Tuesday afternoon. And that's not going to win.
Automated gates for security scans, test coverage thresholds, and deployment checks run at the speed of the pipeline, not the speed of the meeting. Elite teams deploy multiple times a day, and they're not doing it with manual approval chains. I can promise you that.
3. Lightweight Architectural Review for High-Risk Changes
Notice I said lightweight and for high-risk changes. This is not a review board that meets monthly and creates six bottlenecks. This is a short, focused conversation. When a change touches shared infrastructure or could affect another team's service, we need to start getting involved. The key word is when — not always.
Reserve the ceremony for the risk. This is where your architecture community of practice earns its keep.
4. Flow Health Review Cadence
Fifteen minutes a week. Four numbers: lead time, work in progress, change failure rate, time to restore. Those are the vital signs of your delivery system.
You're managing queues, not timelines. If lead time is creeping up, that's an early signal. Fix it now while it's small. When it becomes a six-week backlog, it's a lot harder to fix.
This is the cheapest structure on the list and probably has the highest leverage.
5. Psychological Safety Baseline
I know it sounds soft. It isn't. Studies have consistently found that psychological safety is among the strongest predictors of software delivery performance.
Teams that feel safe surface problems early and admit when things aren't working. They will always outperform teams that hide problems until they explode. Problems are cheaper to fix the earlier we find them.
Measure it. A simple quarterly pulse survey with three or four questions is enough. If your score is low, you don't have a velocity problem. You have a trust problem first. And nothing else matters until we fix that.
Five structures. Decision rights. Automated gates. Lightweight architecture review. Flow health cadence. Psychological safety baseline. None of these require a committee. None require a framework purchase. All of them protect flow.
One Action You Can Take Next Week
Sit down with your team and identify one decision that currently gets escalated that they should be able to resolve on their own. Just one. One decision that's going to slow things down every sprint because nobody is sure if they're allowed to make the call.
Now write a one-sentence decision rule. Here's an example:
If a change does not affect another team's API contract, the team can review and merge the code without external review.
Another one:
If the cost is under $10,000 and the experiment runs less than two weeks, the product owner can greenlight it.
And by the way — where did all of our product owners' authority go? They need to have the authority to do those things.
Make the rules visible. Put them on your team agreement. Let the team use them for two sprints. Watch how much faster things move when people don't have to ask permission for decisions they're already qualified to make.
One structure. One guardrail. Hours of wait time back every sprint. It can be a game-changer.
The Real Definition
Sustainable velocity is not maximum speed. It is the speed you can hold without things breaking underneath you.
Agile was never "no structure." It was always minimal viable process, minimum viable bureaucracy — optimized for the customer who's paying for the work.
The organizations getting this right are not choosing between agility and structure. They are deliberately designing both, hand in hand. And guess who's at the center of that design? Their customer.
If you're navigating an enterprise transformation and trying to figure out where to add structure without killing the speed your teams fought hard to build, this is exactly the work I do every day with leadership teams. Explore our upcoming classes and coaching engagements to see how we can help you design the right guardrails for your context.