Flexibility with Agile
The traditional waterfall process, like its namesake cannot be stopped or easily redirected once it starts. Once the final specification is delivered to engineering, there is no turning back, presumably because the cost and lost development productivity would be just too high a price to pay. However there are two very good reasons why change in the project scope must be considered once development starts.
- Waterfall specifications are never complete
- The world (markets, customers, competitors) changes while development is proceeding
Traditional software development has attempted to deal with the first issue by increasing investment in a "complete" specification, which has proven to be an unachievable goal. (Even the rigorously planned Space Shuttle project didn't plan for O-rings and heat tile problems). The second issue, however can never be fully addressed by traditional methodologies. The pace of external change is increasing, not decreasing (see Why Agile?), which means that Waterfall development methods are, by definition, increasingly missing the business requirements.
Agile Methodologies embrace change. They can do so because there is no "Big Specification" in advance. As a result, there is not an emotional investment or commitment to a final product path (although there is a final goal). There are only new decisions to make along the way, which are shaped by continuous learning and assessment of the market. Developers who work in an Agile environment do not see changes, they see new features and functionality to be added. By adding functionality in an incremental fashion, requirements are much more likely to be matched to market and stakeholder demands. Stakeholders can agree to change the product path without disrupting the development process or losing productivity.
