I accepted this ten years ago.
I watched companies slap “Agile” on their waterfall processes and call it transformation. I saw project managers rebrand themselves as Scrum Masters over a weekend certification course. People rush for SAFe training that violates every agile principle.
I made peace with it. Told myself it didn’t matter. That’s just how big corporations work. I ran my own world with the values and principles, but I gave up trying to force it on organizations that don’t actually want to be transformed.
But I keep seeing posts on LinkedIn. Smart people calling out the same patterns. The same frustrations. The same fundamental misunderstanding of what Agile actually is.
So maybe it’s time to say what everyone’s thinking, but nobody wants to admit: Many organizations adopted Agile to make stagnation look modern. Agile was never meant to change how they work.
The Money Pit We Built
SAFe wasn’t created to make organizations agile. It was created to let big corporations avoid actually changing while claiming they had.
It’s Agile for companies that fundamentally don’t believe in Agile principles. It’s a way to check the box, get the certifications, use the vocabulary, and keep doing exactly what you were doing before.
And it’s bleeding companies dry.
It’s being used as a shield. A way to say “we’re agile” while maintaining every waterfall practice that made you slow in the first place.
You can’t plan everything six months in advance and call it agile. You can’t turn backlogs into dumping grounds for technical tasks and call it product thinking. You can’t micromanage every hour and call it empowerment.
But we do it anyway. Because the certification was easy to get. Because the consultants told us we could. Because it lets us keep the illusion of control.
The Weekend Experts
Here’s what happened: Scrum certifications became a weekend activity.
You could go from project manager to Scrum Master in 16 hours. No experience required. No understanding of the principles. Just memorize some terms, pass a 10-question test, and update your LinkedIn profile.
Suddenly, everyone’s an expert. Everyone’s certified. And nobody actually knows what the hell they’re doing.
A Scrum Master isn’t a project manager with a new title. A Product Owner isn’t just the person who writes requirements. These roles have specific purposes. Specific responsibilities. They exist for reasons that matter.
But we stripped all that away. Kept the vocabulary. Ditched the meaning.
Now we have Scrum Masters running Kanban because “Kanban doesn’t have all those ceremonies I don’t like.” Yes, you should read that again. “Scrum” Masters running “Kanban”. What they call Kanban anyway. We have Product Owners who’ve never talked to a customer. We have teams doing “sprints” that are just two-week waterfall cycles with a standup.
It’s not Agile. It’s theater.
What We Did to the Frameworks
Scrum works. Kanban works. They work for specific types of work under specific conditions.
Kanban is for like-sized, continuous flow work with specific constraints and metrics. It’s not “Scrum without planning.” It’s a completely different approach designed for a completely different context.
Somewhere along the way, picking a framework turned into ordering off a menu. I’ve heard teams say, “Let’s do Kanban,” not because it fits their work, but because it sounds easier or lets them skip retros. We end up choosing what’s convenient, not what’s right. And then we wonder why nothing changes. The real needs of the team get lost, and the framework becomes just another checkbox.
We end up with Scrum Masters leading teams in Kanban, not only doing relative estimates but also estimating in hours and then measuring velocity, yet none of them can explain throughput or cycle times.
That’s not how this works.
The work should determine the framework. Not your preference. Not what’s trendy. Not what requires fewer meetings.
If you’re doing software development with variable-sized work and uncertain requirements, Scrum might be right. If you’re doing continuous deployment with steady flow and tight constraints, maybe Kanban is a good fit. If neither fits, maybe you need something else entirely.
But you don’t get to bastardize a framework because you don’t like parts of it and still claim you’re using it.
The Backlog Became a Junk Drawer
Backlogs used to mean something.
They were a prioritized list of value. Customer needs. Business outcomes. Things that mattered.
Now they’re task lists. Technical stories. Architectural work. Bug fixes. Everything is dumped in one place with no clear prioritization and no connection to actual value.
We estimate tasks. We plan everything. We turn backlogs into detailed project plans and wonder why we’re not getting the flexibility Agile promised.
Because we’re not being Agile. We’re doing waterfall with different words.
A backlog isn’t a comprehensive list of every piece of work that needs to happen. It’s a prioritized queue of value delivery. If you can’t explain why something’s in the backlog in terms of customer or business value, it doesn’t belong there.
But we threw that out. Because planning everything feels safer. Because we like control. Because we never actually believed in the principles.
The Principles We Ignored
Agile isn’t a process. It’s a set of values and principles.
The core principles are simple: people over process, working software over paperwork, customers over contracts, and change over rigid plans. When I look at what’s actually happening, it’s obvious most companies missed the point. They skipped the hard part, the real change, and settled for surface-level tweaks.
Most companies read that and immediately started figuring out how to keep their processes, documentation, contracts, and plans while still calling themselves Agile.
We wanted the buzzword. We didn’t want the change.
So people got certifications. They renamed our roles. They adopted the ceremonies. And we kept doing everything exactly the same way.
Daily standups became status meetings. Sprints became mini-waterfalls. Retrospectives became complaint sessions with no action. Planning became an exercise in committing to work six months out.
None of that is Agile. It’s just new labels on old dysfunction.
Why This Actually Matters
This isn’t just semantics. This isn’t just me being pedantic about frameworks.
Companies are hemorrhaging money on this. They’re paying for SAFe training. They’re hiring Agile coaches who are giving the same bad advice for the check. They’re reorganizing around squads, tribes, and chapters. They’re spending millions to transform.
And they’re getting worse. Not better.
Because they’re implementing theater, not principles. They’re adopting vocabulary, not values. They’re checking boxes, not changing culture.
And the people doing the actual work are burning out. Because now they have all the Agile ceremonies on top of all the waterfall requirements. Now they’re in more meetings, doing more planning, tracking more metrics, and delivering less value.
That’s not Agile’s fault. That’s ours.
The Hard Truth
If you want to be Agile, be Agile. Embrace the principles. Accept the discomfort. Let go of the illusion of control.
If you want to do Scrum, do Scrum. All of it. Not just the parts you like. Understand why the roles exist. Understand why the ceremonies matter. Do it right or don’t do it at all.
If you want to use Kanban, use Kanban. For the right work. With the right constraints. With the discipline to maintain flow and measure cycle time.
But stop pretending. Stop calling yourself Agile while running waterfall. Stop claiming you’re doing Scrum when you’ve gutted everything that makes it work. Stop adopting frameworks you don’t understand and blaming them when they fail.
The frameworks aren’t the problem. Your unwillingness to actually change is the problem.
What I’m Asking
I’m genuinely curious: what are you seeing at your workplace?
Are you watching Agile get implemented in name only? Are you in an organization that spent a fortune on SAFe and got nothing in return? Have you seen teams that actually do it right, and what made the difference?
Or maybe you think I’m wrong. Maybe you’ve seen these frameworks work even when adapted. Maybe the purist approach isn’t necessary.
Tell me. I want to hear what’s actually happening out there. Because if enough of us are seeing the same pattern, maybe it’s time to stop pretending it’s working.
Share what you’re seeing. Tell me your stories, good, bad, or ugly. Maybe you’ve cracked the code, or maybe you’re stuck in the same mess. Either way, let’s talk about what’s really going on. Maybe, together, we can figure out what actually works.
Related Reading:
- The Truth About Agile Nobody Admits
- How Great Leaders Build Teams That Think
- The State of Agile Software in 2018 (Martin Fowler)
Want more unfiltered insights on leadership? Check out my book, Beyond Management: A Field Manual for Real Leadership.