Every few weeks, someone in a steering meeting declares that waterfall is dead and agile is the answer. Then someone else asks how agile will work for the data center migration. Both people have a point, and neither has the whole picture. The useful question isn’t which approach wins. It’s which approach fits the work in front of you.
What waterfall does well
Waterfall (and its cousin, the stage-gate process) assumes you can know most of what you need up front, then build it in order. When that assumption holds, the approach works well. Consider a regional bank that must meet a regulatory change by a fixed date, with the requirements spelled out in the regulation itself. Little is uncertain about what to build. The risk is in coordination, documentation, and proof that you followed the rules. A plan with clear phases and sign-offs serves that work.
The same goes for hardware, construction-like projects, and anything with long physical lead times. You can’t iterate on a poured foundation. If a server order takes 12 weeks to arrive, you plan around it.
What agile does well
Agile methods such as Scrum assume the opposite: you don’t know everything yet, and the fastest way to learn is to build something small, show it, and adjust. Picture a retailer building a new customer portal. The sponsors have a vision, but nobody can say which features customers will use. Writing a 200-page requirements document for that project means locking in guesses. Short iterations with real feedback turn guesses into evidence.
Questions to ask before you choose
We use a few questions with clients to sort work into the right bucket:
- How stable are the requirements? If an outside authority fixes them, lean toward a planned approach. If the users will discover them as they go, lean toward agile.
- How costly is a change late in the work? Software changes are cheap compared with rework on a physical build.
- Can the people who know the need work with the team regularly? Agile depends on that conversation.
- Do external dependencies dictate the sequence? If so, you need a plan that shows it.
Most real programs answer these differently for different pieces. That’s the point.
Mixing the two
Large companies rarely have the luxury of one approach. A single initiative might include a fixed-scope infrastructure upgrade, a regulatory report, and a customer-facing application. Run the first two with a plan and gates, run the third with iterations, and agree on how the pieces meet. This takes more coordination than picking a side, but it fits the work.
The risk we see most often isn’t choosing the wrong method. It’s choosing a method for the label. A team that calls its schedule “sprints” while still delivering everything at the end has gained nothing. A team that drops all planning because planning sounds old-fashioned will find the regulator isn’t impressed.
Key message: “Match the approach to the uncertainty in the work, not to the fashion in the meeting.”
Before your next project starts, take 30 minutes and rate it against the four questions above. If the answers point in different directions, split the work. If you’d like a second opinion on where to draw the line, talk to us.