Agile vs. Waterfall - Is There a Real Winner?

Adapted by:  • Edited by: Michele McDonough
Updated Sep 12, 2011
• Related Guides: Software Developers

Waterfall and Agile are two different approaches to software development that also find use in project management. Both methods have their advantages and disadvantages, and the selection of either method will depend on various project-centric factors.

Waterfall Method

Slide 1 of 4

The Waterfall model is a sequential design process used in software development, with the development life cycle of Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance progressing steadily downwards, just like a waterfall flows down. Completion of one stage leads to another, and each stage has its separate goals. It owes its origin to the standard workflow process in the construction and manufacturing industries.

The advantage of the Waterfall method is the division of the project into tight compartments, reducing the dependency on individuals in the team. Key individuals coming and going at the transition points of stages does not affect project execution. The method also calls for robust documentation, further lessening the dependence on individuals.

The disadvantages are the inflexibility and rigidity. Just as water that flows down a waterfall cannot come back, it is not possible to alter a completed stage or even the project design in any way. Requirements gathering upfront therefore become critical. The logic is that the time spent upfront to ensure comprehensive requirements gathering and design saves considerable time and effort later.

Agile Method

Slide 2 of 4

Agile software development bases itself on an iterative and incremental approach. Software developers work on small modules, and respond to users' changed requirements rather than follow a specific or predetermined plan of action. The basic design is simple, and changes are made as work progresses.

Unlike with the Waterfall method, testing and customer feedback occurs simultaneously with development. This method gives priority to collaboration over design. Interactions among stakeholders take priority over processes and tools, and working software takes priority over documenting procedures. Different developers may work on different modules, and integrate all modules together at the end.

Agile methods of software development gained popularity in the 1990s as a reaction to the drawbacks of the traditional Waterfall methods. Critics considered the Waterfall method heavily regulated, regimented, and micromanaged to suit many needs, and have been working on various incremental approaches experimented since 1957.

The Verdict

Slide 3 of 4

Both the Waterfall method and the Agile method of software development have their uses. Although Agile arose as a reaction to the limitations imposed by the Waterfall method, Waterfall still retains its relevance as a better method when the environment is stable with no room for changes, when frequent interactions with ends users and other stakeholders are not possible, or when there is a risk of key developers quitting the project midway.

Agile is a lightweight method. As software developers focus on smaller work areas, overhead becomes less, and the project costs considerably less than when using the Waterfall method. When customer requirements are hazy, or the business environment is uncertain, Agile methods that allow making frequent changes, and testing during the construction stage remains the best choice. Successful execution of Agile projects nevertheless requires highly skilled and competent developers, and stakeholders who know what they want. With the scope to accommodate changes, an Agile project can easily lose its way.

Please be sure to check out the other items in Bright Hub's collection of Agile project management guides and discussions.

Reference

Slide 4 of 4
  • Sliger, Michele; Broderick, Stacia (2008). The Software Project Manager's Bridge to Agility. Addison-Wesley. ISBN 0321502752.
  • Royce, Winston, W. "Managing the development of large software systems.". Retrieved from http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Image Credit:

  1. freedigitalphotos.net/exsodus
  2. freedigitalphotos.net/Danilo Rizzuti

Comments

Showing all 2 comments
 
Bruno Spinelli Mar 17, 2010 4:51 PM
Agile for fixed price and time projects
Hi Folks,

I believe the secret is adaptation, for the situations you can’t avoid working with strict constraints, I believe Agile methodologies can be adapted.

If you need to deliver something, in a fixed time and budget , you have no time to loose and no money to waist. In other words: “You better completely and precisely understand the requirements written on that RFP (Request for Proposals) otherwise you are going to get burnt.”

The best way to make sure that you are achieving the expected results without spending time and money with unneeded efforts is to make the stakeholders aware of every significant piece of software built as soon as possible so the unavoidable mistakes of any project are always corrected before is too late.

I see iterations, incremental releases and constant reviews as essential tools to support this scenario and meet the requirements effectively. Agile methodologies leverage all these factors naturally and natively, and that’s where I think they have so much to contribute to any project, even the ones with so many restrictions.

I invite you all to take a look on the post "Agile for Fixed Price and Time Projects: http://whiteboardworks.com/2010/03/agile-for-fixed-price-and-time-projects/

Regards,

Bruno Spinelli.
Joseph Flahiff Nov 15, 2009 12:22 PM
Agile vs. waterfall
Interesting article but I don't think it goes far enough. Agile and waterfall are both fantastic ways of working to ensure success of a project. That is the ultimate reason for using either of the methods. The criteria for evaluation is what will help ensure success. The key is knowing what is important to success. There is a great book called "Balancing Agility and Discipline" that covers this in great detail.
I was recently the project manager for a project that was executed using agile but should not have been. In the end we used a hybrid approach but since it wasn't started with a hybrid it was much more difficult than necessary. The problem was that the content presented such high risk to the company profitability that every change had to be reviewed by a risk committee, by a medical team, by a business team, and ultimately by the project sponsors. It took weeks to get each of these teams to do their reviews. which flies right in the face of agile, where the team has authority to make changes and implement them.
All that to say, there is NO winner, there are horses for courses, sometimes agile is best sometimes waterfall. Know what you are getting into before you start.
 
blog comments powered by Disqus
Email to a friend