Bring on the Changes
From "birth" into the world of development we were taught that change was badto be avoided, controlled, and managed. The waterfall approach and RAD methods that followed have been created, in a sense, from this premise. A number of the RAD methods, such as evolutionary prototyping, still have a point where they ask for sign-off and then control from this baseline. In one sense it may be that there are no "bad" methodologiesjust misguided implementations. In his book Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorset House, 2000), Jim Highsmith makes the point that rigorous development works well for spacecraft development but is clearly ill-fitted to e-business.
The cost of change increases over the lifecycle and is higher at the end; you need to get it right up front or you'll pay for it later. Customers are drilled for requirements; the process seems to take forever and project managers then battle for requirements sign-off. The train is about to leave the station; you'd better speak up now or that's it! Inevitably, change comes during development, or, worse, deployment. Assuming that the change is signed off and the customer accepts the risks, how do you complete a difficult change at the eleventh hour? What will the integration issues be? Whose code will get broken?
Time to face the facts: Change will happen. XP accepts change and seeks to flatten the cost of change over the life of the project. This way you can postpone decisions until later, when they may or may not be required.
How does XP allow for change at any time?
Use of object-oriented techniques can help
Simplicity of design at high and low levels
XP practices that surround coding: code standards, automated testing, pair programming, refactoring
Time to ring in the changes!