Agile or Waterfall?


Just because something doesn’t do what you planned it to do doesn’t mean it’s useless. – Thomas A. Edison (1847-1931)


So, which is a better approach to project management? Agile or Waterfall?

The answer is simple: Agile is better. It’s newer, it sounds cooler and it has better terminology (scrums and sprints – that’s awesome!).

Still not convinced? Then check out some of these dank memes that pop up when you to a Google search on “agile or waterfall”.

In just a few simple pictures, you can plainly see that the Agile approach is easier…

Agile Methodology vs Waterfall Model: Pros and Cons

…less risky…

comparison of agile vs waterfall | Waterfall project management, Project  management, Agile

…quicker to achieve benefits…

…all with a greater likelihood of success.

2019 UPDATE] Agile Project Success Rates 2X Higher Than Waterfall
So if it’s been settled for the ages, then why am I writing this piece? And why are you detecting a very slight hint of sarcasm in my tone thus far?

The Agile framework has its roots in software development and in that context, I have no doubt about its superiority. That’s because new software is (generally speaking) easy to modularize, easy to test and easy to change when you find errors, vulnerabilities or awkwardness for the user all with very little risk or significant capital outlay.

I’m certainly no expert, but intuitively, Agile project management seems to be exactly the right tool for that kind of job.

Where I take issue is when I hear it being bandied about as an outright replacement for all previous project management methods because it’s trendy, regardless of whether or not it’s the right fit.

Some Dude: “We’re embarking on an Agile transformation!”

Me: “That sounds great! What do you mean exactly?”

Same Dude: “It means we’ll be more agile!”

Me: “Uh, okay.”

Building a new skyscraper is a project that consumes time, materials and resources and is expected to achieve a benefit upon completion.

You can’t approach such a project with the mindset that “we’ll buy some land, start building upwards and make adjustments as we go”. When you get up to the 20th storey, it’s not so easy to make a decision at that point to go up another 20 storeys (did you put in a foundation at step 1 to support that?). Everything needs to be thoroughly thought through and planned in a significant amount of detail before you even purchase the land, otherwise the project will fail. Yes, there are opportunities to make small changes along the way as needs arise, but you really do need to be following a “grand plan” and you can’t start renting it out until it’s done.

Similarly, if you had a medical condition requiring several complex surgeries to be performed over several months, would you opt instead for a surgeon who says “I’ll just cut you open, start messing around in there and quickly adapt as I go – we can probably shave 20% off the total time”?

This brings me to supply chain planning in retail. On the face of it, the goal is to get people out of spreadsheets and into a functional planning system that can streamline work and improve results. It would seem that an Agile approach might fit the bill.

But building out a new planning capability for a large organization is much more like building a skyscraper than coding a killer app. Yes, the numbers calculated in a planning system are just data that can be easily changed, but that data directly drives the deployment of millions of dollars in physical assets and resources. It requires:

  • Tons of education and training to a large pool of people, grounded in principles that they will initially find unfamiliar. The unlearning is much harder than the learning.
  • A thorough understanding of what data is needed, where it resides and what needs to be done to improve quality and fill gaps.
  • A thorough understanding of how the new planning process and system will fit in with existing processes and systems in the organization that won’t be changing.

All of this needs to happen before you “flip the switch” to start moving goods AND the business has to keep running at the same time. A former colleague described projects of this nature as “performing open heart surgery while the patient is running a marathon”.

After this foundation is in place and stabilized, there are opportunities aplenty to apply Agile techniques for continuous improvement, analysis and a whole host of other things. But there needs to be a firm base on which to build. Even constructing a killer app with the Agile approach still requires a programming language to exist first.

So what am I saying here? That large scale organizational change programs are complex, risky, take a lot of time and require significant upfront investment before benefits can be realized?

Yeah, pretty much.