Agile vs. Waterfall: A Leadership Guide to Choosing in 2019

The differences between types of software are vast. One application might be built to control a vehicle in space. Another might integrate two systems to add business value to a partnership. Then there are popular consumer brands that support multiple platforms. Since software varies so widely, the process of building it varies widely too.

In this post, we’ll compare two popular approaches to building software: waterfall and agile. Waterfall is a process model, while agile is a set of values. Several processes seek to uphold agile values, so let’s take a look at how they stack up. We’ll give waterfall the honor of going first since it has seniority in the software realm.


The major phases are as follows:

  1. Inception
  2. Elaboration
  3. Construction
  4. Transition

These phases are laid out in the COCOMO II or constructive cost model. COCOMO II can be used to roughly understand the distribution of effort between phases. The toughest part is getting the parameters right.

You’ll often see these four phases of the software life cycle broken down even further:

  1. Requirements
  2. Plan
  3. Design
  4. Implement
  5. Verify/Test
  6. Deploy
  7. Operate/Maintain
  8. Retire

There are approval gates between phases. For example, between the plan and design phase, you might do a financial analysis to evaluate the return on the project. And the project might not make it past this point.

This is the basic waterfall process, and many projects will take on this model — including non-software projects. Therefore, it’s the easiest to integrate into standard management models.


Comparison by Phase


Planning an agile project is different. This phase isn’t as critical because delivery happens gradually instead of in one lump at the end. The agile team will deliver value in the first few weeks. That’s not to say the whole product will be delivered that quickly; it may still take months or even years to complete. But the team will deliver working software with added value every two weeks or less. This goes on until enough value is delivered to satisfy the customer.

Feasible projects move past the planning phase. So if one has made it to this point, that means the projected return is worth the estimated cost. Most approved projects will then go into a design phase.


In waterfall, design is a big effort. The details are specified in a way that can be handed off to the implementation team. The architect(s) will create UML diagrams and other documents that show the developers how to build the system. These are like the blueprints and plans for a building project.

Agile doesn’t use “big design up front” (BDUF). Some design is needed, but often things will change over the life of a project. In these cases, detailed design isn’t worth the effort. Instead, agile does more “just in time” or JIT design. This is best done by skilled developers who understand how to make the right choices.

With a detailed or general design in place, it’s time to start implementation.


In waterfall, the implementation team pieces together the design that was handed off to them. In theory, they just need to code whatever was designed. Developers must be able to read and interpret the plans. Some software can automatically write code directly from design diagrams. While it’s possible to get working software this way, it doesn’t always result in optimal performance.

The agile method is highly tuned for implementation. Because the agile team will deliver working software every two weeks or less, agile succeeds when it’s possible to get feedback from the customer quickly. The customer is a specific role on the team — someone who can speak for the business and for users. So this person will make decisions about what’s needed. As you can imagine, collaboration is highly valued in agile, so daily interaction between the customer and the team is important — especially when the needs of the business are constantly changing.

The next phase of waterfall is about testing. Agile approaches this as part of the implementation phase, but hybrid processes often include a verification step. It’s really all about how the customer is willing and able to interact with the team.


This phase often leads to a reworking of the design, and sometimes the team has to go back to the drawing board. This is the first time the customer will see the product, and in some cases, they won’t see it until delivery. By now, the waterfall process has been through implementation. The majority of the cost has already accrued. So additional costs can really start to stack up during verification. After production, this is the second most expensive phase to fix any defects. These facts exemplify the need for careful design in a waterfall project.

Agile projects have a shorter cycle between design and verification. Often it’s done in real time. At minimum, it should be done every two to three weeks. Defects in an agile project aren’t as expensive to resolve at this point. Close collaboration and short cycles keep those costs down.


Consider a product that’s expensive or impossible to change after deployment. For instance, it’s nearly impossible to change a Mars rover once it’s been launched into space. But even some terrestrial applications, such as an HR or billing system, come with a high cost of change. It’s expensive and time-consuming to update a core system. So if a system is on-premises software, your delivery mechanism choices may be limited.

On the other end of the spectrum, consider a product like Facebook. It has millions of users, and the applications are web or mobile. The delivery mechanism is quick. In fact, Facebook delivers multiple times every hour. It has mechanisms to support continuous deployment. It can be more agile and often tests during production because Facebook can roll back as easily as it can release.

Waterfall isn’t always the wrong choice. Agile isn’t either. It all depends on the situation. The delivery mechanism is one factor that can help you determine the appropriate model to use.

Overall Comparison

When you look at the two side by side, it’s easy to see just how different they are — and how each provides value in its own way. Organizational structure and the delivery mechanism will have a lot to do with the choice you make. So will your teams’ skills and the availability of the customer.

In either model, larger projects are more prone to slippage since there’s more that could go wrong. What can you do to combat this?

The Bottom Line

Still, no matter which style you determine is the most appropriate for your project, there will be a large degree of unpredictability throughout the life of it. Measuring the flow through the value stream will help you identify any bottlenecks and resource contention, two things that can cause delays and increase costs. So be sure to map and measure your value stream continuously to detect bottlenecks, balance resources, and improve predictability.

Learn more about Value Stream Management

Learn how to improve the speed, quality, and visibility of your software delivery.