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?
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
Use Agile (Scrum, XP, Kanban) when:
Use Waterfall when:
Great post by Dean Leffingwell on same topic - TAKE THE QUIZ - Picking Agile vs. Waterfall “Projects”: a Ten Point Quiz.
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:
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.
You have three factors:
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.
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.
"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.
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:
Do they use a formal iterative method, such as UP, Scrum, Kanban and etc, or do they make it up as they go along.
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)
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:
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.
