When to use Waterfall

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:

  • It is a simple, straight-forward approach.
  • It is easy to develop a plan for managing a Waterfall project since every phase has a start and end, and you know prior to coding what is to be developed, when it is due, when testing is to begin, etc.
  • The early planning provides a good basis for designing components that integrate with external systems.
  • It is easy to plan resources for Waterfall because, again, you know when everything is to start and end.
  • Clients who want definitive beginning and ending dates can find Waterfall reassuring. Customers can be told the date when they will have a product in their hands and, if the project is right for a Waterfall approach, it is delivered on that date.
  • The cost of development can be determined in advance.
  • Detailed procedures can be used to regulate every part of the process.
  • The design-heavy approach of Waterfall forces a disciplined approach to development and makes expectations clear.
  • Team members can participate in other projects before their phase begins or after their phase ends, returning to the project as needed.
  • The reliance on design documentation reduces stress from developer turnover.
  • The design-heavy approach means errors can be spotted in the design phase. There are obvious pitfalls to this and anyone who has worked with the Waterfall method knows that design errors occur, but take an experienced team and put together a plan and you will often get a solid design that can be executed according to plan.

Drawbacks of the Waterfall Model

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

  • Time to release is exceptionally lengthy for large projects. Royce’s paper was kind to Waterfall when it came to small, internal projects, but regarded it as quite flawed for larger, more complex projects. In fact, this is probably the primary reason Agile has become so popular. Projects that were too large were cancelled before they could reach completion via the Waterfall method.
  • The second leading criticism of Waterfall is that change is unwelcome. Once testing begins, it is extremely expensive to return to development or to redesign the project. The design must be carefully and correctly written before going too far.
  • Working software doesn’t appear until late in the project.
  • Bugs written early in the project can create big headaches for later code, but none of that becomes apparent until testing begins, which makes fixing the code expensive and time consuming.
  • It is not an object-oriented approach. Waterfall projects are highly integrated. This is another aspect of Waterfall that reduces flexibility.
  • It is not a good method for maintenance and other types of long-term projects.
  • Hand-in-hand with the preceding criticisms is the fact that customers often don’t know what they want before the project begins.
  • If the team is inexperienced or entering uncharted waters, obstacles appear that create jeopardies for the project.
  • Testing may be short-changed in order to stay on schedule, which leaves bugs to be discovered by the customer after the product is delivered.
  • Events may force the entire project to be scrapped. For example, changes in the industry that occur during the development phase could render the entire project obsolete. Another event may be the discovery of a design flaw so severe that the whole project has to go back for redesign, which can be so costly the customer rejects the project.

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:

  • Requires customer involvement
  • Costs and timelines are uncertain
  • Planning is difficult
  • Lack of clarity about final result
  • Minimal documentation
  • Team members must be cross functional – some who are inexperienced in unfamiliar roles
  • Developers are dedicated to a single project
  • Scope creep is a risk – as a project welcomes change it can grow out of control and run past its due date

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:

  • The requirements are well understood and not likely to change.
  • The customer is not prone to demanding changes.
  • The customer prefers not to be involved in the development, but wants to be consulted at the beginning and receive a working package at the end of the project. Agile works best when the customer is involved in all phases (reviewing the product at each iteration), but Waterfall customers need only receive a release and install it. (Note: this is a simplification. Customers also must be educated in using the system and that can be a lengthy and important step. This is the same regardless of the method used, and it may be that educating users once or twice a year on new features for a larger release is less intrusive than educating a customer monthly or even weekly on a smaller set of features. Also, bear in mind that customers who want to be involved can be in a Waterfall-based project. Having the customer in for frequent reviews can be distracting and may lead to unwanted change requests, but it can also keep the project focused on meeting customer needs.)
  • The project is small.
  • Speed of delivery is not important.
  • The delivery is to be applied to a legacy system that is not prone to change.
  • You will have similar projects in the future, allowing reuse of the project plan and can glean lessons from the heavy documentation of the previous project.
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:

  • Identifying required tasks and defining the sequence for completing them.
  • Defining the dependencies for required tasks.
  • Determining the relationships that are and are not critical between tasks.
  • Schedule the expected timeline for each task.
  • Develop a Plan B for critical paths.

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:

  • Initiating – Set the vision. This is also the process group in which the project manager is selected.
  • Planning – Set the scope. The PMBOK describes 24 processes in the Planning stage.
  • Executing – Put the plan into action.
  • Monitoring and Controlling – This occurs during the entire project and is not a sequential phase that waits on another phase to end.
  • Closing – Occurs when the customer agrees to accept the project.

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