Where I lecture, I was always taught to use waterfall to manage projects, but when I finished college, waterfall wasn't the only method that can be used for project management, and I am very interested in Scrum.

My question: when (for what kind of projects) it's better to use waterfall, and when it's better to use Scrum?

  • 1
    Take a look at "The New Methodology" by Martin Fowler.
    – Be.St.
    Commented Dec 22, 2011 at 15:16
  • 13
    "Pure" waterfall is suitable for repeatable, knowable processes like manufacturing. Use any practice with efficient feedback loops when you can't measure everything upfront.
    – Todd A. Jacobs
    Commented Jul 13, 2012 at 13:20
  • @ToddA.Jacobs while waterfall can work in manufacturing. Manufacturing is going Lean (agile). A better example it motorway/freeway repair. Where they only have one lane, and they have to get the lorries/trucks to arrive on time, in order. There will be a lot of planning, and little opportunity to adapt. Commented Mar 30, 2019 at 10:14

14 Answers 14


First of all, it isn't an either-or type of problem. You will find pure implementations of both approaches (pure waterfall being rather rare these days) as well as a mixture of both approaches or some of this, some of that and much of chaos.

Then it would be better to discuss heavy-weight formal approaches versus light-weight agile approaches, than waterfall versus Scrum as they are just specific cases.

You may want to use formal approaches when:

  • You work for a big client who enforces a very formal approach on vendors.

  • You work on fixed-scope, fixed-price contracts and client doesn't expect (for any reasons) rapid change in the scope.

  • You project team is experienced with specific heavy-weight approach - they know how to deal with it, they know how to use it to deliver a high-quality project.

You should consider agile approach when:

  • You work on in-house projects or projects for more flexible clients where you don't have to adjust to client's processes.

  • You work on a project where the scope is changing rapidly (for whatever reason) and you tend to accept the fact.

  • Your team isn't fluent in any specific project management approach as generally agile methods make learning curves pretty smooth in terms of introducing best practices.

Having said that, feel free to mix different approaches - whatever works for the team and for the project can be and should be used. You don't get points for being orthodox with any specific approach - you get points for delivering projects.

As a piece of final advice, it's better to use potentially worse methods (where worse means one which doesn't suit so well to your specific project environment) but use it well, than use potentially best methods but screw up its implementation. See: Good waterfall is better than bad agile

  • I am not sure if I agree to potentially use the "worse" method if it is used well. I think most teams fail in agile approaches, because they pick the wrong methodology for a given project. The right approach often dictates if you are able to use it well or not. See this blog post for more info. Commented Nov 10, 2015 at 18:29
  • 3
    this is an old post, but I down-voted this answer because it seems to suggest that the two approaches are equally valid. The earliest discussion of waterfall was by Winston Royce as a description of WHAT NOT TO DO in software PM. Somehow that is has been forgotten. I have problems with "agile" and the Agile Movement as an industry, but waterfall is not an equally valid methodology. en.wikipedia.org/wiki/Waterfall_model#History
    – fregas
    Commented Nov 16, 2015 at 18:36
  • It could be useful to add Fig. 3.3 from The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP Commented Jan 15, 2018 at 19:54

Use Agile (Scrum, XP, Kanban) when:

  • you want to benefit from fast feedback and burning visibility of objective data
  • you don't completely understand the value and definition of what you are building
  • your payoff/downside curves could vary widely
  • have a team passionate about it or a coach who will help them
  • have complicated project without all the experts you need or a complex project

Use Waterfall when:

  • the project is simple
  • the project is complicated, but you have the expertise to deliver it
  • it is all you know and you have no support for change
  • the upfront investment is not risky to make
  • you focus your performance measures on delivery date and budget

Great post by Dean Leffingwell on same topic - TAKE THE QUIZ - Picking Agile vs. Waterfall “Projects”: a Ten Point Quiz.

  • Link fixed, thanks @Adam-Wuerl
    – Lunivore
    Commented Apr 25, 2012 at 15:57
  • The link is not working. Commented Feb 28, 2016 at 0:55
  • 2
    I will say use waterfall only if the requirements are fully clearly defined and can not change over the period of project. But noways you will find it very rarely.
    – Amol Patil
    Commented Dec 2, 2019 at 14:00

You shouldn't use waterfall for anything but the simplest of projects, which effectively excludes about 90% of all software projects. Why? Because software projects are complex on three dimensions: Requirements, Technology and People.

