Waterfall vs Agile – Why you shouldn’t choose

By Rob Murdock, Consulting Manager, Rizing – Consumer Industries

Introduction

The last decade has seen widespread adoption of Agile methodology, a great tool when applied appropriately.  I’ve used Agile, and like many others see significant advantages in leveraging this approach.  When dealing with tasks that are iterative in nature, Agile is my tool of preference as it guides quickly to a minimum viable product (MVP) and avoids spending unnecessary time delivering functionality that isn’t in scope.  It’s also much easier to manage and control since updates are provided daily and deliverables are far more tangible.  On the other side of the spectrum, Waterfall methodology is applied when dealing with tasks that have dependencies or when a process is already in place.  Too often, I’ve come across situations where teams want to put a stake in the ground and select a “one size fits all” approach when it comes to methodology approach, and all to often, that is a big mistake.

In this blog, I will discuss when you should embrace each methodology, and how a hybrid approach effectively supports key project goals (time, scope, cost and quality).

What’s the real difference between Waterfall and Agile?

Waterfall 101

Waterfall methodology, boiled down to basics, is a simple A to B to C “do things in this order” approach.  If you ordered a new cell phone, the steps to transfer contacts, calendars, photos, etc is a pure waterfall approach.  But that doesn’t exclude you from performing other tasks simultaneously, like setting up a new online account with the new provider.  Here is a project example; before I can deliver training, I need a training plan (what are we training, who is receiving the training, how is training being delivered, etc).  Before I can develop a training plan, we need a training strategy.  Trying to do the plan without the strategy will likely result in significant rework without the guidance and clarity aligned on (and approved by leadership) in the strategy document. So it’s effective and efficient to take the time to first develop the training strategy, then a training plan.

Waterfall – A Thanksgiving dinner example

Let’s have a little fun and explain each methodology using “developing and executing a Thanksgiving dinner” example.  Here are the core milestones:

1. Who is attending (how much food do a need to serve)
2. What am I serving (menu creation)
3. What materials (ingredients) do I need
4. How do I prepare each item (knowledge transfer)
5. When am I doing this (schedule)
6. How much will this cost (budget)
7. Who is cooking (resource planning)
8. Last – Identify Key stakeholders (In-laws)

Because I don’t have to create the ability to cook this menu (cookbooks already provide this documentation), I can follow a waterfall approach and sequence events and schedule “deliverables” around the planned serving of the meal.  Identify dependencies, I can’t cook what I haven’t acquired, I can’t shop for food if I don’t know what I’m serving.

In traditional Waterfall, you plan these activities, ensure you have the resources to execute, and manage against that plan.  As you deliver your future holiday dinners, this process gets easier to repeat, less error prone, and generally results in better outcomes.

Where Waterfall fails in this example is when you are creating this for the very first time.  Example – I’ve never deep fried anything in my life.  Starting to deep fry a turkey Thanksgiving morning with no experience likely won’t result in a positive outcome.  Doing a test-run a month prior, probably a good idea (here – think iterative development until a MVP outcome is achieved).  To supplement the negatives of Waterfall, a hybrid approach of pre-practicing what has never been done before, and even breaking down certain tasks that can be pre-done and/or executed in a more time-boxed fashion enable leveraging some of the best of both methodologies.

Agile 101

Agile methodology, reduced to simple terms, is breaking down tasks into smaller, manageable activities that are designed to result in a measurable result. A good example would be a team breaking off a product enhancement (say, I want to identify all customers who bought laundry detergent more than 30 days ago, and send them an e-coupon promotion for x brand of detergent) and breaking that work down to smaller tasks.

1. Identify customers who purchased category = laundry_detergent AND date > today + 30
2. Create eForm with promotional coupon
3. Populate each eForm with customer_name and customer_email
4. Test
5. Correct defects
6. Test
7. Release

This is a fast, effective means to develop new functionality, execute testing, and prioritize defect resolution.

Agile – A Thanksgiving dinner example

In true Agile, we would have a product owner who would define the product, and prioritize key capabilities or functionality they want.  Product owner:  “I want the Turkey first, it’s the most important dish on the menu.”  Great – team runs off to the kitchen and figures out what a turkey is, iteratively create the turkey portion of the dish until they’ve created a “MVP” turkey – which is then released to the client.  On to the next release, pumpkin pie, then mash potatoes.  Agile will get you incremental value faster, but that may not always translate into a useful outcome.  You get the point, being “Agile” is most beneficial when creating or developing something new, not following an existing process.  Since we want the entire meal served appropriately, a hybrid approach enables using Agile to plan out and execute new tasks where appropriate as well as time-boxed activities. We’d then use Waterfall to enable multiple activities being managed concurrently, like having team ‘a’ cooking and basting the turkey while team ‘b’ is preparing salad or using the same oven on the same temp to cook dinner rolls. A hybrid approach leverages the best of both tools.

All tools have an application, not all applications need a tool

The point is that both Waterfall and Agile are valuable tools in our project execution toolkit.  Exclusively choosing one over the other is like only using a hammer when a wrench is the right tool.  When we look specifically at the IT industry and focus on major upgrades, weather it be upgrading from one version to a new one, or switching systems all together, the approach shouldn’t be an either/or, it needs to be a thoughtful, which tool do I apply and when.  Within the SAP Activate Methodology, many of the early activities need to follow a Waterfall approach.  We need to define scope, establish governance, align on key design decisions before we begin to put developer fingers on keyboards.  Step A needs to happen before step B.  But once we’ve done the front-end prep and requirements are defined, prioritized, and approved, it’s the perfect time to leverage Agile and develop and release capabilities in multiple sprints.  Testing and defect resolution also fit very well in the Agile approach.  I don’t need to test functionality like year end close-out if that won’t happen for another 9 months, when we can focus today on month end close-out.  Deliver that functionality first, then go back and test less time sensitive examples.

Conclusion

Don’t treat project methodology like religion.  You don’t have to be exclusively in camp Agile or camp Waterfall.  Smart project teams maximize the best of both approaches and deliver a hybrid methodology, one that leverages each methodology at the right time, for the right purpose.  This supports the ability to delivery high quality, effective results, and doesn’t hand-cuff teams into a mandate to utilize only one tool, when that mandate is counter-productive.