The Waterfall model is a sequential design process used in software development, with the development life cycle of Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance progressing steadily downwards, just like a waterfall flows down. Completion of one stage leads to another, and each stage has its separate goals. It owes its origin to the standard workflow process in the construction and manufacturing industries.
The advantage of the Waterfall method is the division of the project into tight compartments, reducing the dependency on individuals in the team. Key individuals coming and going at the transition points of stages does not affect project execution. The method also calls for robust documentation, further lessening the dependence on individuals.
The disadvantages are the inflexibility and rigidity. Just as water that flows down a waterfall cannot come back, it is not possible to alter a completed stage or even the project design in any way. Requirements gathering upfront therefore become critical. The logic is that the time spent upfront to ensure comprehensive requirements gathering and design saves considerable time and effort later.
Agile software development bases itself on an iterative and incremental approach. Software developers work on small modules, and respond to users’ changed requirements rather than follow a specific or predetermined plan of action. The basic design is simple, and changes are made as work progresses.
Unlike with the Waterfall method, testing and customer feedback occurs simultaneously with development. This method gives priority to collaboration over design. Interactions among stakeholders take priority over processes and tools, and working software takes priority over documenting procedures. Different developers may work on different modules, and integrate all modules together at the end.
Agile methods of software development gained popularity in the 1990s as a reaction to the drawbacks of the traditional Waterfall methods. Critics considered the Waterfall method heavily regulated, regimented, and micromanaged to suit many needs, and have been working on various incremental approaches experimented since 1957.
Both the Waterfall method and the Agile method of software development have their uses. Although Agile arose as a reaction to the limitations imposed by the Waterfall method, Waterfall still retains its relevance as a better method when the environment is stable with no room for changes, when frequent interactions with ends users and other stakeholders are not possible, or when there is a risk of key developers quitting the project midway.
Agile is a lightweight method. As software developers focus on smaller work areas, overhead becomes less, and the project costs considerably less than when using the Waterfall method. When customer requirements are hazy, or the business environment is uncertain, Agile methods that allow making frequent changes, and testing during the construction stage remains the best choice. Successful execution of Agile projects nevertheless requires highly skilled and competent developers, and stakeholders who know what they want. With the scope to accommodate changes, an Agile project can easily lose its way.
Please be sure to check out the other items in Bright Hub’s collection of Agile project management guides and discussions.
- Sliger, Michele; Broderick, Stacia (2008). The Software Project Manager’s Bridge to Agility. Addison-Wesley. ISBN 0321502752.
- Royce, Winston, W. “Managing the development of large software systems.”. Retrieved from https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf