I know. The title is going to upset people. Good. It means you’re paying attention.
Before you close this tab, I want to be clear about something. I’m not anti-Agile. I’ve worked in genuinely Agile environments and they are fast, energising and good for the people doing the work. I’ve been part of teams that ship regularly, respond well to change and build things people actually want to use.
But I’ve also worked in places that called themselves Agile while operating in a way that was, in practice, a Waterfall project wearing a Scrum hoodie. Sprints on the calendar. Standups on the schedule. A Scrum Master in the org chart. And underneath all of it, the same top-down planning, the same fixed scope, the same “we need this date” pressure that defined software delivery twenty years ago.
That second version is the most dangerous thing in software delivery right now. Not because it fails. It always fails eventually. But because it fails while consuming enormous amounts of energy and goodwill and because it makes people think Agile is the problem when the actual problem is the gap between what the team says it’s doing and what it’s actually doing.
A properly executed Waterfall project is significantly less damaging than broken Agile that nobody is willing to name honestly.
The Part Nobody Defends
Waterfall has become the thing everyone in software agrees was bad. A cautionary tale told to explain why we needed something better. Rigid, slow, change-resistant and responsible for some spectacularly expensive project failures in the 1990s and early 2000s.
That reputation is not entirely unfair. When requirements are wrong, when the world changes during a long development cycle, when assumptions made in the planning phase turn out to be incorrect, Waterfall gives you very few good options. You either deliver something outdated or you stop and restart, which usually means blowing the budget and the timeline simultaneously.
But let’s talk about what Waterfall actually provides before we dismiss it entirely.
A properly run Waterfall project starts with clear requirements. Everyone agrees on what is being built before anyone starts building it. The scope is defined and documented. Stakeholders sign off on what they’re getting before the first line of code is written. Design is reviewed before development starts. Development is complete before testing begins. Each phase has a formal checkpoint and you don’t advance until that checkpoint is passed.
There is real discipline in that. There is genuine accountability. And for certain types of work, that discipline is exactly right.
Fixed-scope contracts with external clients, where scope changes cost money and both parties need to know exactly what they’re agreeing to. Regulated industries like finance, healthcare and government systems where documentation requirements are non-negotiable. Long-running infrastructure projects with well-understood requirements that are genuinely unlikely to change. Projects where the cost of an error in production is catastrophic and the most important thing is verification at each stage before moving forward.
In those contexts, Waterfall is not a compromise. It’s the correct choice. The problem was never the methodology. It was applying it to every project regardless of fit.
The Fake Agile Checklist
The reason this conversation matters in 2026 is that fake Agile is everywhere. And most teams running it know, somewhere underneath the daily standups and velocity charts, that something isn’t working.
Here’s a quick checklist. If more than a few of these are true for your team, you are not running Agile. You are running something else and calling it Agile.
Sprint goals are decided by management before the sprint starts and handed to the team as instructions, not negotiated commitments. The development team has no real say in what gets built or when. Estimates from engineers are treated as delivery promises. Incomplete tickets roll over sprint after sprint with no real conversation about why. “Done” means done in development, not done in production. Retrospectives happen but nothing they produce actually changes the way the team works. The Scrum Master’s primary job is chasing status updates and reporting to management. The product backlog has hundreds of items, many of which nobody would miss if they disappeared.
If that list describes your team, you are not failing at Agile. You are successfully running a slow, expensive Waterfall that has been decorated with Agile vocabulary. And that is strictly worse than admitting what you have and working with it honestly.
Why Honest Waterfall Beats Fake Agile Every Time
When a team runs Waterfall honestly, everyone knows what they’re in. The scope is fixed. The process is sequential. Changes are expensive and the decision-makers accept that.
That clarity has real value.
Engineers know what they’re building for the next three months. They’re not dealing with the whiplash of mid-sprint pivots. The requirements document, frustrating as it may be, at least exists. When arguments start about scope, there’s a document to refer to. When something is out of scope, that phrase means something specific and defensible.
Stakeholders know when they’ll get what they asked for. They’ve agreed to a plan. Their expectations are anchored to something real.
Managers know what the team is working on without needing a daily standup to feel in control. The plan is the plan.
None of this is ideal. None of it is fast. But it is honest. And honest, functioning processes produce better outcomes than dishonest processes that generate noise and confusion while pretending to be something they’re not.
The team I’d most want to work in is a genuinely Agile one. The team I’d prefer over fake Agile is a disciplined, well-run Waterfall. At least with the latter, everyone has the same map even if the map is slow.
What Your Organisation Actually Needs to Run Real Agile
Agile is not a process you install. It’s a set of conditions that have to exist before the process can work.
Real Agile requires that the team making the software has genuine input into what gets built. Not just tokenistic inclusion in planning meetings but actual influence over scope, priority and approach. If the team can’t push back on unrealistic commitments, Agile is a performance.
It requires a product owner who has real authority. Not just a title. Not a proxy for a committee. Someone who can say yes and no, who understands the users and who can make trade-off decisions without going through three layers of approval first.
It requires stakeholders who understand and accept that changing direction has a cost. Not just in principle but in practice. Every time scope is added mid-sprint, other things get dropped or pushed. That consequence has to be real and accepted, not absorbed silently by the engineering team working longer hours.
It requires a culture where raising problems is safe. Where saying “this is going to take longer than we estimated” is met with curiosity rather than pressure. Where a developer who flags a blocker in the standup gets help rather than a motivational speech about commitments.
It requires technical practices that keep the codebase in a state where the team can actually move quickly. Tests that catch regressions. Code that can be changed without fear. A deployment process that doesn’t require a three-day ceremony every time something needs to go live.
These are not exotic requirements. But they are real ones. And in many organisations, most of them are missing.
The Honest Conversation That Never Happens
Here’s what I wish someone would say in more leadership meetings.
“We would like to run Agile but we’re not set up to run it properly. Our planning is too top-down, our stakeholders aren’t ready to accept flexible scope and our codebase is in a state where moving quickly is genuinely difficult. So instead of pretending we’re Agile when we’re not, let’s define what we’re actually doing and do it well.”
That statement would be honest. It would set correct expectations. It would give the team something real to work with instead of a gap between the stated process and the lived experience.
Almost nobody says it. Because saying it feels like admitting defeat. It feels like giving up on the better, faster, more modern way of working.
But pretending you’re Agile when you’re not isn’t a path to becoming Agile. It’s a way of using the vocabulary of improvement while avoiding the actual work of changing.
What to Do If This Is Your Team
If you’ve read this far and recognised your team, the path forward is simpler than it sounds.
Stop performing the parts of Agile that don’t fit your reality. If you can’t genuinely commit to sprint goals because management will override them, stop pretending sprints are real. Do project-based planning with honest timelines and clear milestones.
Keep the parts that work regardless of methodology. Regular code reviews. Clear definitions of what done actually means. Short feedback cycles wherever you can create them. Honest conversations between engineers and product about what’s realistic.
Be clear with your team about what process you’re actually running. People can work effectively in almost any structure if they understand it clearly. What they can’t do effectively is navigate a structure that contradicts itself.
And if you want to move toward genuine Agile, do it intentionally. Start with the conditions. Fix the culture, the authority structure and the technical practices. Then introduce the ceremonies, not the other way around.
The Destination Is Still Worth Reaching
None of this is an argument against Agile as a destination. A team that is genuinely operating on Agile principles, where feedback loops are short, where the team has real ownership and where the process adapts to what the work actually needs, is the best version of software development I’ve experienced.
But the path to that destination runs through honesty about where you are right now. Not through performing a methodology you’re not yet equipped to actually run.
Use what fits your situation. Be clear about what you’re doing. Hold the people in your organisation accountable for creating the conditions that better processes require.
That’s less exciting than announcing an Agile transformation. It’s also the thing that actually works.
The best process is the one your team will actually follow, in the conditions that actually exist. That’s the beginning and the end of it.