eXtreme Programming (XP) Benefits
The benefits of XP can best be understood in comparison to the most popular traditional Waterfall development method.
| Benefit | XP | Waterfall |
|---|---|---|
| Flexibility and Adaptability | Extremely agile and resilient to changes in project goals and scope.Development priorities can change as frequently as weekly without a negative (or discernible) impact on development productivity. | Inflexible once the requirements specification is completed and development is started. Mid-project changes to priorities or scope are extremely disruptive to the development team and can kill or seriously delay a project |
| Stakeholders Control the Process | Stakeholders have complete control over the priorities direction of development (but not the development process itself) by prioritizing User Stories for development or creating new ones as requirements change. | Stakeholders lose control once the design specification is delivered to development, and don't recover it until the next project is planned. |
| Stakeholders Get What They Want | Stakeholders are continuously involved in evaluation of the software development and providing feedback as to whether the software meets their initial vision and works the way they expect it to. The software is not complete until the stakeholder agrees that it is. As a result, there are not product surprises for stakeholders, who always know exactly what the software product will look like. | Once stakeholders submit the requirements specification there is a long period (months) where engineering is interpreting the specification in isolation. Without frequent feedback, the engineers may develop a product that does not completely match the stakeholders' vision. In fact this is usually the outcome. |
| Accurate Forecasts | The short frequent release cycles and the measurement of project velocity at the end of each iteration allow for tuning of the schedule and, over time, very accurate estimates of calendar time required to complete a given set of user stories that constitute a release. | Development forecasts are notoriously inaccurate, always in the wrong direction. Product development times are extremely unpredictable, regardless of how much time is spent up-front with specification writing and project planning. There are a lot of reasons for this, but the main ones are that software development in any sizable project has too complexities and dependencies to estimate reliably as a whole, and requirements change all the time. |
| Software Is Always Releasable | Because Continuous Integration is built into the development process, and resources are invested in creating automated tests, software is always ready for release when business requirements dictate. There is no lengthy and unpredictable testing phase at the end of product development. | Software is only releasable when a grueling final test cycle is completed. The test cycle (often manual, but sometimes with an automated component created by "QA") must be repeated each times bugs are fixed and reworked features are added back to code. This cycle is inevitably repeated multiple time until the software reaches an acceptable level of "stability" or delays threaten the business viability. The end result is that software always ships with known problems that there is not time to fix. |
