Waterfall Teams

Waterfall Teams use the waterfall model of development that entails a linear sequential path through requirements definition, analysis, design, development (coding), testing, deployment and maintenance. The waterfall model has been extensively proven* to be badly suited to Software Projects as it is only suitable for trivial, very small time frame, very low risk work with an experienced team where everything is completely predictable.

Often described as the traditional approach to software development, the waterfall approach is characterized by following a set of distinct sequential process stages such as Requirements Definition, Design, Build, Integration, Test, Deployment.

Waterfall’s sequential stages encourage development of intermediate work products to pass information across stage boundaries. Because each stage is done only once it must be fully complete before the next is started. This leads to lengthy up front requirements definition which aims to fully understand system requirements so that they can then be frozen before starting the design stage etc.

This approach leads to the system only being available in one release at the end of the entire lifecycle, often called a “big bang” approach. This means that business value can only be realized at the eventual end of the lifecycle, not in incremental parts, meaning that return on investment is delayed to the end of the project. Critically, the only meaningful point of feedback, when the actual system can be tested and used by customers only happens once, at the very end. Waterfall methods only allow for feedback once, not continuously. Feedback against plans, especially course corrective feedback, simply doesn’t compare to feedback against actual output.

Typically, waterfall approaches lead (by design) to very late integration breakages and bug discovery since testing is only done at the end of the project once coding is complete. In this model, risks are only mitigated at the very end of the lifecycle once testing is complete and behavior is proven.

Waterfall can sometimes feel intuitive as it is simpler to grasp than iterative/agile methods. Waterfall methods seem to make sense for physical construction and sometimes these metaphors are badly used for software development. Waterfall gives a perception of management control since problems aren’t identified until the end of the project. As a result, a project can seem to be executing normally without problems for 90% of its lifecycle as the mess of early tests, bugs and changes is avoided until the end. A common dysfunction in waterfall processes is that as the schedule gets squeezed testing effort is reduced in favor of scope and so quality is diminished.

Is Waterfall ever appropriate?

Waterfall may feel an attractive approach for extremely short, low risk projects, even then a continuous flow model would be preferable as each requirement can be tested (reducing risk) as it’s developed. For larger and/or riskier projects we recommend an iterative approach. For large very low risk projects we recommend splitting the project into parts that can be delivered incrementally or in parallel since there is no reason to assume that low risks never happen, some level of assurance part way through is advantageous.

Splitting a waterfall project into a number of smaller deliveries, with a little up front scoping requirements, architecture and planning is in fact iterative development. Splitting those parts down to the size of the smallest deliverable requirement is a continuous flow model.

We cannot recommend waterfall methods for software development.

* See “The Business Value of Using Agile Project Management for New Products and Services” by Dr. David F. Rico, PMP, ACP, CSM for a study of studies – although this does compare waterfall vs. agile.