eXtreme Programming prescribes a core set of values and practices that permit developers to do what they do best: develop software. All project stakeholders are continuously engaged throughout the development lifecycle. The customer contributes stories, priorities, acceptance tests, and information on demand when developers and managers request it. Developers contribute estimates and running code, supported by automated unit tests. Management mediates - balancing customer-defined value with development cost and resource levels dedicated to the project, based on fluctuating business conditions.

Values

The core values of eXtreme Programming are:

Communication: Success is directly proportional to communication. Most problems can be traced to at least one communication issue. eXtreme Programming forces all project stakeholders to communicate by employing practices that cannot be implemented without communication.

Simplicity: Always do the simplest thing that could possibly work, whether it relates to process or code generation.

Feedback: Receiving concrete feedback early and often from the customer, from the team, and from real end users provides more opportunity to steer the development effort and the project.

Courage: eXtreme Programming states, "If you are not moving at top speed, you will fail". Developers with courage can move quickly; they are not afraid to throw code away or make a change late in the game.

Practices

The following practices translate the values into activities a developer should perform as part of their routine.

Planning game: The objective of the planning game is to create an approximate plan quickly that corresponds to the next release or two, and then to refine it as the project evolves. Accurate plans are produced for the next iteration only. This style of planning is effective because the customer makes the business decisions and the development team makes the technical decisions.

The customer determines:

• Scope, i.e. the requirements expressed as stories (for a release and the next iteration)
• Release dates
• Priorities, i.e. which features will be developed first, based on business value

The development team determines:

• Estimates of how long it will take to develop a story
• The cost and implications of using various technology options
• Team organization
• The risk of each story
• The order of story development within an iteration (doing risky items first can mitigate risk)

Testing: eXtreme Programming employs test-driven development so that automated unit tests - written in NUnit - are produced in parallel with the code. This type of unit test gives a developer the courage to refactor code, because any break in the code will be detected quickly resulting in a test failure.

The customer (supported by developers) should produce automated acceptance tests to validate the stories. These acceptance tests determine whether the system satisfies the requirements, and should be executed regularly to ensure that developers are not breaking existing features as new ones are introduced. It is not necessary for acceptance tests to pass at each run; they simply help gauge project progress and enable the customer to make informed decisions about whether a piece of software is ready for release.

Pair programming: Pairs of developers working together should write all the code; this provides many benefits:

• All design decisions involve at least two developers
• At least two developers are familiar with every part of the system
• Two developers are less likely to neglect tests or other tasks
• Changing pairs propagates knowledge throughout the development team
• Code is always being reviewed by at least one developer

Refactoring: Refactoring is the technique of improving code without changing its functionality. Performed mercilessly, both before and after implementing a feature, refactoring incorporates learning into the generation of code without breaking the unit tests. It also helps keep the code clean, increasing its longevity and reducing the number of defects.

Simple design: In eXtreme Programming design is deemed so important that it should be performed constantly. The simplest design that could possibly work at any point should always be used, progressively changing it to reflect emerging reality. The simplest design does not imply a small or trivial design, merely that the design has to be as simple as possible and still work, e.g. features that have not been requested should not be included. The simplest design:

1. Runs all the unit tests successfully
2. Contains no duplicate code
3. Clearly states the developer's intent
4. Contains the fewest possible classes and methods

Collective code ownership: The whole development team owns the code, and each team member has the authority to make changes to the code to improve it. Whoever breaks the code, is responsible for fixing it. Unit tests must run before and after each change.

Continuous integration: Continuous integration means integrating code frequently. Ideally, the code should be integrated several times a day, each time following a completely successful run of all the unit tests. This makes debugging and fixing part of the daily development routine; it keeps the code clean, and ultimately helps avoid big-integration nightmares.

On-site customer: Having the customer (or a representative of the customer) available on-site helps eliminate bottlenecks that can arise when developers have to wait for critical business decisions or clarification of desires and priorities. Actually, the customer does not need to be on-site, providing they are available whenever needed to answer questions and to provide direction for the team, based on business value.

Small releases: Releases should be as small as possible and still deliver enough functionality to make them valuable to the business. Releasing software as soon as it makes sense will provide early and tangible value to the customer, who can then reciprocate with early, concrete feedback to the development team.

40-hour week: Here, the principle is more important that the actual number of hours worked during the week. Persistently working extended hours will adversely affect the performance of the team - more mistakes will be made, which will slow progress and degrade quality.

Coding standards: A defined set of coding standards helps facilitate refactoring, switching development partners regularly, and operating at maximum speed. The rules do not need to be exhaustive, but should provide guidelines that will make the code communicate its purpose clearly.

System metaphor: The system metaphor is analogous to architecture, and provides a consistent picture that describes the way the system works, where new components fit, and what form they should take.

The whole is greater than the sum of its parts

The practices work together; consequently the maximum benefits are attained when they are all adopted. However, implementing a single or small group of practices will still provide some benefits. Like any methodology, eXtreme Programming should be adapted to suit the development context, but care should be taken to retain balance amongst the practices so that their real power can still be harnessed to deliver superior software quickly.