Agile vs Waterfall: A Leadership Guide to Choosing in 2021

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.

Waterfall

With a waterfall process, there are four major phases with gates in between. Specialists in their respective departments perform the work in each phase, and then the work is handed off sequentially from one department to the next.

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.

Agile

On the other hand, agile isn’t a process. Agile, according to the original manifesto, is a set of values and principles that result in better ways of developing software. It doesn’t solve for project planning or capital budgeting. It doesn’t account for operations or maintenance. No, agile is about building software. Its value is derived from collaboration combined with early and continuous delivery.

Comparison by Phase

Since agile is about building software and not planning software projects, we will collapse our comparison. It’s fair to say the customer (company) already has an idea about what it wants when it starts building software. You wouldn’t, for example, hire a software team and say, “OK, now figure out what problems you’re going to solve.” Businesses generally don’t do that—so let’s start with planning.

Plan

Planning is a critical step in the waterfall process. It’s the part when the cost of the project is determined, which can make or break the next few years. So it requires skilled and experienced practitioners to be effective. Software estimation and budgeting is not an easy exercise! Once the project is underway, the scope and budget are fixed. The product will be delivered in its entirety once the project is done, and that could be months or years in the future.

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.

Design

When we say “design,” we aren’t just talking about visual design. There are many technical details that go into the design of a software system. And project success is highly dependent on good design.

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.

Implement

Once the designs are made—and this part can take some time—it’s off to the developers or engineers for 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.

Verify

The verification phase of a waterfall project happens after implementation is complete. QA engineers will do their best to shake out any bugs and other defects in the application. User acceptance also happens during this phase. Customers must try the system for themselves in order to sign off on the delivery.

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.

Deploy

Deployment is one of the most important factors in determining which model to use. Some products are best deployed all at once and with a fixed scope. Waterfall and agile differ greatly in how they handle scope. With waterfall, the scope needs to be mostly fixed. But agile methods handle a flexible scope, and the deployment mechanism matters a lot.

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

Let’s take a closer look at some comparisons between waterfall and agile:

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

It’s important to observe how the work flows through the system you’ve chosen. And that starts with value stream mapping, which is basically what we’ve seen in this post. We’ve effectively mapped the value stream between the waterfall and agile processes.

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.