Waterfall versus Agile methods: A pros and cons analysis

The word "Agile" has caught on as a buzzword in the world of software project management. The great thing about buzzwords is that they draw attention to new concepts that hold promise in terms of improving existing processes and methods. Agile has been touted as the next big thing in the mystical world of project management methodology and a replacement for the antiquated Waterfall methodology. Yet waterfall methods do hold value for certain projects and some development teams.

Cheetah – agile 

Turtle – not so agile 

IT project – not typically so agile

 

To understand the differences between Agile and Waterfall, you must first acquaint (or re-acquaint) yourself with the classic project management cycle.  Imagine a project request asking for the construction of a playground swing set. The usual project management lifecycle depicts the initial gathering of requirements from the client as describing a three tiered swing. The project manager interprets that as a request for a comfortable armchair on a swing. The final delivery of the requirements ends up looking like a swing with some critical features missing. However, in reality all the client really needed was a simple tire swing.

While the above talks about a project lifecycle from start to finish – the actual motions of shepherding the project from Point A to Point Z has typically followed the Waterfall methodology. The classic waterfall methodology goes through the gates of Plan, Build, Test, and Deploy – with the caveat that any late breaking changes to requirements would be something the business would have to work around or cough up big bucks to work into a change request.

The Waterfall methodology has been identified by the following characteristics:

• Classic methodology that has been used and proven effective for simple development projects
• Involves a series of gates or phases that must be completed in sequence
• Requires all requirements gathering to be completed up front
• Requirement changes become more difficult and more expensive as a team proceeds deeper into the life cycle
• Recommended – for shorter duration projects (within 6 months) where clear vision and stakeholder commitment exists

As projects have grown more complex and to support increasingly changing business environments driven by changes in the financial market place and changes in government regulations, business customers have demanded that IT respond to their changing requirements much more rapidly.

Along came Agile. Agile is a new(er) project management methodology that aims to address the concerns raised by Waterfall. 

Some of Agile’s characteristics:

• Low overhead methods that emphasize values and principles rather than processes
• Project priorities are re-evaluated on a continuing basis in cycles of a week, a month, or sometimes longer depending on the project
• Especially beneficial for small teams with rapidly changing requirements
• Allows for testing of the product in components

What it is NOT:

• A way to avoid documentation
• A way to encourage more change
• A way to put off planning till later

While Agile has the benefit that it can potentially deliver critical business value faster, there are a myriad of issues that most IT organizations face when it comes to the execution of Agile projects. In particular, the most common issue is that developers sometimes take a laissez-faire attitude and step away from the rigor needed to deliver successful IT projects. 

Agile may not be for everyone and Waterfall may not be for everyone either. That begs the question – what is the right project management methodology?

As with most things – the middle ground does most people a world of good. What has been happening recently is a hybrid version of Agile with Waterfall – this requires much more discipline on the project manager’s part – but usually the end result is a much more palatable outcome satisfying both the business and the IT organization.