This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.


This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.


Agile vs Waterfall: Introduction

This is the first in a short series of posts that compares agile vs waterfall and how and why iterative agile development can deliver better results than a waterfall development project; and how it gives back control of the project and more importantly budgets to customers.

This first part covers a bit of background about waterfall and iterative agile and compares the iterative approach with the waterfall approach.

In future posts, I'll discuss:

So firstly, what is waterfall and what is iterative development?

What is Waterfall Development?

Before the introduction of waterfall, a lot of software development was ad hoc and chaotic with little process or methodology applied at all. The software industry needed to add rigour and process, so we looked around and found some great techniques from engineering disciplines that would fit nicely into software development.

It was a great leap forward to:

  • have a project plan
  • gather requirements and write a specification
  • architect and build software to the specification and architectural plan
  • use a formal quality assurance process to ensure that the software met the specification

These meant that we could actually deliver what the customer wanted.

It works well for designing and building a civil engineering project, such as building a bridge, and it vastly improved the quality of software delivery.

Waterfall Project Plan

A typical waterfall project follows a plan similar to this one. We start by specifying the requirements and architecting the solution. Then we design the software to fit the architecture and meet the requirements. Next we actually build the software. Then we test it before we finally deliver it. This is all underpinned by project planning.

However, as an industry we've matured. We've welcomed the rigour and discipline that we've drawn from physical engineering. Now though we've seen what can also go wrong with that approach and improved our delivery processes.

Software development, while it does have some parallels with physical engineering, does not have all the same constraints as physical engineering:

1. Software is much easier to change

We can replace whole components and rework software much more easily than we can for example a half-built bridge. Refactoring tools and automated test suites allow us to do this with confidence. A civil engineer can't decide to rip out their foundations and replace them with something better during the project. Software projects can and do allow us to embrace improvements, new ideas and new requirements as the project progresses.

2. Software can be delivered in smaller pieces

Typically a engineering project is either complete or useless. There isn't much point to a half-built bridge.

Unfinished Bridge

(photo taken by mateoutah)

However, with software, a customer can often get significant benefit from only part of the full system, and can gain additional value as more and more of the system is delivered.

3. Software is less repeatable than engineering projects

One of the downsides of software projects are they are often very different from each other. While there are many reusable components available for software projects, each project typically solves a different problem – otherwise it could be an off-the-shelf package.

Civil Engineering lives within physical constraints and while new materials and techniques do come along; many engineering projects have a larger set of known constraints than a software project does. However it is worth noting that when a large engineering project attempts something particularly novel or untried, they do often suffer from similar budget and time overruns as software projects. On the whole though, civil engineering projects do appear to be more amenable to repeatability than software projects.

One of the primary weaknesses of the waterfall approach is that you don't get any benefit or return on investment until the very end of the project when all steps of the process are completed. If the project is running behind schedule (who ever heard of a software project running behind schedule?) there is relatively little you can do bring it back on schedule.

What is Agile and Iterative Delivery?

Knowing about the differences between physical engineering and software development means that we can utilise the best techniques from engineering that are applicable to software projects while also taking advantage of software's flexibility to deliver a better solution.

This is where incremental iterative delivery can bring significant benefits to a software project.

Iterative Project Plan

With this approach, the customer receives incremental releases every iteration, and to be clear these iterations are short, typically we work with one or two weeks iterations; there needs to be an immediacy about the delivery.

Generally, early iterations won't deliver enough functionality for the system to be useful, but each one adds a little increment that builds up over time until we reach a "minimum viable product", that is the minimum set of functionality for which the system is somewhat useful to the customer. It's where the system can be put live and the customer will start to receive some value; but typically short of the full system that the customer envisages.

In the diagram, this is depicted by colour coding the delivery milestones. By iteration six, the milestone has turned green and the customer starts to earn a return on their investment. Each iteration after that just adds more and more useful functionality.

The big benefit of this though comes when we consider what happens if the project is running behind schedule. We don't have to wait until the end. We don't have to increase our budget to cover that last push beyond the original delivery date.

The customer instead has control of when the project has delivered enough. If the project has spent its budget but hasn't delivered everything then the customer can decide if what they already have is enough or if they want to spend more to get the remaining functionality.

In waterfall they don't get that choice. They either have to decide to stop and get a "half-built bridge" that is of little value, or they have to bite the bullet and spend more in the hope that eventually they'll get the finished product.

Next time, I'll discuss requirements gathering on a waterfall and an agile iterative project.