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 execution phase 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 […]

  20. […] Bowes. 2014. Agile vs Waterfall: Comparing project management methods. [Accessed 31 March […]

  21. Pia Krogh says:

    Great introduction – I am on a “what every body knows” level when it comes to agile project management. Not that I have anything against this logical approach just never – before right now – had the chance.

    Realy looking forward to be more experienced in this.

  22. Andy says:

    A good article. Just a small point. I noticed that in the heading of the article, you refer to Agile and Waterfall as “Project Management Methods”, when in fact you correctly define both approaches as software development methods. Hence the title is incorrect.

  23. Yahya says:

    Thanks for the article, I enjoyed reading it.

    My field isn’t in software development, It’s in the implementation of low current systems. In our company, it has always been Waterfall approaches, in all type of project with an emphasis in a pile of documentation, of progress, financial and forecast reports.

    It has only been a few months now since I started to experiment with an Agile approach in one of my projects. Though it was a challenge at the beginning, now, to my surprise it’s going great, we have been delivering valued work to our client so frequently.

    It all comes to the project type and how to best approach it, either with Agile or Waterfall

  24. Bob McCalley says:

    Informative article weighing the Pros / Cons for each methodology. Having had the opportunity in my IT Career to have worked using both the Waterfall and Agile methodologies. I would choose Agile over Waterfall. It is more flexible to change as the project progresses, improves time to market, meets expectations of the business and delivers a quality product.

  25. Paul says:

    Nice summary.
    I’ve read a lot of materials about agile, lean, kanban etc. and I can see that sometimes there is no clear distinction between different terms. Maybe I don’t get it right. 🙂
    However, I think that Kanban is more of a Lean methodology, even though it is agiler than most agile methodologies. After all, it is one of the main pillars of Lean. Anyway, I think that teams (not only Dev) use kanban software solutions more and more because they are really adaptive and flexible.
    I totally agree with people who think that Agile is better than Waterfall. Plus I don’t think that waterfall is easier to understand and this is a pro. If you are clever enough (regular level, not even “wow”smart) 🙂 you should be able to understand Agile.
    Nice work.

  26. Celina says:

    Dear all,

    can someone explain to me why the pie chart is saying 23 % accelerate time to market and 16 % manage changing priorities and 15 % better align IT / Business Objectives ? Why isn’t it all adding up to 100 % ?

    Thank you very much !
    Best regards,

  27. […] Bowes, Jim. “Agile vs Waterfall – Comparing Project Management Methods.” Manifesto, Manifesto, 17 July 2014, from https://manifesto.co.uk/agile-vs-waterfall-comparing-project-management-methodologies/ […]

  28. […] is your own management style? If you prefer fixed costs, deadlines, and a linear thought process, then waterfall is a more comfortable methodology for you to lead. Agile can be “fuzzy,” and […]

  29. […] rather than a group of HR professionals taking the traditional tack of working out a project plan and rolling it out a year later using the waterfall method, in this instance, a mixed team of HR professionals and people from across the business worked […]

  30. boi says:

    10/10 would read again, very good article

  31. Mathu says:

    Very good explanation about agile Vs Waterfall

  32. Shamla Sajuvan says:

    Very good explanation.

  33. […] Designing a customer experience is a complicated undertaking. In the history of humankind how we organize, conduct, and complete complex projects has a been a source of interest, study, and refinement for the better part of 4 millennia. Surely the great pyramids were not done by shooting from the hip. Plans were drawn up. Architectural and mathematical principles were applied. Workflows and schedules were introduced. Workers were conscripted. Hookahs were smoked. One might expect a very rational linear process. However, a review of history would argue that a pure linear process is not the source of humanity’s greatest accomplishments.  Course corrections are often made on the way.  Scrapping a large part of what was done or even “rebooting” completely happens often. The scientists at Los Alamos in 1943 had a rough ‘plan’ to start with but was revisited when things did not work out as expected.  An intellectual punt on the concept of compression yielded the birth of nuclear fusion which in turn brought World War II to a close. Phew! As Albert Einstein said “If we knew what we were doing, it wouldn’t be called research.” It turns out that controlled chaos is good for humanity. The learnings are this: if we are overly strict and structured we fail to innovate, barreling down a predefined path and not looking up.   If we have no structure and guiding princples, we just iterate aimlessly like a wind up toy bouncing across the table that eventually vibrates off the surface crashing to the floor. These two approaches are book ends on a continuum that can be found in everything from the fine arts to the physical sciences.  Somewhat ironically, no more apparent is this creative control-chaos tension than in the world of software application development with the move from “waterfall” to “agile” approaches. […]

Sign up for the Manifesto newsletter and exclusive event invites