The Big Dumb Question:
Scrum is one of the most popular frameworks in the world—and nearly every client I work with says they’re doing it (or wants to). But in most cases, what they’re doing looks almost nothing like what the Scrum Guide describes. Which begs the question:
Who’s really “doing Scrum?” And if Scrum so hard to implement as designed—does it work as well as we think?
Scrum in the Wild—A Savage Savannah
Tons of organizations say they’re “doing Scrum.” But in most cases, the way they practice it diverges from how the Scrum Guide defines the framework’s core elements.
- Dedicated, stable teams? Rare.
- Empowered Product Owner? Often missing.
- Acceptance criteria over detailed requirements? Almost never.
The result is a Scrum evangelist’s nightmare:
- Fluctuating teams that make estimating impossible
- POs who can’t make backlog decisions without convening a steering committee
- Projects that take months to get started because full requirements need to be gathered
Most Scrum experts will say that these organizations aren’t actually doing Scrum. What they’re doing is a heavily edited version—shaped by real constraints (like bandwidth and legacy systems) and imagined ones (like the belief that executives won’t support change).
I call this “Wild Scrum”—a chaotic approach that cobbles together Scrum elements that are easy to implement, leaves the Waterfall foundations in place, and labels itself “Hybrid.”
And it drives Scrum evangelists bonkers.
The Inadequate Response of Experts
I think Scrum evangelists are largely right when they say those edits usually do more harm than good.
That’s because when organizations make changes to the framework, leaders rarely stop to ask how their version of Scrum behaves as a system—starting with alignment on why they’re “going Agile” in the first place:
- What outcomes will we see with Agile that we didn’t with Waterfall?
- What benefits are most important to achieve?
- If we change X, what will break? Do we care?
- What constraint are we accommodating? And is the constraint worth protecting?
- How much effort are we willing to put into the transformation itself?
But if you scroll the comments section of a Scrum group for advice, you’ll hear a pretty consistent (and inadequate) response:
Don’t overcomplicate this. Just do what the damn Guide says.
Look, I get it. Why do all this work to change a framework that (at least on paper) is simple, elegant, and dripping with common sense?
But the bigger the organization, the more it becomes a Herculean effort just to get executives to understand what Scrum is (even if they asked for it)—let alone marshal the resources to implement it.
Which is why for most of my career, I’ve been quietly asking the question:
If a framework is so difficult to implement that almost no one above a certain size actually does—how useful is it really?
Scrum Assumes a System You Probably Don’t Have
As a consultant, I have a rule: Advice that my client will NEVER implement isn’t good advice—even if it’s “correct” from a best practice perspective.
Instead, if best practice is a non-starter, I have an obligation to look at their constraints, push back where it matters, and collaborate with them to develop, iterate, test, and implement a solution that works for their goals.
And that’s the heart of my tension with Scrum.
On paper, it’s brilliant.
But in practice, it assumes a system most organizations just don’t have.
The Scrum Guide describes itself as a “purposefully incomplete framework,” meaning you can bring in your own techniques and methods. But it also strongly cautions:
Changing the core design or ideas of Scrum… limits the benefits and potentially renders it useless. – Scrum Guide
So before you start customizing, it’s worth asking: what does Scrum’s core design actually assume about the organization implementing it?
In practice, it assumes organizations can accommodate:
- Stable, self-sufficient, cross-functional teams
- A single person (Product Owner) with authority to prioritize and approve work
- Business stakeholders who can show up regularly for demos—and interim feedback
- Testing and integration practices that support “done” increments every Sprint
- Agile planning cycles—where roadmaps are adaptable, not locked in quarters ahead
To be clear, these practices work—but most organizations can’t change on a dime to accommodate them. They certainly can’t “try it as is” to determine if the philosophy, theory, and structure help to achieve goals—at least not right away.
What It Usually Takes to Scale Scrum in a Large Organization
For mid- to large- organizations or PMOs to implement enterprise Scrum, some monumental things need to occur:
- Changes usually need to be made structurally and culturally…even if they are done iteratively.
- In the new structure some people will no longer be needed—others will need to be added.
- Almost anyone that touches technology products will need to be educated on what is needed from them to make it work—from the C-suite on down.
- And perhaps most critically, you’ll need to figure out what products, projects, or systems each team (or multiple teams) will support—ideally in a way that provides full coverage without introducing siloes or doubling your development staff.
And if you’re trying to do SAFe…well, that’s a post for another day.
The pressure to implement Scrum “right” is what leads many Agile Transformation folks to take (ironically) years to implement anything impactful.
In fact, a few years ago, when I asked an Agile Transformation lead why they felt their implementation was taking so long, here’s what they said:
“I know I’ll never get real Scrum across the finish line. But if I do something “wrong” and it gets out to other Agile people, I won’t be able to find a job—I won’t be taken seriously.”
And honestly, she’s not totally wrong. (But again, a post for another day).
But as I often say to the consultants I work with: Do we want to be right? Or do we want to be effective?
Large-scale Agile Transformations have real costs—and they’re rarely fully examined:
Direct Costs (That Add Up Fast)
Headcount and Hiring Costs
Dedicated, cross-functional teams often mean hiring new roles—and reducing or reassigning people who no longer fit the structure. Both have real price tags, financially and culturally.
Training and Enablement at Scale
Executives, business stakeholders, technologists—everyone needs to understand what’s changing and why. That means upfront investment in training, communication, and coaching. And don’t forget the training and coaching that needs to happen before you even decide to transition—informed executives are critical.
Productivity Drop During Transition
Even with phased implementation, delivery slows. Teams relearn roles. Conflicts surface. People wait for clarity before moving forward.
Restructuring and Change Management Overhead
Real Scrum often requires shaking up org charts, workflows, and reporting lines. That’s time-consuming, politically sensitive work—and it rarely stays contained.
Opportunity Costs (You’re Probably Underestimating)
Delayed Strategic Work
Every month spent retooling delivery systems is a month not spent shipping critical initiatives. That delay has real downstream impact.
Innovation Bottlenecks
Teams navigating transformation fatigue often deprioritize risk-taking or customer experiments—just when you need them most.
Erosion of Cultural Capital
Drag out change too long, and teams disengage. Early champions lose steam. Leaders lose credibility. Skepticism becomes your biggest blocker.
It’s not impossible to do. There are good reasons to do it. But is implementing a textbook Scrum approach always worth the cost of change?
Maybe it’s time to stop doing Scrum—and start doing Agile.
That doesn’t mean abandoning Scrum altogether—it means using Agile principles as the design spine, whether or not the framework fits your context perfectly.
We can start by realizing Agile and Scrum aren’t the same thing.
Agile is any approach that supports the ability to create and respond to change. Generally, for something to be considered Agile, it needs to be consistent with the four core values (in the Manifesto) and twelve supporting principles that guide agile practices.
Scrum is one framework that fits the bill…but there are others. Including new ones that we build ourselves.
What Agile Without Scrum Looks Like
Recently, I worked with a client who genuinely wanted to work in a more Agile way—but faced real constraints. They couldn’t form stable, cross-functional teams for every product. (There were too many). Executives were uncomfortable—for a variety of good reasons—with investing full decision-making authority with POs. And some of their delivery work was dependent on business collaborators who simply couldn’t reliably make time in each Sprint to provide feedback, attend the demo, and weigh in on prioritization.
So we did something simple.
We printed the 12 Agile principles and carried them into every design meeting. And every time we added a practice or made a tradeoff, we’d ask:
- What did we break?
- Do we care?
- Is this consistent with what we say we value?
- Will it get us closer to the outcomes we actually want?
- Will it scale? At what cost?
Twelve weeks after implementing the new approach with a pilot team, they’d delivered two high-priority enhancements and a slew of small fixes that had been stalled for over a year.
Not because they “followed Scrum.”
But because they stayed true to Agile.
What to Try Today
If you’re leading—or living through—a Scrum implementation, try this:
- Get clarity on why you’re making the change. Even if you’re smack dab in the middle of a transformation, document why you’re doing it. What outcomes are you trying to achieve? Rank them in priority order.
- Swap the framework for the principles. Pull out the Agile Manifesto. Ask: “Do our current practices support this? What about our new ones? Do some elements undermine others?”
- Name the constraint you’re protecting. If you’ve changed Scrum, be honest about why. Is it a real constraint—or just an inherited assumption?
- Design as a system, not a checklist. Every adaptation affects something else. Domesticate “Wild Scrum” by making sure everything works together as a cohesive whole.
If this piece made you nod—or wince—you’re not alone.
Scrum transformations are rarely clean, and most PMO leaders are doing their best with real constraints.