Extreme Programming

Extreme Programming (XP) is a no nonsense, code first approach to software delivery that emphasises four basic activities: coding, testing, listening, and designing.

You code because if you do not code, you will haven’t done anything.
You test because if you don’t test, you don’t know when you are done coding.
You listen because if you don’t listen you don’t know what to code or what to test.
And you design so you can keep coding and testing and listening indefinitely.

It was the first Agile method to truly challenge traditional Waterfall methods. It did away with traditional requirements gathering techniques, brought testing to the forefront of the delivery process, and helped popularize core software engineering practices like automated testing, refactoring, continuous integration (CI), and test-driven development (TDD).

The Practices

Practice	Description
The Planning Game	Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same: Business comes up with a list of desired features for the system in user story format. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval. Business then decides which stories to implement in what order.
Small Releases	Start with the smallest useful feature set. Release early and often, adding a few features each time.
System Metaphor	Each project has an organizing metaphor, which provides an easy to remember naming convention.
Simple Design	At every moment, the design runs all the tests, communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods. This rule can be summarized as, 'Say everything once and only once.'
Testing	Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors. Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework. Acceptance Tests are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. Test can be manually run, or ideally automated.
Refactoring	Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn”t break anything because you have the tests.
Pair Programming	All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
Collective Code Ownership	Every programmer improves any code anywhere in the system at any time if they see the opportunity
Continuous Integration	New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or the changes are discarded.
40-Hour Work Week	No one can work a second consecutive week of overtime. Even isolated overtime used too frequently is a sign of deeper problems that must be addressed.
On-site Customer	A customer sits with the team full-time
Coding Standards	Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.

Dials to 11

XP was is a bet that hard problems become easier when tackled continuously all the time.

If code reviews are hard, we'll review each others code constantly - pair programming.
If testing is hard, we'll test continuously, even with our customers, starting from day one.
If integration is hard, we'll integrate constantly - continuous integration.
If design is hard, we'll continuously - refactoring.
If deploying is hard, we'll deploy constantly getting lots of feedback starting with the first iteration.

Learn More

Here are some great books on XP. Start with Kent's white book (1st Edition) on the left. Then move onto the green and the pink ones. There is a 2nd Edition white book, but I recommend reading the 1st edition first and then the 2nd if you like it.