Client asks: “Should we use Agile or Waterfall?”
Wrong question.
Real question: “What’s the best way to deliver what you need?”
Methodology debates waste time. Clients don’t care about your process. They care about results.
Here’s what actually matters.
The Real Difference
Waterfall: Plan everything upfront. Build it. Deliver it at the end.
Agile: Plan a little. Build a little. Learn. Adjust. Repeat.
That’s it. Everything else is noise.
The methodology zealots will tell you one is always better. They’re wrong.
When Waterfall Works
Building a bridge? Use Waterfall.
You can’t build half a bridge, test it with real traffic, then iterate. You need the full plan upfront.
Same with:
- Regulatory compliance projects with fixed requirements
- Hardware integrations with long lead times
- Fixed-scope government contracts
- Projects where changes are expensive or impossible
Client knows exactly what they need. Requirements won’t change. Build it once, build it right.
Waterfall isn’t dead. It’s just not the default anymore.
When Agile Works
Building a new customer portal? Use Agile.
You think you know what customers want. You’re probably wrong. Better to find out early.
Agile works when:
- Requirements will evolve as you learn
- User feedback matters
- Market conditions change fast
- “Done” is unclear at the start
Get something working fast. Show it to users. Learn what matters. Adjust.
Most software projects fit here. Not all.
The Trap Consultants Fall Into
Consultant shows up: “We do Agile.”
Client has a fixed-price contract with defined deliverables and a hard deadline.
Consultant insists on sprints, retrospectives, adaptive planning.
Project fails. Consultant blames the client for “not being Agile enough.”
Wrong approach.
Your job isn’t to impose methodology. It’s to deliver results with the constraints you’re given.
What Clients Actually Care About
Will it work? Does the solution solve the actual problem?
Will it be on time? They have business deadlines. Miss them and your process doesn’t matter.
Will it be on budget? They allocated money. Spend more and they don’t care that you were “responding to change.”
Will we know if something’s wrong early? Surprises kill projects. Methodology should surface problems fast.
Pick the approach that delivers on these four things.
The Hybrid Reality
Real projects don’t fit neat categories.
Migration project? Waterfall for infrastructure changes that need sequencing. Agile for the new features you’re building on top.
ERP implementation? Waterfall for the core system. Agile for custom workflows that need user testing.
Product redesign? Agile for discovering what users want. Waterfall for the final build once you know.
Most experienced consultants use both. Sometimes in the same project.
Red Flags
Client says: “We’re an Agile organization” but won’t let you talk to end users.
That’s not Agile. That’s Waterfall with standups.
Consultant says: “We need Waterfall” but can’t articulate what the final deliverable looks like.
That’s not planning. That’s hoping.
If someone’s treating methodology like religion, run.
The Questions That Matter
How clear are the requirements? Crystal clear? Waterfall might work. Fuzzy? You need Agile.
How expensive are changes? Cheap? Iterate. Expensive? Plan carefully.
What’s the risk of building the wrong thing? Low risk? Execute the plan. High risk? Validate early and often.
What does the client’s organization actually support? They say Agile but have a change control board that takes 6 weeks? Work with reality, not wishes.
When does the client need to see progress? Monthly? Quarterly? End of project? That tells you how to structure delivery.
What Good Consulting Looks Like
Assess the actual situation. Don’t bring a predetermined methodology.
Client needs a fixed price and scope? Structure it like Waterfall with clear phases and gates.
Client needs to explore and learn? Structure it like Agile with incremental delivery and feedback loops.
Client needs both? Do both. Discovery phase that’s Agile. Implementation phase that’s Waterfall once you know what to build.
Match the approach to the problem. Not the other way around.
The Courage to Choose
Sometimes clients want Agile because it sounds modern. But their project needs Waterfall.
Tell them.
Sometimes clients want Waterfall because it feels safe. But their requirements are too unclear.
Tell them.
Your job is to recommend what works. Not what’s trendy or comfortable.
The Real Skill
Junior consultant: “We should use Agile for this.”
Why?
“Because Agile is better for software projects.”
That’s not thinking. That’s repeating what you heard.
Senior consultant: “We should use iterative delivery for the customer-facing features because requirements are unclear, but phased delivery for the backend migration because the technical sequence is fixed.”
That’s thinking.
The skill isn’t knowing Agile or Waterfall. It’s knowing when to use what and why.
What Success Looks Like
Project finishes. Client gets what they needed, when they needed it, for the price they expected.
They don’t remember whether you used Agile or Waterfall.
They remember you delivered.
That’s the only methodology that matters.