Communication

XP emphasizes face-to-face communication over other types of communication, such as documents. XP values documents but values personal communication even more. In order to facilitate communication, XP teams:

• Use a common system metaphor or vocabulary.
• Work closely with one another in an open workspace.
• Continuously integrate the code.
• Work closely with the business people, preferably having them in the same room.
• Program in pairs.
• Collectively own the code.
• Frequently plan and report status to the customer.

Simplicity

XP presumes that it is better to do the simple thing today and pay a little more tomorrow if more is really needed than to do a more complicated thing today that may never be used. This is a fundamental philosophy that permeates everything in an XP project. If something isn't needed today, we don't do it today.

For example:

• We will write no document unless there is an immediate and significant need.
• We will adopt no tool unless there is a tangible and verifiable benefit.
• We will avoid writing infrastructure until it is needed by existing code.

In order to maintain the simplicity of their software and their team structure, XP teams:

• Ask themselves: What is the simplest thing that can possibly work?
• Continuously simplify and improve the design through refactoring.

Some time ago, Kent Beck offered the following rules for simple design. In priority order, the code must:

1. Run all the tests.
2. Contain no duplicate code.
3. Express all the ideas the author wants to express.
4. Minimize classes and methods.

Feedback

Feedback works at different scales in XP.

At the highest level, the customer can see the progress of the team through the working software delivered every two weeks. This continuous feedback allows the customer to steer the project to success. We get concrete feedback on the state of the system in the form of executable pieces of functionality that pass repeatable, automated acceptance tests. These tests prevent the system from backsliding. No new release of the system can fail acceptance tests that used to work.

At the programming level, programmers write unit tests for all the logic in the system to get immediate and concrete feedback telling them if the code they just wrote is doing what they expected.

XP teams:

• Develop in small releases.
• Develop in smaller iterations.
• Break features and requirements into stories that fit in an iteration.
• Break stories into even smaller tasks.
• Write small unit tests to ensure that tasks work properly.
• Write acceptance tests to ensure that stories work properly.
• Track progress and communicate it to the customer frequently.

Courage

Perhaps a better name for this value is trust. In order to function, the members of an XP team have to have the courage to trust each other, trust their customer, trust their practices, and trust themselves.

XP team members trust that they can:

• Stop when they are tired.
• Let every business decision be made by the customer.
• Ask customers to reduce the scope of a release.
• Ask their peers or customers for help.
• Design and implement only what is needed for today and add tomorrow what will be needed tomorrow.
• Make changes that improve the functions or structure of the code.
• Fix the design and retrofit existing code when the design is shown to be inadequate.
• Throw away code.
• Change code they did not write.
• Change the process when it is not working.