Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?

share|improve this question
    
Take a look at "The New Methodology" by Martin Fowler. –  Be.St. Dec 22 '11 at 15:16
6  
"Pure" waterfall is suitable for repeatable, knowable processes like manufacturing. Use any practice with efficient feedback loops when you can't measure everything upfront. –  CodeGnome Jul 13 '12 at 13:20
add comment

14 Answers 14

up vote 36 down vote accepted

First of all it isn't either-or type of problem. You will find pure implementations of both approaches (pure waterfall being rather rare these days) as well as 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 and they enforces their 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 high-quality project.

Then 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 scope is changing rapidly (for whatever reason) and you tend to accept the fact.

  • Your team isn't fluent with any specific project management approach as generally agile methods make learning curve 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.

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

share|improve this answer
1  
+1 nice answer and nice blog post –  DaveParillo Feb 17 '11 at 22:34
add comment

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.

share|improve this answer
    
Link fixed, thanks @Adam-Wuerl –  Lunivore Apr 25 '12 at 15:57
add comment

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.

share|improve this answer
    
Checking in here way too late, just wanted to add my two cents that this is by far the best answer –  magnus.westrom Dec 8 '13 at 14:04
add comment

Here is a short comparison between the two: http://philipjeffs.com/scrum-vs-waterfall, the keywords:

  • Requirements vs. User Stories
  • Predictive vs. Empirical
  • Individuals vs. Teams
  • Sequential vs. Iterative
  • Cost of change vs. Encouraged change
share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Great article, Mark! –  Tiago Cardoso Dec 26 '11 at 16:00
add comment

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.

share|improve this answer
add comment

"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.

share|improve this answer
    
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?" –  CodeGnome Jul 14 '12 at 13:18
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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).

share|improve this answer
add comment

Waterfall: Ideally, Waterfall is recommended when the project goals and objectives are fixed and the development process is to be carried out in a traditional, “straightforward” manner i.e. the scope of development is fixed, and the project modules are to be developed based upon the project design created at the time of project inception. It is useful when the project related requirements are fixed, and do not change.

Agile Scrum: Based upon an iterative product incremental cycle, Scrum is recommended when the project related requirements, and the project scope, is not fixed and liable to change at any given time. Scrum is all about “inspecting” and “adapting” – it is most useful and effective when client related project requirements are likely to change as the project proceeds with the development activity. Scrum supports self-correction and self-learning – two traits which are essential for a dynamic project management system. In addition, Agile Scrum is a framework, meaning Scrum has to be first customised to suite the project specific requirements and subsequently implemented in a project to be effective.

share|improve this answer
    
Hi, welcome to PMSE! Worth to mention how the links added are adding value to the question itself, otherwise they could be considered only promotion. Tks! –  Tiago Cardoso Jul 2 at 18:57
add comment

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.
share|improve this answer
    
I don't see how waterfall helps here, either, unless the goal is CYA. All successful project management requires customer engagement to deliver value. –  CodeGnome Jul 13 '12 at 18:24
add comment

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.

share|improve this answer
    
Actually, you are wrong. Waterfall is a methodology. –  Zsolt Jul 13 '12 at 17:23
    
@Zsolt why didn't you downvote? –  Mark Phillips Jul 13 '12 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 –  CodeGnome Jul 13 '12 at 18:09
    
@MarkPhillips I was distracted by some good deal from valve ;-) –  Zsolt Jul 13 '12 at 18:11
    
@CodeGnome, I agree. For me the answer is too generic and less constructive. –  Zsolt Jul 13 '12 at 18:12
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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