The Mythical Xp Customer

XP makes steering very easy. Even civilians can do it. Because XP must name the role for those who hold the steering wheel, we call them OnsiteCustomer, borrowing the positive-reinforcement ideal of a "paying customer". But because this role is unique, many folks decide not to understand how simple it is.

Some thoughts:

The term "mythical XP customer" was inspired by Fred Brook's "mythical man-month": both are curious (and convenient) abstractions. Originally the XP customer was in fact conceived as a single person, essentially because Kent Beck happened to meet two of the very rare incarnations of this ideal as he reveals in "One Team". He says

"The picture of a single person feeding expectations to a whole team of programmers is seductive. You don't have to worry so much about disagreement in detail, and political disagreements are even rarer. You don't have to worry about finding the appropriate expert to answer a question. Don't get me wrong. If you can find that one person who knows the whole domain, is willing to make quick decisions and fix them later, can speak to you both concretely and abstractly, and can put up with a room full of nerds you are likely to be successful. First, though, such folks are understandably rare. Second, this picture seems to exclude many people who now dedicate their talents to software development, like analysts, testers, and modelers."

So in its current version the XP customer may actually be a group of many people, but they are required to speak with "one voice". The role of the customer is basically to provide decisive input about "what" the developers should build and accommodate any obstacles the developers find as they figure out the "how". Hence, the call for an on-site customer, who is always available if questions arise. Finally the customer is also supposed to develop (in sync with the developers' work) a specification of the desired product in a language the developers can readily understand and test their product against (acceptance tests). Doesn't this sound wonderful (from the developers' perspective that is)? A developer talented in abstraction might even recognize the Gang-of-Four (Gamma et al.) design pattern that is applied here in a rather curious way: the proxy/gateway pattern. Its "Intent: Provide surrogate or placeholder for another object [the business team] to control access to it [consistency, flexibility, realism, prompt availability]. Applicability: A remote proxy provides a local representative for an object in a different address space [the business people's corner of the universe]." As this observation reveals the concept of the XP customer is an attempt to hide and encapsulate unfamiliar, inconvenient or even threatening aspects the development team would otherwise have to deal with. There's nothing wrong with that per se, as long as one remembers that a gateway can only control what goes through it, but doesn't change what happens on the other side. Hence even with the gateway in place many questions remain: The customer group is supposed to steer. How do they know where to steer to? How should they work together to be able to keep up with the agility of the development team? Important questions, which have not been answered yet. Ultimately developers and business people need to work together in one team to preserve agility and create maximum business value. The "one voice" gateway is just a crutch that we need for now. So, don't settle on XP as a closed safe haven for geeks with that friendly customer. There is still uncharted territory that wants to be explored.

PS Just for fun, imagine you were a business person (rather than a developer). Now apply the proxy pattern. Surprised by what you end up with?

PPS Ultimately, I believe agile methods are about battling the negative side effects of advantageous specialization/categorization (as much as possible, but not more). Mike Hill has an interesting perspective on this (The Essence of XP: Playing Both Sides and Neither, XPUniverse 2001).

--NikolasKaue?

TheMythicalXpCustomer would probably be a super-ProjectManager who can create consensus and consult expert (technical or non-technical) opinion when needed. Yes, this is hard, and it's quite rare, too. And ExtremeProgramming doesn't do much to deal with that. I don't see that as a weakness of ExtremeProgramming; I see it more as a realistic limiting-of-scope. ExtremeProgramming is a technically focused process, and it does not attempt to fix the political/organizational problems. See XpDoesntCoverThat. -- FrancisHwang

Quotes (mostly from XA egroup)

[Moved to XpCustomerQuotes.]

So I guess the main argument of this page is that you'll never find the XP "Customer," as described.

OK, I'll agree with that. But this doesn't mean that we should abandon the idea of the XP customer, or the effort to achieve that ideal. As with time management, the fact that you'll never absolutely achieve "touch it once" or "always work on priority #1 first" is no reason not to try. In a futile attempt to achieve perfection, we can often accomplish some really good stuff along the way.

As I see it, the XP "Customer" concept/ideal provides two significant benefits:

It stops the programmers from trying to set business policy and the business people from trying to dictate low technical design decisions. Let's have each group do what they do best, and have them stop trying to interfere with or control the work of the other group.
Someone or some group in the business community has to be able to make real decisions: Having a dozen or more independent groups all saying that they want it all and they want it now isn't going to get anything of value accomplished. There must be some business person or business process that prioritizes tasks so that high business value can be produced, and less valuable conveniences and "want to haves" can be deferred.

-- JeffGrigg

Perhaps a link to WhatSmartSoftwareCustomersKnow is appropriate? --MikeSmith

See XpMailingListQuotes, QuestionsToAskYourXpCustomer