Before you crucify me, I admit that my post title is clickbaity.

I had this realization relatively recently that most of my colleagues were “born” into Agile, most of them heard the terrifying stories of Waterfall, but none of them practiced it, this post isn’t going to be one of those Horror stories, it’s actually going to paint Waterfall in a positive way, but still, in the end, it will convince you the reader that an adaptive way of working is better for our time (without mentioning it after this sentence.)

Let’s start with the basics,

What the F is Waterfall?

If you want to know in details there’s this Wiki site, I’m guessing you’ve heard of it, feel free to read more here 

A quick recap from my perspective

Waterfall work in sequence, each part of the work has its time and once one chain in our sequence finished they ship their artifacts down the lane, easier put with a diagram:

• Gather Requirements for the entire solution –>
• Design the entire solution –>
• Implement the entire solution –>
• Deliver the entire solution.

Easier than the diagram: Imagine a Waterfall 🙂

Well, that sounds scary, too assuming and leaves no room for adaptive approach or place for error, and also not that awesome, so how can I turn you on to it?

Let’s turn on our time machine, Get our C/C++/Pascal out from storage/cellar clean it up from all the dust and jump back 36 years into the past.

(Yes yes I’m cheating a bit, but as I said before, I’m not here to tell you horror stories about Waterfall, I’m here to turn you on to it AND to turn you on to iterative adaptive process without talking about it (sort of) ).

The year is 1983, you are working in a Software Company, the internet is not really a thing.

The product you are creating is most likely shipped as Hardware Installation and it has to work out of the box immediately OR your product is a software product copied into Floppy disks and shipped to stores around the world.

Problems we have (in 1983 I remind you):

• Requirements Gathering: Talking to our clients’ means, travel to them directly which is an expensive and taxing process (If only talking to people all over the world would have been easy via a computer).
• Software Design and Implementation: We need to understand our specification document, we know that the doc is static (most of the times), but it’s usually very long and describes a lot of different scenarios, it’s a lot of reading and starting to write code is really hard.
• Software Release:
  • Once we’ve delivered our Hardware/Floppy, the cost of change is extremely high, so iterating on what we released and delivered is too costly and would mean extreme annoyance to our customers and would drive us out of business most likely.
  • Our software lives for the life cycle of the Hardware we shipped it on (most of the time) and most of the time updates are not needed (unless we screwed up badly).

There are probably a lot more problems, but those are fine for the sake of our example and thought experiment.

 

How do we solve our problems?

• Requirements Gathering: 
  • Well, we can gather requirement in one go, ask our biggest customers what are the problems they have and ask ourselves what’s our vision, how do we want to solve it, we will probably have some calls and even go to some customers offices, but until we know what we do… we will probably need to make sure our specification book is airtight.
• Software Design and Implementation: 
  • Once we have a fully written specification document/book we design the solution, we do a BUFD (Big Upfront Design), we know that the requirements will not change so we can ensure the best quality as our design is there to solve our problem at hand.
  • After we have our Design ready, we implement until all features specified in our spec document are done.
• Software Release: 
  • We deliver to QA for intense testing before our release, we make sure that all features on the spec doc are working properly and that our product is not behaving weirdly, we iterate over bugs found several times until our software is in a good enough shape – remember!  bug fixing at the customer is extremely costly we want to avoid it like the plague, QA testing is the most important part of our process.

What’s the point?

Seems like if we follow this process:

• Product people will plan ahead in advance, they’ll figure out the ins and outs of our product and create a well-defined specification document.
• The engineering team will design and implement the product.
• QA department will test it (and iterate with The engineering team until all important bugs are fixed).
• We ship

We reduce costs, increase quality while still being able to deliver value to our customers.

Yay! we solved it!

Let’s quickly jump back into our time machine, go to 2019 quickly and ask ourselves

What’s the point of this post?

I basically wanted to share with you (the reader) what is Waterfall, to explain why it actually worked, why it was designed the way that it was while encourage you to think about your problems today, to ask yourself if your process solves those problems, ask yourself what are the limitations you have today as well.

Clearly, Waterfall wouldn’t work for most places today, those problems that Waterfall solved are dated…

Summary

Waterfall worked well and was constructed to solve problems of an era, it worked well for the limitations of its time and many great products were delivered using it.

Our era is faced with different challenges, those challenges are different, our limitations and abilities are also different, I hope that by reading this article I convinced you that

• Waterfall is not the root of all evil but was an efficient mode of working for the limitations the era faced and the challenges of the era.
• You need to always ask yourself what are your problems, what are the limitations you have and what are you trying to solve, you know… be “Adaptive” 🙂 (yes I mentioned it in the end)

I know I promised I wouldn’t mention, but…

Fun anecdote I learned recently, Agile was actually supposed to be called Adaptive, the Agile name, in the end, was a compromise name, I really prefer it to be called Adaptive as I feel it better describes the best use of Agile: Communication and adaptive planning over document writing and predictive planning.

 

* Thanks to culture less developers for the last anecdote, check them out if you understand Hebrew. (Best developer culture podcast I know)

At: http://notarbut.co

Highly recommended!