A misleading example of Agile & Waterfall!
Ahmed Said
Principal Technical Project Lead at Integrant, Inc | Scrum Master at Coca-Cola Consolidated
The above image is the most misleading example I’ve ever seen describing the differences between Waterfall and Agile approaches, and here's why:
(the above image has so many different presentations online, I managed to make my own but I'm sure you'll find it everywhere with the same idea but with different presentation)
In the above example, it’s obvious that the customer wants to have a car as an original requirement, right? And what happened next?
In the 1st half of the picture (the traditional waterfall)
He got a wheel first! Then a chassis, then a body! And finally, he got his car! Is that a real waterfall example guys? Are you delivering your product incrementally in waterfall? I thought waterfall is a sequential process, and if it's an incremental process, why do we need agile then?
I’d assume if this is a real waterfall approach, the customer won’t see anything until the product is totally finished, right?
In the 2nd half (the agile approach)
He got a skateboard! Then a scooter, then a bicycle, then a fast motorcycle, then a sedan car!
Could you imagine what could happen to a company that has been asked to deliver a car and they delivered a skateboard instead?
While having the customer unhappy after building this nice skateboard, next cycle you sent him a scooter, although he wants a car! I can imagine that the customer will shut down the deal at once. Because simply that means there’s a massive issue in understanding the customer needs and he is always getting something not meeting his expectation. He will switch to someone else he can understand his needs, right?
The intersection between the 2 halves
By combining the 2 halves together we’ll get into the below conclusion:
1- Waterfall requirement gathering process is 100% perfect and much better than Agile, right? The customer asked for a car and he got a car exactly the way he is expecting.
2- Agile approach has a massive amount of wastes, do you believe that a skateboard can be used to build a car at the end? Or can any of the bicycle’s parts be used to construct a car? It’s not possible, right? Instead each cycle you had to construct a brand-new product and destroy the previous one to meet your customer expectations. That’s so expensive!
3- Although the customer wasn’t involved in the waterfall process at all, he just asked for a car and he got it at the end. That means early feedback from customers is valueless, right? Not only that but also the feedback process didn’t help in building the right thing for the customer using the Agile approach.
4- The improvement or learning curve in each cycle is super slow in Agile. Each cycle you are building a brand-new product to your customer and failure happened 4 times out of 5. The agile team didn’t figure out that the customer wants a car until the 5th cycle!
Honestly, if I looked at the above picture and know nothing about Agile and Waterfall, I’d praise how the waterfall approach is more robust and deliver the customer what exactly he needs! On the other hand, I’ll never recommend Agile to anyone because of this massive waste of resources, communication, budget, and time!
Where’s the real problem?
The real problem in the above picture is combining the 2 halves together with the labels used! Think with me about removing the 1st half from the picture so it’ll look like this:
It’s totally different, right? It’s actually illustrating the idea of building an MVP (Minimum Viable Product) and evolving the idea each cycle. It also could mean that the customer didn’t want a car in the 1st place, he wanted to move from point A to point B and that’s it. And each time you are delivering him a solution to help him do that until he is satisfied. Do you see the difference? (the original author and article that introduced that image/ example, but other authors tweaked the image until it lost its main purpose)
But when it was combined with the 1s half of the waterfall part, it lost its purpose completely and became a discouraging thing to be Agile. And moreover, it is wrongly praising how waterfall is better than Agile in communication, requirement gathering, and budget! The total reverse of the main target of the image.
Business brain Showa Ota
1yThank you for clarification! so useful!
MyCMP Project Manager at Gulfstream Aerospace
3yThere should be a comparative illustration when deciding on Waterfall or Agile, as Agile is not always the best solution for developing non-software projects. For the Kniberg car illustration, it isn't logical to perceive the project as "move from point A to point B", since the illustration for Waterfall is not supportive. I firmly believe the illustration supports the project "Build a Car". Confusion is created due to the inappropriate Agile example. The below illustration is much more appropriate, with Waterfall at the top and Agile at the bottom. I would take this illustration one step further and show the Agile Sprint 4 deliverable as a different type of car than Waterfall. Agile would have the advantage of working directly with the PO to know the color, and specific style desired, while Waterfall would be a square-angled, black object on wheels (1886 Motorwagen). It's often challenging to look at examples of items that already exist and associate Agile, since Agile centers on development of a feature yet to exist. Image Source: https://blog.ippon.tech/agile-story-development/
Improving the world by improving the people in it
3yOh, finally! Kniberg must be fuming at how his original diagram got so misappropriated. I'm sure Royce ranted when he found his explanation about waterfall became adopted as a model to aspire to, rather than a diagram to illustrate concerns.