Agile vs Waterfall: Comparing project management methods

Traditional waterfall methods for developing software are rapidly declining in popularity as more recently developed Agile methodologies are increasingly adopted. But what’s the difference between the two – and is Agile always better?

What is waterfall?

The waterfall model is one in which each phase of a product’s life cycle takes place in sequence, so that progress flows steadily downwards through these phases like a waterfall.


Nobody invented the waterfall method. Rather it was inherited by enterprise software developers from other industries where, once a particular phase of production is complete (like laying the foundations of a building for example), it was incredibly costly or impractical to go back and make changes. The waterfall was only codified when people subsequently realised that it wasn’t the only way of doing things. (Winston W. Royce is commonly credited with the first formal description in an article from 1970 in which he described a flawed software development model.)

In waterfall methodologies all the requirements gathering and design work is done before any coding takes place.

There are several well known and widely implemented waterfall methodologies that are used on IT projects. These include PRINCE2 which was created by the UK government and remains popular in the UK public sector and PMI PMP which is more internationally recognised.

In general these methodologies have stages that deal with what you need to do before a project, during a start up phase, a planning phase, an executionphase and a closing phase. They also then have a series of processes for managing work packages, exceptions, reporting, risks and issues.

Pros of the waterfall method

  • Potential issues that would have been found during development can be researched and bottomed out during the design phase. If appropriate meaning an alternate solution is selected before any code is written.
  • The development process tends to be better documented since this methodology places greater emphasis on documentation like requirements and design docs. Many organisations find this reassuring.
  • Because the waterfall process is a linear one it is perhaps easier to understand, especially for non-developers or those new to software development. Often teams feel more comfortable with this approach.

Cons of the waterfall method

  • Often the people we’re building software for (the client) don’t know exactly what they need up front and don’t know what’s possible with the technology available. This way of working doesn’t handle this well.
  • Solution designers often aren’t able to foresee problems that will arise out of the implementation of their designs.
  • Changes to requirements (e.g. like those resulting from new technologies, changes in a market or changes to business goals) can’t easily be incorporated with the waterfall method and there are often laborious change control procedures to go through when this happens
  • The process doesn’t have its own momentum

What is agile?

An Agile software development methodology – such as Scrum – is one which eschews a linear, sequential approach in favour of an incremental, iterative one.

Instead of extensive planning and design up front, Agile methodologies allow for changing requirements over time by using cross-functional teams – incorporating planners, designers, developers and testers – which work on successive iterations of the product over fixed time periods (timeboxes). The work is organised in to a backlog that is prioritised in to exact priority order based on business (or user) value.

These teams are self-organising, include a representative of the business (the product owner). The emphasis is on efficient face-to-face communication and short feedback loops.

The goal of each iteration is to produce a working product,, which can be demonstrated to stakeholders. Feedback can then be incorporated into the next or future iterations.agile-project-management

Agile evolved out of a number of different lightweight software philosophies which developed in the 1990s in counterpoint to heavyweight methodologies like waterfall. The Manifesto for Agile software development, written in 2001, shows the emphasis that Agile places on value.

Pros of Agile methods

  • Working software is delivered much more quickly and successive iterations can be delivered frequently, at a consistent pace.
  • There is closer collaboration between developers and the business.
  • Changes to requirements can be incorporated at any point of the process – even late in development.
  • It gives the opportunity for continuous improvement for live systems
  • It is highly transparent

Cons of Agile methods

  • Agile methodologies (e.g. Scrum, XP, Kanban, Crystal etc) are often more difficult to understand than linear, sequential ones – at least initially.
  • Because of the emphasis on working software there can be a perception that documentation can sometimes be neglected. The focus should be on appropriate documentation to the audience that needs it but, if not implemented well, this isn’t always the case.
  • When implemented badly Agile can introduce extra inefficiencies in large organisations or can be working against long standing organisational processes.

When is Agile better than waterfall?

I’m a huge proponent of Agile software methodologies. I believe that technology, businesses and markets change so fast these days that software development needs to be adaptable above all other qualities.

Agile methods are more flexible than the waterfall method which means that customers’ requests are more likely to be met. Even when things change the constant focus on value means what you’ve already delivered should have been worthwhile. And the rhythm that Scrum creates helps build highly motivated teams where productivity increases over time.


The top 3 reasons people choose Agile – from the Version One State of Agile Survey 2013

Having said all that, there are still circumstances in which the waterfall method can be suitable – for example, where requirements are guaranteed to be unchanging and there is very little uncertainty or if the project if very simple – but those circumstances are becoming fewer and farther between.

Also if an organisation and the people involved in the project are not in a mature enough state for Agile it may be more appropriate to use traditional project management methods.

What are your thoughts? Have you tried using Agile – how was it received in your organisation and what challenges did you face?



Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. […] Under the DevOps umbrella resides a number of project management methodologies employed by application engineers. Manifesto, a technology development and management firm based in the United Kingdom, identified two: the "waterfall" and "agile" strategies. […]

  2. Sean says:

    Nice article. It is also worth looking into how Agile IS Waterfall, at least in the sense that the qualities of Waterfall that make it a successful methodology in other areas underpin the common sense that Agile brings to the table.

  3. Jose Huerta says:

    Good article!

    But I disagree in considering PMBOK as a waterfall methodology. PMBOK can be applied to any industry project life-cicle. Waterfall is a lifecycle, and iterations are another lifecycle. Both can be applied using PMBOK.

  4. Jim Bowes says:

    Thanks Jose, I was referring to my experience of the PMI methodology where there are sequential project phases – I know they have created Agile implementations that work within their framework. I work most frequently with Scrum which I consider more a productivity framework than a project management methodology. Outside of that it very much becomes about how can you make Agile work in a scaled/organisational environment. I think that’s still being wrangled with.

  5. Jim Bowes says:

    Sean, thanks for your comment. I see what you’re saying, but for me it’s more about the principles than the specific delivery mechanism.

    It’s believing that customer collaboration, working product, the team self managing are all critical to the the success. If you don’t drive the cultural and interaction change then Agile doesn’t really work. So I think there is more than flipping the delivery.

  6. Colin says:

    I am looking in to agile techniques and wondering if it’s adaptable for maintenance scheduling for a process under going huge change. Has anyone used agile for anything other than software?


  7. Jim Bowes says:

    Hey Colin, We’re seeing more and more teams using Agile techniques outside of software development. Especially in communications and devops teams. For some teams KanBan can work really effectively (where the fixed sprints are too rigid). KanBan is focussed on limiting work in progress and flow – it would be worth looking at whether this could help your organisation. There are also frameworks for scaling Agile that deal with releases such as the Scaled Agile Framework. Hope this helps.

  8. kvu says:

    See this article from CIO.


    And I agreed with most points mentioned in the above CIO article. There must be a management decision before the project starts if it should be agile or traditional. Certainly, agile project is not fit for certain types of projects, vice versa. Traditional waterfall projects can fail, so can agile projects. The reason that we do not know much about how and why agile projects fails because we do not have enough project data to quantify the success ratio for agile projects.

  9. […] In the Agile style, development teams — engineers, designers, project managers, and product managers – work on the project simultaneously, constantly communicating and adapting to finish it quickly. It’s a very agile (hence the name) way of developing products, particularly compared to the traditional Waterfall method in which a product is developed just one step at a time. More on Agile versus Waterfall styles here. […]

  10. […] Agile vs Waterfall: Comparing project management methods, Manifesto […]

  11. […] When the project requires adaptability and constant update, agile is the way to go. This project management methodology is usually best for products related to technology and technological advances, according to Manifesto. […]

  12. Richard Jones says:

    Thank you very much for this simple and succinct explanation.

  13. […] creative space. There are other tools that you can make work with your calendar (such as the Waterfall method for example). It’s up to your team’s preferences how you decide to go about […]

  14. Very nice article! – can also be widened to change management/improvement of business process, not only with software development, but using technology solutions discussion, design, implementation and benefits/achievements review in general

  15. […] Agile vs Waterfall: Comparing project management methods […]

  16. […] Agile development, the way forward is to create a quick design and then build and test it with users. Key […]

  17. […] customer requirements, which would not be easily achievable when applying the waterfall method (see Bowes 2014 for more […]

  18. […] In this way, much like with the inquiry process, there is much more freedom to change direction and follow one’s curiosity and end up with a product truer to the real business’s needs and wants with the agile project management methodology. […]

  19. […] Agile vs Waterfall: Comparing project management methods, Manifesto […]

Sign up for the Manifesto newsletter

News and thoughts on digital, charity, technology and creative