Values

Beck's XP description is noteworthy in the process world for being perhaps the first to explicitly state the values that underly the attitude and practices on a healthy XP project. To quote Beck on the relationship of values and practices:

The [practices] are what you do. The values are how you decide if you are doing it right.

They are:

• Communication XP accepts the widely appreciated observation that problems in communication underly most project difficulties. Communication between programmers is promoted through pair programming, the daily stand-up meeting, and the Planning Game. Communication is promoted through customer involvement in writing acceptance tests and the Planning Game.

• Simplicity or, "Do the simplest thing that could possibly work." This applies not only to the design of software, but to other things such as requirements and project management "tools." For example, XP encourages the use of simple paper index cards to write a brief description of feature and task requests, if more formal artifacts can be avoided. In terms of software design, XP avoids speculative design for possible change ("future proofing") or the creation of more generalized components that aren't immediately justified by current requirements.

• Feedback This value drives quality and adaptation. Feedback in the short term is driven by the XP practice of test-first development with unit tests. It also comes from the practice of continuous integration; a broken build tells the story. When a customer writes a story card (a feature description), programmers immediately estimate it, so the customers know the effort. The practice of daily tracker provides feedback to the team and customer on progress for the iteration. On a longer scale, the customer written acceptance tests provide feedback. Short iterations give the customer the chance to see (and perhaps operate) an incrementally evolved partial system, and clarify or redirect the requirements. And the practice of frequent operational releases generates feedback from production users.

• Courage The courage to develop fast, and make changes fast emerges from the support of the other values and practices, and modern technologies. For example, without a massive set of unit tests, acceptance tests, and continuous integration, making deep "architectural" changes in the code base is tricky business difficult to tell what will break. But the presence of these, combined with a simple design, very clean code refined from frequent refactoring, and modern automated refactoring tools provided by many IDEs enables more rapid and radical change.