XP Diagram : Practices Support Each Other

Bitwix : Close window
From Kent Beck's Extreme Programming Explained, First Edition, the diagram of how the twelve practices work together (pages 64-70).
On-site Customer
Planning Game
Metaphor
40 Hour Week
Refactoring
Simple Design
Pair Programming
Testing
Short Releases
Coding Standards
Collective Ownership
Continuous Integration

The Planning Game

You couldn't possibly start development with only a rough plan. You couldn't constantly update the plan - that would take too long and upset the customer. Unless: Then perhaps you could start development with a simple plan, and continually refine it as you went along.

Short Releases

You couldn't possibly go into production after a few months. You certainly couldn't make new releases of the system on cycles ranging from daily to every couple of months. Unless: Then perhaps you could make small releases, soon after development begins.

On-site Customer

You couldn't possibly have a real customer on the team, sitting there full-time. They can produce far more value for the business elsewhere. Unless: Then perhaps they can produce more value for the company by contributing to the project. Besides, if the team doesn't include a customer, they will have to add risk to the project by planning further in advance and coding without knowing exactly what tests they have to satisfy and what tests they can ignore.

Metaphor

You couldn't possibly start development with just a metaphor. There isn't enough detail there, and besides, what if you're wrong? Unless: Then perhaps you could start development with just a metaphor.

40 Hour Week

You couldn't possibly work 40-hour weeks. You can't create enough business value in 40 hours. Unless: Then perhaps you could produce enough business value in 40-hour weeks. Besides, if the team doesn't stay fresh and energetic, then they won't be able to execute the rest of the practices.

Refactoring

You couldn't possibly refactor the design of the system all the time. It would take too long, it would be hard to control, and it would most likely break the system. Unless: Then perhaps you could refactor whenever you saw the chance to make the system simpler, or reduce duplication, or communicate more clearly.

Simple Design

You couldn't possibly have just enough design for today's code. You would design yourself into a corner and then you'd be stuck, unable to continue evolving the system. Unless: Then perhaps you could get away with doing the best possible job of making a design for today.

Pair Programming

You couldn't possibly write all the production code in pairs. It will be too slow. What if two people don't get along? Unless: Then perhaps you could write all the production code in pairs. Besides, if people program solo they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practices, particularly under pressure.

Testing

You couldn't possibly write all those tests. It would take too much time. Programmers won't write tests. Unless: Then perhaps programmers and customers will write tests. Besides, if you don't write automated tests, the rest of XP doesn't work nearly as well.

Coding Standards

You couldn't possibly ask the team to code to a common standard. Programmers are deeply individualistic, and would rather quit than put their curly braces somewhere else. Unless: Then perhaps they would be willing to bend their style a little. Besides, without coding standards the additional friction slows pair programming and refactoring significantly.

Collective Ownership

You couldn't possibly have everybody potentially changing anything anywhere. Folks would be breaking stuff left and right, and the cost of integration would go up dramatically. Unless: Then perhaps you could have anyone change code anywthere in the system when they see the chance to improve it. Besides, without collective ownership the rate of evolution of the design slows dramatically.

Continuous Integration

You couldn't possibly integrate after only a few hours work. Integration takes far too long and there are too may conflicts and chances to break something. Unless: Then perhaps you could integrate after a few hours. Besides, if you don't integrate quickly then the chance of conflicts rises and the cost of integration goes up steeply.