Ten ways Agile development process, Waterfall approach differ Howard Deiner E-MailPrintAAAAAA inShare 2FacebookTwitterShare ThisRSSReprints Since

the Agile software development movement began in the 1990s, there have bee n countless arguments between Agile and Waterfall development camps about why on e methodology is better than another. These discussions hardly help project mana gers, CIOs and development teams choose the better methodology for their softwar e projects. Bypassing biases, this tip presents an overview of 10 critical diffe rences between Agile and Waterfall, providing some guidelines for making project methodology decisions. Created in 1970, the Waterfall methodology was the first model for software deve lopment. Waterfall filled a methodology vacuum and was welcomed, but its slow st ep-by-step approach created redundant processes and long stretches between relea ses. Enter Agile development s lean processes and rapid, modular, iterative releas e approach, which is a polar opposite of Waterfall s cascading process of requirem ent to analysis to design to coding to testing to release. Agile was designed to address the waste inherent in the Waterfall process due to the heavyweight docu ments that most adherents interpreted as a necessity to do good software enginee ring. With these overall Agile and Waterfall differences covered, let s get into more de tail with these 10 fundamental differences in the practices and strategies assoc iated 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 gat her each and every requirement up front and do a thorough analysis and design, s o 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 tha t those requirements will change over time. Getting it right the first time take s 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 j ust follow the requirements to the letter. The Agile development process aims to get functionality released in small bite-s ized 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 aga inst 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 bu ilding and how we will do it, and then learn over time the best approaches to ta ke.

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 pro gress 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 e vents, such as completion of detailed specifications, component construction com plete, 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 skyscraper s, where we start at the base and build the application on a strong foundation, eating the application layer by layer. In Agile, we assume that there are still details that need to be worked out as t o what is needed for the application. We develop working software early, gain cu stomer feedback and then incorporate that as we repeat the development and feedb ack cycle. Waterfall: Programming is just construction Agile: Programming is an extension of design Waterfall treats the programming aspect of application development as merely con struction, 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. T he 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 f ollow 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 t o 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 p ut together at the beginning. But in the Agile development process, the reason for integrating early is to fin d those latent defects and unforeseen use cases. Fixing them early is easier and cheaper when there is less code in the way.

cr

Waterfall: Measure progress with documentation Agile: Measure progress with working software The Waterfall approach presumes that the planning is the most important aspect o f application development. Measure your progress by examining the size of your p lans. Agile says that we are doing application development to produce software, not do cumentation 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 bus iness value for the company. Conclusion Waterfall and Agile represent very different approaches to software development, and the differences are at the heart of what separates the two schools of thoug ht. Understanding these differences is key to making the right decision for you and your organization.