Prior to SCRUM and other popular Agile methodologies, Waterfall model was widely used to organize and deliver software projects.
As the diagram shows, the entire process flows from one phase to another similar to the movement of water in a waterfall. That’s how the name “Waterfall model” came. The process flow is only in one direction ( just like water in a water fall that flows only from top to bottom).
Waterfall Model Phases
- Analysis Phase – An Analyst usually, gathers the requirements.
- Requirements Phase – Requirements are finalized.
- Design Phase – Code and other artifacts of the deliverables are modeled in this phase.
- Development Phase – Designs are put into practice to build the product.
- Testing & Integration Phase – testers makes sure that the products meets the requirements to a high degree of quality
- Operations and Maintenance Phase – After testing the product is released to the customer. Further, there will be ongoing maintenance and support to the product in a live environment, and this is also considered a phase.
The Waterfall model is seen as an industry standard for running software projects for decades. However, there are some fundamental flaws with this model.
Fundamental flaws with Waterfall model
- The Principle flaw with the waterfall model is that it doesn’t accept changes to requirements once the Requirements phase is completed. On the other hand, in a business, things can change rapidly, consequently, the ability to implement changes as and when needed and a better change management approach is always key to success. So, this rigid nature of Waterfall model towards requirement changes is a major flaw.
- Most of the defects are not found until the test phase, this often delays launch as more time is needed to fix bugs.
- The number of defects can never be forecast perfectly, so this often leads to over time. This results in low morale and last minute scrambles in the project.
In the real world software projects, requirements rarely remain fixed for the long term. So, there are only 2 ways to deal with requirement changes in the Waterfall model
- The Delivery team accepts changes in requirements even after requirements phase (violation of waterfall model), consequently there are delays, increase in cost, and also annoyance to the team.
- The client should agree and stick to it that there shall be no requirements changes after the completion of requirements phase. Thus the Project runs smoothly without delays.
Option 1:- In reality most businesses go for this. Changes are inevitable in any business, so they can’t risk losing business at the cost of sticking to a delivery model.
Option 2 :- Changes in requirements are viewed as bad. But the truth is, Change is often a reaction to market condition and is often a good thing. Changing requirements can increase the business’s return on investment, which usually has a good knock on affect on the company and the employees.
However, Neither of these situations is good.
Apart from these problems, the Waterfall model has to deal with other obstacles as any development model would such as
- Unclear requirements,
- unrealistic deadlines,
- inaccurate estimates,
- number and caliber of people working on the project can change eg: People Pinching delays.
These issues that we discussed and other issues are known as Impediments or blockers. Collectively these blockers can cause chaos on projects if allowed to.
In business things can change rapidly, so change management is always key to success. In Waterfall model, changes to requirements cannot be made at a later phase. After decades of running projects on Waterfall model, it was clear that many companies needed a change in the delivery model and a better change management approach in order to keep projects running smoothly.
Recognizing these blockers, a group of thought leaders joined forces to create new iterative Agile Methods of working such as LEAN, FDD, DSDM, RUP, XP, KANBAN, CRYSTAL, SCRUM, SCRUM OF SCRUMS, LESS, DAD, DSDM, AUP, OpenUP etc.