Comparing Agile and Waterfall Methods of Project Management

October 11, 2012 | Author: PM Hut | Filed under: Agile Project Management

Comparing Agile and Waterfall Methods of Project Management
By Alan Cairns

Put simply project managers are in the business of making things happen. Project management can concern many different types of activity or project, and project managers are in charge of executing the planning, organization, management and control of resources to make it happen.

Project management can concern all manner of projects, from building a house to writing computer software. The manager’s skill lies in curating the resources effectively to achieve the end result.

Traditional (or Waterfall) Project Management

Project managers traditionally identify a number of steps to complete a project, which typically must be completed sequentially. In traditional project management there are typically four stages:

  • Requirements
  • Planning & design
  • Implementation
  • Completion

Waterfall stages

Figure 1: Waterfall stages

Not all projects will include every stage, but most projects include elements of these stages, sometimes repeatedly as one activity relies on the completion of the last. Most complicated projects require many more stages than this, which could include:

  • Conception
  • Initiation
  • Analysis
  • Design
  • Construction
  • Testing
  • Production/Implementation
  • Verification
  • Maintenance

It’s called the waterfall method because tasks are completed sequentially like water rolling down a cliff face.

It is widely accepted that the traditional, or waterfall development model works well for small, well-design projects but can fall short in bigger, less well-defined projects that may change over time. The waterfall model originates in manufacturing and construction, where project are well-defined and after-the-fact changes are extremely costly and often impossible. It was when this model was applied to software development that its unresponsive nature became a flaw.

Agile (or Iterative) Project Management

The agile project management model, or flexible product development approach, is based on principles of human interaction management, and is most commonly used in software, website, creative and marketing industries. In this approach project managers see a project as a series of small tasks defined and completed as the project demands, in a responsive and adaptive manner, rather than as a pre-planned process.

Agile stages

Figure 2: Agile stages

Agile project management’s flexible and interactive characteristics are highly relevant to the industry where it was created – software development. It’s thought that this technique is best used on small projects, or projects that are too complex for a client to understand before testing prototypes. It’s also highly appropriate for teams of professionals who work together on a daily basis. It’s much less likely to be an appropriate methodology for teams that are based in geographically-disparate locations/time zones, where it probably makes more sense to implement the waterfall method.


The traditional method of project management has been criticized for being unable to adapt to changes in projects, so a project’s success depends on an adequate initial brief. It leaves no room for testing prototypes or making design alterations based on behavior or user experience. Agile is generally considered to be much more useful in software development and many creative industries, as it allows for continual adaptation of the brief and response to client specifications.

Agile is not without its critics though; many believe that the agile model doesn’t scale well, which is why many of the biggest software development projects are still being conducted in Waterfall. While it is a useful approach to projects which are likely to have multiple changes, it is seen as offering no advantages over large projects where detailed requirements are known and changes are unusual or prohibitively expensive.

Choosing Between Waterfall & Agile Models

Choosing between models can be difficult, so if you’re struggling with this question, ask yourself the following questions;

  • How stable are the requirement?

    This is one of the main factors in deciding which method to use. If the requirement of a project are likely to keep changing its best to use iterative approaches such as agile, as it provides a framework in which new requirements can be accommodated once the project is underway. Using waterfall methods is like playing snakes and ladders; you can move forward but you can end up back at the start if the brief changes.

    If you are working on a project where the requirements are unlikely to change, and where a number of tasks need to be completed before the project can move the next phase, waterfall is the most appropriate model.

  • Are project teams working closely together?

    If project teams are located far apart, coordination of work needs to be relatively detailed to avoid confusion and wasted time. In this instance Waterfall is likely to be the most appropriate method, offering clear deliverables and project milestones and dependencies. Working closely together with close communication is a key part of the agile approach, which changes and is molded each day by customer requirements. Planning gives offshore workers the ability to get on with work without having to consult a manager continually.

  • What are the critical resources?

    When projects require unique, specialist skills or equipment and these resources are not immediately available, good planning is required. If this is costly or difficult to organize, it’s important to ensure that the resource is fully utilised during its scheduled usage. For this Waterfall is a better approach, as each milestone must be completed before the project can proceed to the next stage. This will help to ensure that critical resources are used minimally and efficiently.

Alan Cairns is a project manager at mobilize, a company mainly specializing in mobile forms.

7 people have left comments

I don not agree at all with this analysis:

– There are no stable requirements. If the are kept stable I will question the usefulness of the application when ready
– Especially with distributed development there is a need for daily and close interaction – agile principles support this
– I fail to see how Waterfall should be a better utilisation of resources. When the carefully concocted plan fails, which it, who are these resources then utilised in a better way?
– You are forgetting the entire value driven approach and prioritisation of stories.

The only reason to run Waterfall is that you do not know how do it differently.

