Recently, a customer whose organization had been entrenched in using the Waterfall development model asked me what the Agile methodology is and what it is good for. I decided to post my paraphrased response here in case you find yourself needing to convince a Waterfall customer to use Agile too.....
Agile methodology is a risk-mitigation approach that grew increasingly effective in our rapidly changing times. In a traditional Waterfall model, projects had distinct phases one following another: heavy upfront analysis, requirements definition, design, implementation, testing, evaluation/maintenance. This works well in static, predictable environments. But in a world where both the business and technology landscape started changing faster, the Waterfall model was prone to several fatal flaws:
- Even the best and most thought-out upfront analysis could not predict what the project needed to accomplish.
- The process could not adapt to changes in needs after the initial phases.
- The process could not respond to epiphanies in better approaches from stakeholders after seeing parts of the project in development.
Agile seeks to address these pitfalls. There is still some upfront analysis and requirements definition and there is still testing at the end, but what used to be distinct phases are now sort of blended into "mini waterfalls", or in Agile parlance, "sprints", running back-to-back for the project duration. The project team thinks about what should be done at the start of a 2-week sprint, does it, releases the current build it to stakeholder(s) to identify any possible issues, and iterate this way until project completion. Throughout the project, it is important not to lose the forest for the trees either, always asking if the over-arching project goals are being met. This approach provides much more transparency and control to stakeholders, and utlimately lessens risk.