Since the Agile software development movement began in the 1990s, there have been countless arguments between Agile and Waterfall development camps about why one methodology is better than another. These discussions hardly help project managers, CIOs and development teams choose the better methodology for their software projects. Bypassing biases, this tip presents an overview of 10 critical differences between Agile and Waterfall, providing some guidelines for making project methodology decisions.
Created in 1970, the Waterfall methodology was the first model for software development. Waterfall filled a methodology vacuum and was welcomed, but its slow step-by-step approach created redundant processes and long stretches between releases. Enter
With these overall Agile and Waterfall differences covered, let’s get into more detail with these 10 fundamental differences in the practices and strategies associated with each.
Waterfall: Requirements defined up front
Agile: Requirements evolve throughout the project
The Waterfall approach presumes that the right way to produce software is to gather each and every requirement up front and do a thorough analysis and design, so that it’s done correctly the first time.
Agile is very different. We are supposed to acknowledge that for anything other than the most simple of projects, we will never know everything up front and that those requirements will change over time. Getting it right the first time takes a few iterations.
Waterfall: Big bang releases
Agile: Quick releases
In Waterfall, there is no advantage to attempt to integrate early and often, as we presume that everything will work, both technically and functionally, if we just follow the requirements to the letter.
The Agile development process aims to get functionality released in small bite-sized chunks, and wants to get the code into the hands of customers as quickly as possible to learn more about what they really need, as well as how well we went about fulfilling those needs.
Waterfall: Plan driven
Agile: Learning driven
Waterfall tells us to take everything to do for the work and completely estimate and plan our work. We then simply have to follow through, recording actuals against estimates.
Agile teaches us that since we will never know all the requirements up front, we should get started with a minimum amount of knowledge about both what we are building and how we will do it, and then learn over time the best approaches to take.
Waterfall: Infrequent client communication
Agile: Continuous client communication
The Waterfall approach by its nature is document-centric. The documents serve as a contract between the parties. No interactions are needed, since the documents contain the totality of the agreement.
Agile encourages us to develop iteratively, continuously showing our work in progress to the client. Together we and the client can then figure out what should be accomplished as we continue to go forward in a very people-centric manner.
Waterfall: Interim deliverables at gates
Agile: Continuous deliverables of working software
Due to the fact that Waterfall is plan-driven, we need a way to show progress as we proceed. We do this in our project plan, with milestones to mark important events, such as completion of detailed specifications, component construction complete, system integration complete and so on.
The Agile development process says that we should continuously deliver software from early on that demonstrates end-to-end integrated and working software, even though that software will be feature-incomplete for quite some time.
Waterfall: Develop in horizontal component layers
Agile: Develop in thin vertical slices of functionality
Software development in Waterfall mimics the way we approach building skyscrapers, where we start at the base and build the application “on a strong foundation,” creating the application layer by layer.
In Agile, we assume that there are still details that need to be worked out as to what is needed for the application. We develop working software early, gain customer feedback and then incorporate that as we repeat the development and feedback cycle.
Waterfall: Programming is just construction
Agile: Programming is an extension of design
Waterfall treats the programming aspect of application development as merely construction, capable of being farmed out to the lowest bidder.
In Agile, there will always be holes in our knowledge that can only be filled by the continuous delivery of increasing capable iterations of working software. The design and programming of the application are inseparable.
Waterfall: Integrate at the end
Agile: Integrate early and often
Waterfall says that we will waste cycles if we integrate before we are finished constructing. We assume that everything will fit together perfectly if we just follow the plans.
Agile says that the sooner you recognize a problem, such as integration issues, the easier and cheaper it is to fix the problems. We integrate early and often to find the problems to fix, so they can be fixed close to when they are created.
Waterfall: Test at the end
Agile: Test early and often
Since we don’t integrate until the end in Waterfall, there is no to test until the end. But there should be no bugs if we just follow the plans we painstakingly put together at the beginning.
But in the Agile development process, the reason for integrating early is to find those latent defects and unforeseen use cases. Fixing them early is easier and cheaper when there is less code in the way.
Waterfall: Measure progress with documentation
Agile: Measure progress with working software
The Waterfall approach presumes that the planning is the most important aspect of application development. Measure your progress by examining the size of your plans.
Agile says that we are doing application development to produce software, not documentation about how we will produce software. Therefore, measure how well you’re doing by measuring how much software is produced and tying that back to the business value for the company.
Waterfall and Agile represent very different approaches to software development, and the differences are at the heart of what separates the two schools of thought. Understanding these differences is key to making the right decision for you and your organization.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
This was first published in June 2012