Anders Ingerstedt wrote on October 15, 2012 - 6:57 am | Visit Link

Hi Anders,

Regardless of how useful you think the application is when it is ready, if the requirements won’t change then there’s no need to go back to the “requirements” stage once design and implementation has commenced.

Sorry I can’t make sense of the rest of your comment because of the grammar.

Alan wrote on October 22, 2012 - 12:03 pm | Visit Link

I wonder whether the co-location of teams is really a requirement for Agile in today’s environment. With the ability to easily do video conferencing for daily scrums, does geographic disparity really matter? As for time zones, while it may extend your day particularly when working with offshore teams, I’m not sure that onshore time zone differences really matter.

Andreas Zapletal wrote on October 30, 2012 - 6:41 am | Visit Link

Both methods are challenged for larger systems; Waterfall because the requirements are never static and incorporating changes is more difficult, and Agile because the changes that are incorporated may cause “local optimization” – great features, with a brittle architecture.

Fundamentally, large systems are hard – as as soona s we find techniques to build a system of size “X”, the requirements are to build a system of size 10X.

F. Michael Dedolph wrote on October 30, 2012 - 6:54 am | Visit Link

Nice short article and to the point. I agree with you on almost all points. I have implemented hundreds of projects in both methodologies and have found your statements to be right on target. Off-shoring is very difficult to implement a full Agile methodology, so I would suggest, be very careful when buying into Agile when off-shoring. The tie of teams communicating real-time is difficult, even with daily or bi-daily calls.

Another area of concern when using Agile; is the availability of SMEs or users. If they are not available on immediate demand or full time, Agile struggles to deliver on-time and on-budget. Assuming a developer or non-SME has the right knowledge to fill in the holes when a SME is missing is a slippery path and most likely will fail. IT should never drive requirements, if you do you are in POC mode still.

I have written a new methodology that tries to take the best of both worlds while minimizing the risk of both, an iterative approach with a good understanding of what needs to be developed before hand, with check points against the original plan. This has worked well when users are hard to get full-time and in off-shoring.

Anders, if your approach is to throw the Agile at every project you are doomed to fail in several scenarios. Also your comments show a lack of experience in scenarios where Agile has been proven to fail. Instead of such a narrow view of the world, maybe you should become open minded and take advice of those who have extensive experience.

Marc wrote on October 30, 2012 - 8:51 am | Visit Link

We started transitioning a development team of 35 people from Waterfall to Agile Scrum in July, 2012. We are developing the next major release of a COTS product. I’ll share some of my observation.

1) To date we have implemented all the key roles, primary Scrum ceremonies and artifacts. We have yet to move to the User Story style of identifying requirements and we don’t yet measure velocity. We still use traditional methods of documenting functional and non-functional requirements and estimating. Our product Owner does prioritize the Product Backlog.
2) Our team in distributed in France, US, India and China. We use technology heavily to facilitate stand-ups, reviews, planning meetings and retrospectives. The technology we use is video conferencing, audio conferencing, instant messaging, desktop sharing, web cameras, etc. We also have an electronic planning board and task board on a shared server that everyone can see and update.
3) Our team is divided into 5 scrum teams, each of approximately 5 to 9 people. We use a Scrum of Scrums hierarchy and the 5 Scrum Masters meet twice a week for a stand-up. Our sprints are two weeks. This seems to work well but I think it would be difficult to scale this too much larger.
4) We use a burn-up chart to show our overall progress to completion. This sends the message that the Product Owner has control of the end date since she controls amount of functionality to be developed and tested before release.
5) The close collaboration with the Product Owner and Marketing team (Voice of the Customer) has been our biggest success and benefit. Everyone sees the progress and adjusts “requirements” and priorities dynamically to best fit the market.

Tom V. wrote on October 30, 2012 - 9:46 am | Visit Link

Drawing a distinction between the fundamental of Waterfall and Agile is useful in that the essential differences are often requested by clients.

Having worked as project and programme manager on construction as well as national data management – to pick two extremes – I have had to use both approaches although at no stage did anyone actually use the terms.

We should also recognise that there may be certainty over an intended outcome: eg a new refinery or new data sharing capability for all local authorities with central government. The first of these is more clearly ‘waterfall’ the second is ‘agile’.

However there can be no certainty over all of the detail required to reach an acceptable result for either of these. In both cases there will be alterations after completion, part of what will be continuing maintenance and upgrading of the refinery (changes to control and security for example) and change to the software (changes to code to cater for changing to user requirements for example).

So the fundamental requirements for clear control of changes to the scope is required for both: client and project manager have to be prepared to say when a suggested change is beneficial and should be included at an agreed price; client and project manager also have to be able to say no to a suggested change, and either accept it as something beyond the project for later or say it really is not necessary.

Barry T wrote on May 19, 2013 - 3:28 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: 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>

All fields marked with " * " are required.

Project Management Categories