Waterfall or Agile?
April 25, 2010 | Author: PM Hut | Filed under: Project Management Musings
Waterfall or Agile?
By Samuel Prasad
Neither one works in the real world. A combination of both Waterfall and Agile methods are required to not only effectively manage the development of complex software required of most applications today but also keep clients engaged throughout the development process to ensure that the final product meets their functional and operational requirements.
The Waterfall methodology was in fact never introduced as a workable model. It was presented as a “flawed” method in 1970 by W.W. Royce who argued that a pilot or prototype system be constructed first to identify risks and unknown behaviors before building the real system. However this approach never took hold and the Waterfall method ended up being defined as a series of sequential phases - requirements definition, design, construction, testing and maintenance - where each phase is required to be completed before starting the next phase. This classic predictive approach to software development works very well when all the requirements are known a priori and they don’t change. Product release schedules and development costs can be accurately predicted. Unfortunately, this does not work in most cases because requirements almost always change and product release dates must keep up with market conditions.
Over the years several methodologies under the classification of Agile models have been proposed to address the shortcomings of the “predictive” Waterfall model. Some of the well known ones include:
- Rapid Application Development (RAD) or Prototyping
- Spiral
- V-Model
- Extreme Programming
- Function Driven Development (FDD)
- Test Driven Development (TDD)
- Rational Unified Process (RUP)
- Scrum
The best methodology, in my opinion, is a hybrid model that uses a combination of features from more than one model depending on the project requirements. This allows experienced project managers to choose and tailor aspects from multiple development models to best suit the project, the team and culture of the company.
Project management is a lot like playing chess. You need to know the end objective and an overall plan to achieve it. In other words, you require a strategy to get the project from the start to the finish line. In addition, you also need to have a set of short-term goals or tactics that are measurable and can be implemented relatively quickly that demonstrate results which indicate if any changes in tactics are required to successfully execute the overall strategy. The tactics employed to achieve the short-term goals are iterative in nature and are repeated multiple times to move the project iteratively to the finish line.
Several aspects of the Waterfall method are well suited to define “strategy” while many facets of Agile methods are appropriate for defining “tactics”. I suggest that you use the Waterfall model to gather initial requirements, define user and system interfaces, and draft the foundation of the system. Use the Agile iterative model during construction to deliver parts of the system in pre-defined increments. This allows business stakeholders and clients to use the system and provide valuable feedback as the system is being developed. This can be incorporated into the system in subsequent iterations guaranteeing that the final product will not be outdated even before it is completed.
Dr. Samuel Prasad is a renowned global technology manager with a 15-year track record in helping companies on their implementation of strategic plans and programs related to technology projects for major media, entertainment, data warehousing and financial companies in the U.S., China, Europe and India. His domain expertise extends into areas of financial transaction processing, mobile, wireless, RFID, online media, casual gaming and business intelligence. Sam is a certified Project Management Professional (PMP) and a Certified Software Quality Engineer (CSQE). Sam has a Ph.D. in Robotics & Computer Science from the Stevens Institute of Technology (USA), and a master’s degree in Computer Science from the Indian Institute of Technology. Dr. Prasad can be reached at Intelligent Software Systems. Blog: http://blog.prasads.com/ - Email: blog@prasads.com - Telephone: 631-368-8130
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=""> <strike> <strong>
All fields marked with " * " are required.











2 people have left comments
I agree. Consider also the impact of the structure of the funding contract itself:
A combination of methods is also required when providing paid SW delivery services to customers, since most customers want to know what they’re going to get for their money.
For many first-time development relationships where trust is low, a firm fixed price tied to a detailed scope of work is most typically required. This is equivalent to a Waterfall method.
Other relationships are based on a time and materials basis. That is, the customer pays for whatever it costs to make what they want. This lends itself to Agile methods.
While applying Waterfall to time & materials contracts will work (think defense industry cost-plus models), trying to apply Agile to a Firm Fixed Price contract will more often than not result in running out of budget before the system is complete.
I also agree.
The Waterfall method is great for establishing the initial scope and functional specification document (including the wireframes, IA and expected UI/UX).
From there the Agile method can be used to tweak things throughout the project.
I think it’s valuable to include “Change Requests” though even as part of the Agile method, as every iteration of a change is going to have an unknown affect somewhere else, and often hemorrhages time and money from the project.
The BEST project methodology is a little something I like to call “Common Sense” Project Management. Use the tools you need to get the results everyone wants.