A guy walks up to Steven Spielberg and says “How do I become a movie director?”
Spielberg says “To be a movie director all you have to do is say you are one”.
“That’s all I have to do?”
“Yeah. Now if you want to be a good movie director….”
So far being an XP project has been a lot like being a movie director, but how do we make sure our projects turn out closer to “Schindler’s List” than “Plan 9 from Outer Space”? Clearly, there is some difference between saying you are Extreme and really being Extreme.
A lot of emphasis is being placed on the twelve practices, but is that the key to knowing if your project is really doing XP?
The Twelve Practices
XP is most often characterized by 12 practices:
- Planning Game
- Small Releases
- Metaphor
- Simple Design
- Testing
- Continuous Integration
- Pair Programming
- Collective Ownership
- Refactoring
- 40-Hour Week
- On-Site Customer
- Coding Standards
Should we evaluate a project’s XPness by its adherence to these practices?
Is a project Extreme if it follows all 12? Is it Extreme if it follows a specified 5 practices and any 4 of the other 7? If this is true, what are the 5, how do we measure adherence?
Can you pick and choose and still be on the path to Extreme?
Would the answers to these questions help us know if a project is XP?
No, the twelve practices are intended to be a starting point. Projects who want to know how to start XP are pointed to the twelve practices and told to do them for a couple of iterations and then to modify and adapt them to their local circumstances.
So, if the directions on the label say you should change how you use the practices, they cannot be the standard against which to decide if a project is Extreme.
If following the 12 practices isn’t the necessary and sufficient condition, how can we tell if the project we are looking at, or working on, should be characterized as an Extreme Programming project?
First Principles
Kent Beck envisioned a new software development process based on 4 values:
