What is Waterfall?

When to Choose Waterfall over Agile Guide

Prior to the extremely popular Agile methodology, there was Waterfall. Waterfall is defined as a sequential or linear product development methodology in which each development phase is completed before the next one begins. Waterfall is a straightforward, logical approach to product development. In this method, you determine what to build, plan the build, work out a schedule, obtain your resources, assign resources, develop the product, hand it off to a test team, work out the bugs, and then release it. Along the way the marketing team creates some “buzz” in anticipation of the product, and sales people convince customers that the new product will solve all of their problems. Since the introduction of Agile, Waterfall isn’t used as often, but there are still there are plenty of times when it makes sense to use Waterfall. This guide will help you decide when to use Waterfall over Agile methodology.

A History of the Waterfall Method

Waterfall is a logical pattern to follow - plan, build, test, and release in sequence. The history of Waterfall stems from Winston W. Royce’s 1970 article from the Proceedings of IEEE WESCON, Managing the Development of Large Software Systems. Royce’s article was probably the first discussion of Waterfall in software development, though the word “waterfall” does not appear anywhere in the article. The formal term was introduced in Thomas E. Bell’s and T.A. Thayer’s 1976 paper from the Proceedings of the 2nd International Conference on Software Engineering, Software requirements: Are they really a problem?. As has been noted in many places, however, Royce’s paper did not praise the method. In fact, he described it in unflattering terms, calling it flawed and inviting failure in many ways. He went on to discuss a more iterative approach, perhaps the foundation of what would become an Agile approach.

Bell and Thayer’s paper discusses a change in approach from a bottom-up to a top-down in the development of software requirements, referencing the adoption of this approach in MIL STD 490/483 (MIL STD 490 discusses specifications practices and MIL STD 483 discusses Configuration Management Practices for Systems). The paper is mainly concerned with examining the approaches empirically to determine which works best. Ultimately, the paper declares that “over the last ten years more structure and discipline has been adopted, and practitioners have concluded that a top-down approach is superior to the bottom-up approach of the past.” The term “waterfall” is used in direct reference to Winston Royce’s paper.

Despite the flaws described by Royce, Waterfall became a preferred method in 1985 when the Department of Defence issued DOD-STD-2167A, Defense Systems Software Development. It described the software development cycle as follows:

  1. Software Requirements Analysis
  2. Preliminary Design
  3. Detailed Design
  4. Coding and Unit Testing
  5. Computer Software Component (CSC) Integration and Testing
  6. CSCI Testing

The forward states that “this standard is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software acquisition program.” However, the requirement was laid out in black and white and followed religiously.

The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.

Benefits of the Waterfall Model

For all the criticism of Waterfall, there are some real benefits to its implementation:

Drawbacks of the Waterfall Model

Here are some of the top concerns and criticisms of Waterfall:

Comparing Waterfall to Agile

Waterfall focuses on the design phase of a project, while Agile involves minimal time in design. Both product development options aim to deliver working software, but Waterfall projects typically deliver a release once or twice a year (or even less often) while Agile can deliver working software as frequently as once a week. The deliveries in Waterfall can be large and require a lengthy period of testing, with many companies also using customers to provide Beta testing. Agile tests software as it is built, with the developer often performing the tests.

A significant difference between Waterfall and Agile is that Waterfall is a methodology, but Agile is a “movement” with a variety of derivative methods that apply the principles and values of Agile. Scrum, eXtreme Programming (XP), Kanban, Scrumban, and a number of other methods allow the development team options, so there may be a best choice among them.

An Agile methodology is a superior choice when the client is uncertain about requirements or wants to be closely involved in the development process, and if timelines are short and they want rapid delivery. Waterfall is superior if there are complex dependencies, but Agile is preferable when dependencies are minimal. Agile is also best if speed is more important than quality.

Some drawbacks of Agile are:

The idea that Agile is a dramatic departure from Waterfall is not entirely true. The Agile approach is actually more of an adjusted Waterfall approach, an attempt to address some of the drawbacks of Waterfall in terms of resistance to change and long delivery dates. The lack of flexibility and high rate of cancelled projects has caused many teams to switch from Waterfall to Agile. However, it is important to understand that Agile still takes a sequential approach - it just uses a shorter sequence. Agile still includes some requirements analysis and design at the beginning, but coding does not start until the requirements and design are completed, and you cannot test code that has not been written or deliver code that has not been tested and integrated. Therefore, Agile can be thought of as a more flexible, rapid form of the Waterfall Model.

When to Use Waterfall Method for Product Development

Deciding between Waterfall and Agile comes down to examining the characteristics of the project and the needs of the customer. In particular, pay close attention to the requirements, the goal, and the objective of the project. Waterfall is often a better choice when:

Preparing  project

A Brief Look at the Top Methodologies

Waterfall is just one of many competing product development and project management methodologies. When making the decision to implement one or the other, it helps to have an idea what they are. The following is a brief look at the top methodologies currently in use.


The Waterfall methodology is generally regarded as a traditional approach to product development. Waterfall was based on the notion of everything happening in sequence, with one phase of a project ending before another beginning. This created many dependencies and also resulted in some fairly disastrous situations for software development. Projects were often behind schedule and over budget, and in some cases completely cancelled when the technology changed too rapidly.

Critical Path Method (CPM)

The Crtical Path Method (CPM) method is another sequential method that assumes each step is dependent on the previous step’s completion. The planning phase of a CPM project is more about identifying the most resource intensive portions of the project in order to allocate resources and avoid bottlenecks. Application of the method is done by:

Critical Chain Project Management (CCPM)

Waterfall focuses on design and CPM focuses on tasks, but Critical Chain Project Management (CCPM) focuses on resources and resource allocation. CCPM concentrates on the factors that may affect timelines, costs, performance, and the risk of under-delivery. CCPM’s approach is to define the critical chain, apply resources that can do the most good, and finally introduce time buffers to the critical tasks in order to ensure timely delivery if problems do arise.


The PMI/PMBOK method of project management applies the PMI’s five process groups from the Guide to Project Management Body of Knowledge. Here is a high-level overview of these groups:

Agile Methodologies

Agile is defined as a movement, not a methodology, but a family of Agile methodologies have been developed in accord with the Agile values and principles.


The Scrum method has a small Agile team headed by a Scrum Master. The Scrum Master’s role is to facilitate the work of the team. Planning is minimal and a list is created of the tasks to be worked. Tasks are worked in “Sprints,” which are typically two to four weeks long. Brief daily meetings (called Daily Scrums) are held to go over the day’s tasks and identify obstacles. Team members perform all of the traditional tasks of a project, designing as they go and testing as they complete a task. The goal of the Scrum is to hand over working software. When one Sprint ends, the next begins, with the team drawing a set of tasks from the project backlog. When the overall project objectives have been met and there are no more tasks, the project is complete.


The Kanban method is most suited for maintenance projects. The core of the Kanban method is the Kanban board, a list of all tasks (also called Kanban cards) to be performed that is continuously updated and is easily visible to all team members. When a resource (team member) becomes available, that team member takes a task from the board and works on it. Tasks are added to the board and worked on continuously. There is no defined beginning or ending to the project.

Commitment-Based Project Management (CBPM)

Commitment-Based Project Management (CBPM) is an Agile project management method that can be applied in any project environment. With CBPM, instead of working on a Sprint timetable, which may be unrealistic for the delivery of working hardware features, the team members each make a personal commitment to develop one hardware feature by a specific date. The team meets regularly, for accountability that they are on target. Progress reviews, with any corrections needed, take place at regular intervals. If hardware production falls behind, re-planning occurs to address any roadblocks and implement changes to get things back on track.

Both Scrum and CBPM are team-oriented approaches, and can improve communication both internally among team members, and with the Product Owners (team member who represents the stakeholders, ensuring that development create the features they want). While the Scrum master (development facilitator) will assign hours to Sprints for software development, the individual hardware team members will define the work that they must complete to meet their commitment by the time they specify, using Performance Against Commitment (PAC) charts to show progress.

Both methods allow Product Owners and end users high visibility into how things are going, and where things are going next. Problems that arise can be addressed quickly. With CBPM, the emphasis is on delivery of at least a component or piece of the hardware that works, in order to allow the development or testing of the software that will work on it. This is very different from waterfall, where the entire hardware must all be built first. While Scrum for software is based upon two to four-week Sprints with small portions of the software completed at a time, hardware development requires a different approach.

Extreme Programming (XP)

In Extreme Programming (XP) sprints are usually one week in length with many iterations. In XP, change is the key, and XP programmers work closely with stakeholders. XP is ideal for environments where the requirements are constantly changing. Tasks can be replaced in mid-Sprint.

Adaptive Project Framework (APF)

Adaptive Project Framework (APF) assumes that IT projects vary so widely, no one approach ever makes sense. IT projects differ in risk, cost, length, and complexity and often involve uncertainty in market, business value, customer involvement, and objectives. An APF project therefore starts with analysis of the requirements to define strategic goals. The project is executed iteratively and post-mortems are performed after iterations in order to improve the process. Analysis is usually ongoing, so that the entire project can be redefined or adapted as it proceeds in response to the uncertainty issues in order to maintain or increase business value.


Lean is intended to reduce waste and maximize value. The core values of Lean are continuous incremental improvement and respect for people. Lean focuses on delivering the most value to the customer, maintaining the flow, allocating the work evenly, and most of all, eliminating waste.

Six Sigma

Six Sigma is all about eliminating defects in development through efficient processes and continuous improvement of processes. A rating of Six Sigma means the product is 99.99966% free of defects. When you have a process with a Six Sigma rating, it means that every product delivered via those products can be expected to achieve the same result.

Lean Six Sigma

Lean Six Sigma attempts to combine the Lean and Six Sigma approaches, eliminating waste to make processes more efficient and delivering high value and low defects to the customer.

Process-Based Project Management

In Process-Based Project Management, the focus is on aligning each project with the corporate mission and values. Projects are subsumed in the corporate strategy. Consequently, such traditional aspects of project analysis, such as metrics, are used to determine how closely that objective is met.


The PRINCE2 method is based on the less successful PRINCE method. The PRINCE Method was not widely adopted because it was too cumbersome, and was revised in 1996 into PRINCE2 by a committee comprised of 150 European organizations. While PRINCE was intended to reduce IT cost and time overruns, it was also developed as a project management methodology for any type of project. PRINCE2 issued a major revision in 2009 which made the method simpler and introduced seven basic principles of project success.

Project Integrating Sustainable Methods (PRiSM)

PRiSM focuses on socially responsible project management. Its intent is to manage projects while reducing negative impacts on the environment and promoting socially beneficial projects.

Benefits Realisation

The Benefits Realisation method is all about the customer. From beginning to end, the method seeks to ensure that the customer derives maximum benefit from the deliverable above and beyond cost and timeline.

Many Project Methods Equal Many Opportunities

There are many methods in the world of project management and execution. Most have grown around new approaches and varying needs that only became apparent as the software industry became both more complex (variety of methods and languages) and also easier (increased ease of writing code). The old methods, however, still retain their value in the right environments, as is evidenced by the companies that still develop projects under the Waterfall method. Many customers still want to know what it will cost and when it will be done before they agree to development, and they also still want to know what will be in it. Without that vital information, how would they know if the deliverable has any business value?

These articles were originally published by SmartSheet.com
Copyright 2018 © SmartSheet.com
10500 NE 8th St, Suite 1300, Bellevue, WA 98004-4357 USA