XP teams design software for specific functionalities without adding any functionalities that are not specifically requested that may slow down the process, keeping the development course simple through systematic and regular testing and design improvements.

Extreme Programming is based on 12 principles:

• The Planning Process -- The desired features of the software, which are communicated by the customer, are combined with cost estimates provided by the programmers to determine what the most important factors of the software are. This stage is sometimes called the Planning Game.
• Small Releases -- The software is developed in small stages that are updated frequently, typically every two weeks.
• Metaphor -- All members on an XP team use common names and descriptions to guide development and communicate on common terms.
• Simple Design -- The software should include only the code that is necessary to achieve the desired results communicated by the customer at each stage in the process. The emphasis is not on building for future versions of the product.
• Testing -- Testing is done consistently throughout the process. Programmers design the tests first and then write the software to fulfill the requirements of the test. The customer also provides acceptance tests at each stage to ensure the desired results are achieved.
• Refactoring -- XP programmers improve the design of the software through every stage of development instead of waiting until the end of the development and going back to correct flaws.
• Pair Programming -- All code is written by a pair of programmers working at the same machine.
• Collective Ownership -- Every line of code belongs to every programmer working on the project, so there are no issues of proprietary authorship to slow the project down. Code is changed when it needs to be changed without delay.
• Continuous Integration -- The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.
• 40-Hour Week -- The XP team does not work excessive overtime to ensure that the team remains well-rested, alert and effective.
• On-Site Customer -- The XP project is directed by the customer who is available all the time to answer questions, set priorities and determine requirements of the project.
• Coding Standard -- The programmers all write code in the same way. This allows them to work in pairs and to share ownership of the code.

Often abbreviated as XP, Extreme Programming should not be confused with Windows XP.

Extreme Programming Holds Promise for Intranet Development  
This article from Intranet Journal examines the way Extreme Programming works in practice.

eXtreme Programming
A list of Extreme Programming workshops, services and links.

Extreme Programming: A Gentle Introduction
An easy-to-follow explanation of Extreme Programming with diagrams that show different stages in the XP process.

XProgramming.com
News and information, publications and community resources for Extreme Programming.

eXtreme Programming eXperienced
This case study illustrates how a small U.K. software firm used component-based architectures supporting the XP model to rapidly execute a project.

Using RUP for Small Projects: Expanding Upon eXtreme Programming
A white paper from Rational explaining the different elements of RUP. (pdf)