Very Mild Xp Okay

Discussion on the merits of this page moved to VeryMildXpOkayDiscussion.

There are good lessons from ExtremeProgramming, but XP over does it. Here are techniques to borrow from XP, but in a milder way:

PairProgrammingIsaWaste. It might help newbies, but otherwise spot-checking is sufficient. How much is up to your organization.
OnSiteCustomer? There are numerous ProblemsWithOnSiteCustomer. They have their own job to do and are busy. The one assigned to be on-site may well be junior, and not an adequate source of knowledge. Contact and feedback are very important.
Some planning and UpFrontDesign is useful. There are certain things that are consistent between like industries or domains. To start in code and ignore this history using an "organic" approach suggests that XpIsForBadPlanners.

Like the title suggests, it is a continuum.

This implies XP does not do these things, a misconception common among those who have never done XP. XP does a lot of planning and design, including up front. It just don't hold off writing code to validate those ideas. XP does ContinuousDesign.

Regarding the OnSiteCustomer issue: Somebody's paying for the development. Don't you think they have an interest in ensuring that the product they're paying for is being made properly?

The cynical, but often true, answer is "No." Most often, the part of the organization providing the funding will never use the developed software; the users will be in a separate department as well as the managers who schedule their time. There are also other organizations besides the end users who will want a say in the development; such as the central IT group and the security group. I agree it would be wonderful to have a single person to coordinate the various conflicting interests, but in practice this usually falls on to the development team leader. The group providing the funding usually has no influence to make the project succeed; they merely have the ability to stop or continue funding. The end users may not have even been told that a solution is being built for them. The IT group doesn't care if the software runs or not, just what platforms or support software it may require. The security group doesn't care if the software runs or not, just that it passes their security tests. Not only do we not have one customer voice, the different voices don't even speak the same language.

So why don't we just sell them a lump of coal and be done with it? Clearly this view is overly cynical, and certainly not true. If companies threw money away like this, they wouldn't last long enough to be repeat customers. Maybe this kind of attitude is what caused the DotComBust.

XP does not suggest that the customer is always at your beck and call. It stresses the importance of customer locality when resolving fuzzy issues and problems that inevitably arise during development. Less separation generally equates to faster response times and quicker resolution of such sticky issues.

Where does XP specify that all projects are reinvented from scratch?

Turn some knobs to three and leave the others at zero?

Ahh, finally, to the meat of the discussion. ExtremeProgramming arose from a set of best practices derived from the founders' experience. The idea was to take the practices that worked to the "extreme" (turn the knobs to ten) and remove all practices that did not work (turn the knobs to zero). "Mild XP" is an oxymoron, but it isn't to say that adopting some of the XP practices cannot improve a situation. Some may not be ready for full-bore XP, but mild XP may be a step in a better direction.

See MoreIsBetterFallacy

But also see the DisproofByFallacy fallacy.

Huh?

More is not always better, which is true, but that doesn't necessarily mean that XP's 'turn all the knobs to ten' is wrong. Sometimes more really is better.

Perhaps we can focus the discussion on the circumstances in which a milder form of XP can thrive, as well as circumstances in which XP is not appropriate. Where XP is best, by all means choose it!

Doesn't it make sense to move into something gradually? For example, pairs can do occasional spot checking of each others' work, and then slowly ramp it up until the best level is found.

See TransitioningToExtremeProgramming

This seems to assume that the final destination is XP, when in fact the optimal point may be a mild form.

Re: "Mild XP" is an oxymoron

Like "jumbo shrimp"? Perhaps we can call it MildProgramming? :-)

Contrast with TruckNumber, PairProgrammingCostsBenefits, ProgrammingInPairs, PairProgrammingObjections, PairProgrammingMisconceptions, LackOfOnSiteCustomer, YouArentGonnaNeedIt, criticisms of BigDesignUpFront