Summary

In XP, the customer is the catch-bucket for anything the programmers don t want to do. The programming team is absolved from responsibility for performance to schedule, performance to budget, etc. The customer is the catch-bucket for shortcomings in the XP process itself. Wherever the process is weak, more responsibility gets dumped on the customer. Dumping all the responsibility for schedules, budgets , requirements, and acceptance testing on the customer removes accountability from the programmers.

So when an XP project fails, the programming team is going to be blameless and guiltless. After all, it s the customer s problem, right? You d better believe it.

Having a single on-site customer may be stressful for the person who has that job and may make that person more prone to making errors. It seems to have dawned on the Extremos now that a single individual as the customer is inadequate, and so now we ve got teams of customers. But many of the other tenets of XP (e.g., detailed written requirements replaced by one-line story cards, emergent design, oral documentation, etc.) are based on the concept of one customer being in the room with the programmers all the time.

The customer (or customer team) can be a single point source of failure on XP projects. If the (single) customer drops the ball, bang, you re dead. If the customer team does not speak with a single voice, you re just as dead. There is no safety net. XP asserts that specifications are unnecessary and that writing specifications is, in essence, an act of cowardice. Yet the Extremos completely fail to account for the project failure modes that specifications are intended to prevent. This is justified by repeating fun statements like Fear is the mind killer.