Extreme Programming System

ExtremeProgramming is expressed as a system of practices which balance each other to help keep projects on track.

Via the PlanningGame, XP delegates to customers the authority to define all the requirements with UserStories, and to set the priority for those stories. XP also delegates to customers the responsibility to set priorities in such a way as to deliver maximum business value (BusinessValueFirst) within the resource constraints of the project, and to define tests that will determine when quality requirements are met.

XP delegates to developers the authority to estimate, for each story, how long it will take to implement. XP also delegates to developers the responsibility to meet those estimates if at all possible, to measure their performance against their estimates, and to improve the accuracy of estimates over the course of the project.

The practices that make up this delegation lead to a very stress-free flow of development.

Because the customers have the task of defining the project elements, and because they have good information as to how long things will take, they can easily optimize the product delivered by putting in high-value low-cost features.

Because the developers have complete authority for estimating the time to implement each feature, they become almost indifferent, in a positive way, to the features that are chosen to make up the deliverable.

Delegating priority setting to the customer, if done blindly, could lead to a choice of features, and an order of those features, that might leave some key product capability too late. If the system is supposed to be a distributed database, but the priorities didn't call for any work on distribution until the last week, something bad might happen.

To balance priority-setting, XP has the rule WorstThingsFirst. This rule means that the entire team will consider and discuss the risks of the project. During this discussion, the team reaches agreement on risky areas, and defines efforts (think Technical Stories, though we don't use that term) that should be undertaken to reduce the risks.

To accommodate learning and discovery of new risks or opportunities, XP has the practice of doing a ReleasePlan, an overview of the entire remaining development period, every few iterations. This provides a chance to surface new risks, bring forward capabilities that would add more value than the ones formerly contemplated, and to tune the plan in any other agreed way.

Within this context, the practice remains solid that the customer sets the final priorities. The developers inform the customer of the risks, recommend what is to be done, and do what comes out. (I suppose that a really stupid customer might say "don't worry about performance". I suppose that a developer who seriously thought that was wrong should consider resigning. In practice, customers are almost always smart enough to see risks.)

Once the ReleasePlan is in place, we do IterationPlanning. The customers select the UserStories to be worked on, developers determine the EngineeringTasks to implement the stories, sign up, and estimate how long it'll take. We put into the iteration the amount of work we can do.

During development, we may think of some class or method that would be useful later. XP has a rule, called YouArentGonnaNeedIt. That rule says that we never implement that speculative class or method. We have that rule, and we state it so firmly, and we live by it so carefully because to do otherwise would be to violate the balance between customer setting priorities and developer estimating time.

We have other rules during development. For example, we always DoTheSimplestThingThatCouldPossiblyWork. That is, we choose the simplest approach to solving the problem, subject only to the proviso that it could work. We do that because it minimizes the cost of doing whatever we're doing.

There are risks with the Simplest rule, mostly to the effect that the simplest thing might not hold up, and it might be hard to fix it later. These risks are balanced by some facts, and by some other XP practices. The facts relate to the characteristic of well-factored objects that they encapsulate behavior in a single place. Thus, when the behavior needs to be optimized or enhanced, there tends to be only one place to fix, making it not that difficult to fix. There is also the risk that the code might not be encapsulated, that by doing the simplest thing the system was left with redundant or ugly code. We balance that by our rule RefactorMercilessly, which ensures that the objects are clean and that there is no duplication that gets in the way.

I could, and in the fullness of time, will go on. The overall picture is that the XP practices have been defined to balance the forces acting on the project.

XP is one prescription for a software process. There are many such prescriptions out there, and there are many other ad-hoc processes in place that people actually use. Development projects are free to choose whatever process makes sense to them.

XP has one other rule: TheyreJustRules. This is not license to break the rules: it is license to come together as a group and change the rules. If an XP team found that some rule, say YAGNI, didn't properly balance the project, they would change the rule, add one, or remove one, to bring the project into balance. The ExtremeProgramming folks have worked for years to refine these practices, and we are confident that they are very close. But we continue to watch them in use and adjust if and when we actually need adjustment.

We offer XP as one approach to consider, and we offer the rationale behind it to aid interested people in deciding whether XP applies to their situation. We are not saying it's the only way, we are not saying anything bad about any other way. We are saying XP works, it's consistent, it's lightweight, it's fun, it's worth considering.

-- RonJeffries

So, the new project will introduce Oracle into the product. QC has a fit (they're challenged as it is). I point out that I didn't see what the big deal was, that the code would come with unit and functional tests / test rigs. We're now staffing a new QC department - they all had cardiac arrest ;) Apparently, throw it over the wall to QC is the standard s/w delivery method.

See, XP just feels right. I've worked in all manner of places over the past 20 years. I've yet to see one project (and not only the ones I've been on) to come in on time and on budget. Period. XP resonates with me as addressing what has been done wrong. I'm off to conquer the world. -- CharlesGilley?

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006