To illustrate, this is a Stacey Graph, developed by Ralph Stacey of the University of Hertfordshire in the 1980s - he studied complexity and human behaviours in organizations and businesses and how to adapt management practices to counteract its effects. I've adapted it based on the graph that Ken Schwaber uses in his Scrum books and classes:

Stacey Graph

Waterfall projects fit into scenarios that map into the simple zones on the graph where we have almost perfect understanding of our customer's requirements and the technology(ies) we need to use to implement them into a working software solution along with a small team size 1-3. As you might guess, these scenarios are few.

Typical software projects, however, tend to reside in the complex area in the middle of the graph where requirements run along a continuum where they are not entirely understood or agreed upon (because they've yet to be implemented) and the technologies required run along a similar continuum where we're not 100% certain about how they work.

So far, this is the good news. We can deal with "complex" projects. However, what pushes complexity into the zone of anarchy is when we add people and put them into a highly-creative process like a software project where they need to collaborate to deal with the aforemention ambiguities. Waterfall methodologies, which enforce following a rigid plan over responding to change (within and outside the project), exacerbate this tension and contribute to failure.

In these situations (ie. 90%+ of the time) you need to use an iterative/incremental process to contain the complexity and mitigate risk exposure within a defined time box (the iteration or sprint) so that you can continually inspect and adapt the solution according to the realities of requirements + technology + people.

  • 1
    Checking in here way too late, just wanted to add my two cents that this is by far the best answer Commented Dec 8, 2013 at 14:04
  • Hi Chris, can you confirm that you are the author of the above image? Someone shared it with me and I’d like to attribute its authorship properly. Thanks!
    – Avi Flax
    Commented Nov 13, 2017 at 15:38
  • Hi Avi; Yes, I made the picture above, but it is based on a reinterpretation of the Stacey Graph I first observed from Ken Schwaber over a decade ago. Commented Nov 13, 2017 at 19:16

You have three factors:

  • Money
  • Time
  • Requirements

If money and time are fixed and requirements can change then you would go after SCRUM.

If requirements are fixed then you would go after waterfall.

  • 2
    Nutshell. This answer is in it. Regardless of whatever other voodoo people try and type to sell their favoured solution. Nicely put Jakub. Commented Sep 14, 2014 at 0:17

Will the software ever change after its first release?

Waterfall is for building bridges and houses -- physical, rigid things that you don't expect to change much over time.

Agile and Iterative approaches fit naturally with software development and its fluidity.

You should expect and embrace change.

I understand not everyone agrees with this, but using a Waterfall process is #1 on my post about the top 5 software project management mistakes.

It surprises me that Waterfall software development is still taught and practiced so widely after all these years.


Waterfall should be used when required by the customer or regulators. Not that I know of any regulators that require it.

Otherwise its original paper had it as a straw man to be knocked down; then people took it as a good practice.


There are a number of factors to consider.

For example, the scope of the project, the length of the engagement, the type of engagement (whether you'll be involved in the full lifecycle of the project or only development), the client's past experience and what will work best for you and your team.

Here is a post on picking a pm methodology that might be helpful.

  • Great article, Mark!
    – Tiago Cardoso
    Commented Dec 26, 2011 at 16:00

"Waterfall" is far superior when the customer knows exactly what they want and nothing changes other than bug fixes. It gets a lot of discredit because the vast majority of customers don't know what they want, so iterative processes are far more effective at finding out just what those customers want - and giving it to them.

  • 1
    I agree that it works when the customer is able to accurately define all requirements upfront, but on what basis do you claim it's "superior?"
    – Todd A. Jacobs
    Commented Jul 14, 2012 at 13:18
  • I imagine the same basis that Agile/Scrum purists claim the same about their methodology. A mix of experience, bias and preference. I also prefer waterfall - when you are investing shareholder value at £1500 per second then it pays to have a methodology that is controlled tightly and is in line with regulatory and auditing frameworks. the minute you ask a Scrum team for legally required documentation they whine about the "principles." Commented Sep 14, 2014 at 0:16

Bother the development methodology has its own benefits and limitations. So it completely depends on you which way you would like to move or hybrid of both to redefine the development methodology. Waterfall model is still good for developing many big projects, that have all the steps clearly defined initially. Agile development is being adopted these days but has not superseded Waterfall model that helps to develop a project with clear project steps defined and there is no need to go back.


The waterfall is perfect for projects in which all the requirements are known in advance, up to the smallest detail and do not change and the entire design can be done up front without getting anything wrong and there is no need to test anything until the end, because the tests are just a formality and won't require changes.

The problem is that this can never happen, especially with large projects, or projects that have new aspects to them (from the point of view of either the clients or the implementers).

Even when manufacturing the same product over and over in an existing manufacturing chain, mechanical, electrical and human errors can cause faults and these faults are best detected and corrected as soon as possible.

Most companies that officially practice waterfall use some sort of incremental, or more realistically, iterative method behind the scenes.

The questions are:

  1. Do they use a formal iterative method, such as UP, Scrum, Kanban and etc, or do they make it up as they go along.

  2. Do contracts have to be renegotiated after every need for change comes up, or does the contract already specify control points for changes or halting the project.

If the uncertainty (in requirements, technology, staff and etc) is large, then agile methods can lead to a more efficient process than larger iterations (e.g. UP).


From experiencd of using both, to be honest there is no real advantage of using waterfall unless the project is so small that it fits within a short time period eg. One month. Scrum actually repeats mini waterfall phases in each sprint anyway. The value of Scrum is that no time is wasted doing big upfront Analysis and Design while priorities and market conditions are changing. There is an overview [here] (http://www.pashunconsulting.co.uk/what_is_scrum_blog.html)

  • ...so you think a Scrum Team can deploy an entire SAP environment? That's strange since SAP themselves and SAP Gold Partners don't recommend a Scrum approach. Commented Sep 14, 2014 at 0:18
  • @Venture2099 Whether or not the poster's answer is correct, your counterargument is a logical fallacy known as an "appeal to authority." The tone is also borderline snarky; please try to be polite to other members of the community.
    – Todd A. Jacobs
    Commented Sep 18, 2014 at 20:26
  • 1. It is not an appeal to authority. The OP made a blanket statement regarding waterfall, in order to disprove I only need to find one example. I did, and the example is backed up by industry-leading advice. Furthermore, appeal to authority is not a logical fallacy, it only becomes a fallacy when misused. web.stanford.edu/~jonahw/PWR1/LogicalFallacies.htm has the three misuses of appeal to authority. The appeal itself is absolutely not a fallacy. Experts can be wrong but when weighed equally against non-experts, they are most often correct. Snarky? Guilty. But OP is dismissive. Commented Sep 21, 2014 at 22:51

Scrum methodology requires a change in mindset from traditional methods. The central focus has moved from scope in Waterfall methods to achieving maximum business value in Scrum. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Scrum, quality and constraints can be altered to achieve the main objective of attaining maximum business value.

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling. Changing requirements from customers have led to an increased pressure on businesses to adapt and change their delivery methods.

For more please visit: http://www.scrumstudy.com/blog/advantages-of-using-scrum-listed-down-by-scrumstudy-2/


I think Pawel's answer is great and would +1 you if I could!

To add to his list. You would use waterfall where:

  • You have a hostile customer or one that refuses to engage
    • I say this only because it does happen sometimes. The customer doesn't really want change and it's being imposed on them by an owner or group, but they have ownership of the project. Its rare but Agile needs engagement.
  • 1
    I don't see how waterfall helps here, either, unless the goal is CYA. All successful project management requires customer engagement to deliver value.
    – Todd A. Jacobs
    Commented Jul 13, 2012 at 18:24

Waterfall isn't a methodology itself. Waterfall is just a lifecycle model.

Scrum is an agile methodology. A methodology may describe a lifecycle, and provides a process to support that lifecycle.

  • Actually, you are wrong. Waterfall is a methodology.
    – Zsolt
    Commented Jul 13, 2012 at 17:23
  • @Zsolt why didn't you downvote? Commented Jul 13, 2012 at 17:55
  • @Zsolt It's arguable. A model isn't a methodology, but you can certainly build a methodology around a model. Wikipedia says "The waterfall model is a sequential design process..." so I'd probably argue that the methodology is all the PMBOK stuff that implements the model. en.wikipedia.org/wiki/Waterfall_model
    – Todd A. Jacobs
    Commented Jul 13, 2012 at 18:09
  • 2
    @MarkPhillips I was distracted by some good deal from valve ;-)
    – Zsolt
    Commented Jul 13, 2012 at 18:11
  • @CodeGnome, I agree. For me the answer is too generic and less constructive.
    – Zsolt
    Commented Jul 13, 2012 at 18:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.