Agile, Waterfall or Hybrid: Choosing a Delivery Approach Honestly

The agile-vs-waterfall debate is mostly noise. Real projects choose based on three questions, and many end up — correctly — with a hybrid.

The three questions

  1. How stable are the requirements? If scope can genuinely be discovered iteratively (software, product design), iteration adds value. If the deliverable is fixed by contract and physics (a bridge, a refinery), pretending to discover it in sprints is theatre.
  2. What does change cost? In software, changing course costs a sprint. In construction, changing a foundation design after pour costs months and crores. High cost of change → invest in up-front definition (waterfall's whole point).
  3. What does the regulator or contract require? Stage gates, design approvals, and EPC contract structures impose sequence regardless of methodology preference.

What each does well

Waterfall / predictive delivers when scope is definable up front: clear baseline, meaningful EVM, contractual clarity, and a schedule you can hold parties to. Its failure mode: discovering in month 18 that the requirement was wrong in month 2.

Agile delivers when value can ship incrementally: early feedback, re-prioritisation, and no big-bang integration risk. Its failure modes: scope-creep dressed as "responding to change", and weak long-range cost/schedule visibility — which is exactly what sponsors and CFOs need.

Hybrids that actually work

  • Stage-gated shell, agile inside. Fixed gates for funding and design approval; iterative delivery between the gates. Common in banking and pharma IT.
  • Predictive structure, agile workstreams. A construction megaproject scheduled in P6, with the digital/BIM and commissioning-software workstreams run in sprints, integrated at milestones.
  • Rolling-wave planning. Detailed planning for the next 90 days, planning packages beyond — predictive in shape, adaptive in detail. Native to both P6 practice and PMBOK.

Making the hybrid controllable

The hard part is progress measurement across methods. Practical answer: map sprints to work packages in the WBS, earn value on completed, accepted increments only (0/100 per sprint outcome), and roll it into the same S-curve as the predictive work. Sponsors get one integrated picture; teams keep their working rhythm.

The honest test

If your "agile transformation" still has a fixed scope, fixed date and fixed price — you've chosen waterfall with extra meetings. And if your "detailed 3-year baseline" is re-planned every quarter — you're doing rolling-wave; formalise it and stop calling the variance a failure.

Explore delivery-approach content in the Knowledge Hub, or compare tooling in the Software Hub.

Keep reading