A couple of years ago I was asked by a client if they should “Go Agile”. I just stumbled on this graphic which perfectly sums up my response at the time. Basically, if your organisation has a fixed budget, fixed timeframe and fixed set of deliverables, that’s pretty much what Waterfall was designed for and it’s worked well for decades.
When Waterfall makes sense: Government contracts, regulatory compliance projects, infrastructure implementations where requirements are well-defined upfront and changes are expensive. You know exactly what needs to be delivered, you have a fixed budget and timeline, and scope changes require formal approval processes. Waterfall excels here.
When Agile makes sense: Product development where user needs evolve as you learn more. Software projects where requirements emerge through experimentation. Situations where delivering working functionality early and iterating based on feedback creates better outcomes than planning everything upfront.
Don’t get me wrong – Agile is great. It has a lot more end-user/client interaction and it’s easier to pivot when required. But it’s not a fix-all and it can get expensive and blow out timelines if it’s not done right. I’ve seen too many organisations decide to embrace Agile without properly assessing the pros and cons.
In my recent MBA Business Consulting unit we covered several methodologies and frameworks with a perspective of being able to identify “right tool for the job”. Sometimes a solid option is “Wagile” – Agile-like practices within a Waterfall project plan.
