For decades, we’ve been sold a story: “Waterfall bad, Agile good.” It’s become gospel in our industry. Waterfall is rigid, linear, outdated. Agile is flexible, iterative, modern. End of discussion…..Except it’s complete nonsense.
The Strawman We Love to Hate
Most developers who trash “Waterfall” are attacking a caricature that never existed. They imagine some dinosaur process where requirements get locked in stone, customers disappear until launch day, and any change requires rebuilding from scratch.
Here’s the kicker: Dr. Winston Royce never called his process “Waterfall.” The guy everyone blames for this supposedly terrible methodology warned against doing it just once. His exact words? A single-pass approach “is risky and invites failure.”
His solution? “Do it twice.” Build a pilot, test it, learn from it, then build the real thing. Sound familiar? It should, because that’s basically what every smart development team does today, regardless of whatever methodology they claim to follow.
Royce also insisted on customer involvement throughout the process, not just at the beginning and end. He advocated for formal reviews at multiple checkpoints. He understood that testing late in the cycle was dangerous and expensive. In other words, the “father of Waterfall” was preaching iteration, customer feedback, and risk management back in 1970. Somehow, we’ve spent 50+ years fighting a strawman.
Agile’s Dirty Little Secret
Don’t get me wrong, the Agile Manifesto says all the right things. Customer collaboration over contract negotiation. Responding to change over following a plan. Beautiful ideals.
But here’s what nobody wants to admit: most Agile teams are terrible at being agile. They sprint through two-week cycles, sure. They have daily standups and retrospectives. They use the right vocabulary. But how often do they truly test with real customers? How quickly do they deliver value? How well do they adjust or adapt when requirements change?
Too often, “Agile” becomes just as rigid and dogmatic as the Waterfall caricature it replaced. Teams get so caught up in following Scrum ceremonies that they forget the whole point was to build better software faster.
The Gate That Everyone Misunderstands
Then there’s phase-gate, the methodology everyone loves to hate even more than Waterfall. Critics dismiss it as bureaucratic checkbox theater or a mindless workflow for corporate drones. This completely misses the point. A gate isn’t just a checklist. It’s a decision point. It’s the moment when smart organizations ask: “Should we keep throwing money and people at this project, or should we kill it?”
Think about that. How many failed projects could have been avoided if someone had the courage to ask hard questions at the right moments? How much waste could be prevented if teams had to prove value before getting more resources? The phase-gate process is designed to kill bad ideas before they become expensive disasters. It’s about business and risk management, not red tape. When implemented properly, it’s one of the most powerful tools for ensuring that innovation dollars go to projects that matter.
The Real Problem
Here’s what’s happening: we’re spending more energy arguing about methodologies than focusing on what makes projects succeed. We’re treating process frameworks like religious doctrines instead of tools to be adapted.
Good development, regardless of what you call it must always include customer validation, iteration, and ongoing learning. The smart practitioners understood this from the beginning, regardless of which label they used. The real enemy isn’t any particular methodology. It’s dogma. It’s the belief that there’s one right way to build software, and anyone doing it differently is wrong.
What Really Matters
Instead of fighting methodology wars, let’s focus on what drives success:
- Understanding the problem before jumping to solutions
- Getting feedback early and often from real users
- Managing risk by testing assumptions quickly
- Making informed decisions about where to invest time and money
- Documenting what matters so teams can collaborate
- Learning from failures instead of pretending they don’t happen
These principles work whether you’re following Scrum (or whatever), using phase gates, or making it up as you go along.
Let me wrap up: It’s 2025. Can we please stop pretending that methodology choice is the most important factor in project success? Can we admit that smart people have been building great software for decades using different approaches?
Dr. Royce got it right 55 years ago: the key is understanding what you’re trying to accomplish and adapting your process to fit the problem. Not the other way around.
Maybe it’s time we started listening.
Advance Your Product Management Career—Start Today
If you’re ready to move beyond process debates and build lasting product leadership skills, the Product Management Career Accelerator Course is your next step.
This self-paced online course is designed to help you:
– Gain clarity on your role and responsibilities
– Build the competencies top companies expect
– Create a personalized career development strategy
– Learn directly from Steven Haines, author of The Product Manager’s Career Path
Includes a free copy of the book with enrollment.
One-time fee: $99
Start building the product career you deserve.
👉 [Sign up for the Product Management Career Accelerator Course]