Recently I have been involved in a discussion what is waterfall (of course in software development perspective).
The very first thing comes to the mind is that waterfall software development is a phased approach (over iterative Agile). You have got defined phases and boundaries to cross like “Requirement phase, Design phase, etc.”
If you stop for a moment and look in detail, you will realize that this is more of a description of the “Execution model”. Or how the Waterfall model is executed. But there is much more deeper conceptual definition if you look at from a business perspective.
When you look at software engineering from the problem vs solution concept, you can see it. Software is a solution for a business problem. And software engineering is all about articulating the solution.
So this is how the Waterfall approaches;
- You have the “Business problem” and
- You have a layer to “Specify the problem” (requirement),
- Another layer to “Specify the solution” (architecture and design),
- Another layer to “Develop the solution” (development),
- Another layer to “Confirm the solution” (testing)
- Final layer to “Apply the solution” to the problem (Deployment).
Through this you can transform the horizontal phases of waterfall to vertical layers and by doing so you can see how the waterfall development is really structured.
I don’t need to mention the waste and the confusion this causes when you have so many layers between the Problem and the Solution.
But Agile software development provides a much more compact approach which is more effective than Waterfall. In Agile, you just have two layers representing the Problem and the Solution. Problem is represented by Product owners (if you consider Scrum) and Solution is represented by Development team. By reducing the unwanted layers in the middle, Agile has reduced the waste and the confusion.
But as a note this doesn’t mean that you can avoid the needed steps like design, testing, deployment, etc. It is just that all are done within one layer