On-site Customer: The Old Testament

In the initial wave of Extremo literature, the on-site customer was a single individual, a walking, talking replacement for a requirements spec who lived in the coding room with the programmers for an indefinite amount of time. And on-site customer couldn t be just anyone . Nope, you needed the real expert, and for an indefinite period of time, because in XP SoftwareIsNeverDone.

We discuss why software is never done in XP in Chapter 11.

 

Of course, some people have thought for years that relying on a single on-site customer was lunacy, but until recently this policy has been defended vigorously by the Extremos.

Here are some possible failure modes:

• The goal donor and the gold owner don t agree (but remember, as we discovered in Chapter 2, TerminationCanBeSuccess ).

• The on-site customer gets sick and can t work for 2 weeks, goes on vacation (time for ping-pong! ^[5] ), quits, etc.

• The on-site customer can t remember exactly because the user story details aren t written down ”at least not until the executable acceptance tests are written (see Chapter 10).

• The on-site customer is inconsistent and tells different things to different people.

• The on-site customer doesn t know everything he needs to and fakes it (after all, the pressure is always on to make snap decisions and keep moving the project forward).

Problems with the ˜ Old Testament On-site Customer

The theory behind an on-site customer is a little idealistic: The customer (i.e., the domain expert) is empowered to make day-to-day decisions for the project. She then relocates to your office and mixes with the programmers every day for the duration of the project.

The problems with having an on-site customer are as follows :

• The on-site customer is the single biggest point of failure in an XP project. In traditional project setups, external forces (those outside the team s control) are usually counted as the highest risk. This is something that a modern software process should aim to cushion. XP, however, exacerbates the problem by focusing the entire project, for its entire life cycle, around the biggest external force: the customer.

• It s unlikely that you ll get the real decision-maker for the duration of an 18-month project. The on-site representative will more than likely be a proxy for the real customer.

• The so-called domain expert might not be such an expert, especially if he is freely available for the full project (which may span several years). This isn t really an XP issue, because the same problem would affect any project ”if you can t get the information you need from the customer, then you re in trouble. However . . .

• . . . when analyzing a project s requirements, it s much better for the analyst to spend time up front discussing the project requirements with as many customer representatives as she can. If one person doesn t have the required information, then the analyst can ask somebody else for it. She can get down into the trenches and find out the real problems that need to be solved from the people who will actually be using the system. Then she can define business processes, extract use cases from these processes, and take the customer through them, making sure that the customer understands what he s getting and why (and all of this before time has been spent producing production code, which the customer may then decide, upon seeing it, that he doesn t want after all).

  Even better, the customer (the real customer, that is) will be telling the analyst what he wants; the analyst just needs to establish why and help the customer to redefine what he wants, if need be. Note that XP does create a lot of useful one-on-one time between the customer and team, but the key here is that much of this can be achieved more effectively prior to coding.

• If the programming team members (or the business analysts) find that they need more information, there s nothing stopping one or more of them returning to the customer site and talking to the customer again. In our experience, we ve found that customers appreciate this sort of diligence and are keen to help fill in any gaps in the information that has already been gathered. Of course, depending on what s needed from the customer, a simple e-mail or phone call is often enough. This also means that the team isn t restricted to just one customer representative; it s possible to pick up the phone and speak to the person who is most likely to have the required information.

  On the other hand, if the customer has gone to the trouble and expense of allocating a full-time staff member and relocating her to the programming team s site, the customer will wonder why the team is bothering him. ^[6] The on-site customer should be the person responsible for gathering all required information, from the various departments, as and when the information is required (i.e., on a just-in-time basis). In other words, the on-site customer must learn to be a software analyst as well as a normal customer.

• There s always a risk that the on-site customer will become polluted with technical issues and will start to make business decisions based on the recommendations of the programmers.

• Assuming that the team isn t operating at the same location as the customer s business, having a customer proxy means that you re removed from the political machinations of the real customer s workers. This may seem to be an advantage, but it also removes some of what you gain when you re actually at the customer site, being a consultant. By visiting the customer site, it s possible to establish firsthand whether certain aspects of the proposed new system will be accepted.

  Specific examples of questions that may be answered very easily on-site (but which an isolated on-site customer is more likely to miss ) include the following: Will the new Executive Dashboard product actually be used? Are the workers sufficiently receptive to keep feeding it new data to keep the system relevant? Is there corporate buy-in, or are internal politics likely to cause problems?

XP s answer to all these problems is that the customer role is a difficult one. As Kent Beck writes in Extreme Programming Explained :

GROUCHO  

Being an XP customer is not easy. There are skills you have to learn, like writing good stories, and an attitude that will make you successful. Most of all, though, you have to become comfortable influencing a project without being able to control it. ^[7]

So, the customer is responsible but the programmers are in control. Hey, sounds like fun, where can we sign up?

Did Problems with the On-site Customer Help Kill C3?

Well, we know by now that fear is the source of all project failures, but here s what the XP2001 workshop report Customer Involvement in Extreme Programming had to say about it:

Ron Jeffries (who considers himself ˜the most extreme of the three extremos ) reported on the role of the on site customer in the well-known Chrysler Comprehensive Compensation (C3) project, In this very first XP project, two full payrolls were developed for Chrysler. The project began with approximately 145 large user stories, with a total estimated duration of one year.

The on-site customer in this project had a vision of the perfect system she wanted to develop. She was able to provide user stories that were easy to estimate. Moreover, she was with the development team everyday [sic], answering any business question the developers had.

Half way [sic] the project, several things changed, which eventually led to the project being cancelled. One of the changes was the replacement of the on site customer, showing that the actual way in which the customer is involved is one of the key success factors in an XP project. The new on-site customer was present most of the time, just like the previous on-site customer, and available to the development team for questions. Unfortunately, the requirements and user stories were not as crisp as they were before. ^[8]

As we can see, simply changing the on-site customer ”one person ”led to problems of project-destroying proportions . Most businesses would regard this single potential point of failure as being an unacceptably high risk.

Warning: Being an XP On-site Customer May Be Hazardous to Your Health!

Another problem with the on-site customer role, which directly affected C3, is simply that the role is difficult and stressful. While XPers generally talk about XP projects being fun to work on, the customer has a much harder time of it.

For the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) 2001, XP author and C3 participant Chet Hendrickson wrote an open and frank article titled Will Extreme Programming kill your customer? In this article, Chet discusses C3 s first on-site customer, Marie, who was the supervisor of monthly and biweekly payroll for Chrysler s Corporate Disbursements Department. On C3, Marie was responsible for writing and prioritizing all the user stories, questioning the programmers estimates, and approving all the acceptance tests (plus, to quote Chet, a hundred other things that we eventually took for granted ).

A few months after the launch of C3 s first phase, Marie developed stressrelated health problems and wisely transferred to a less stressful position. Her replacement customer was a very bright and dedicated man. Despite this, it was soon discovered that the replacement customer just couldn t fill his predecessor s shoes:

All we did know was that the job had been too much for the only person we had ever seen actually do it.

This leaves us with two questions. The first, ˜How do you train an XP customer? is beyond the scope of this discussion. The second, ˜Can you do everything that is required to be an XP customer and remain healthy ? is the largest human issue surrounding Extreme Programming. ^[9]

And now for something completely different . . .

SATIRE WARNING
The Extremo Inquisition, Round 2

A team of seven programmers, who had previously been tailoring RUP for their projects, decides to try out XP.

Billy: Right, we ve read all 20 XP books, scoured the newsgroups, entered into a personal t te- -t te with Cardinal Geoffrey, and cut off one of our fingers as Becht tells us to do in his book sequel Extreme Programming 15: The Cunning Plan, This Time There s Gore . I think we re about ready to get started.

Mrs. Potts: I still think he didn t really mean for people to do that.

Milia: Wait! I believe wemay have forgotten one thing, Billy. Can you think what it is?

Billy: I don t know! I just wanted to use XP because I hear you can get coding straightaway with it. I didn t expect a kind of extreme inquisition.

[JARRING CHORD]

[The door flies open and Cardinal Becht of Spain enters, flanked as usual by his junior cardinals, Cardinals Geoffrey and Henrik.]

Becht: Nobody expects the Extremo Inquisition! Our chief weapon is fear ”fear and snacks, especially those tasty little biscuits with the crumbly toppings . . . Hang on, I ll come in again.

[The Inquisition exits.]

Billy: I didn t expect a kind of extreme inquisition.

[JARRING CHORD]

[The cardinals burst in.]

Becht: Nobody expects the Extremo Inquisition! Our three chief weapons are fear . . . tasty snacks . . . and . . . a single dedicated on-site customer who codes acceptance tests and speaks with a single voice! [Blathers on about the virtues of oral communication as opposed to written specs .]

Henrik: [Sotto voce] Wait, sir, the customer got bifurcated last week.

Geoffrey: But surely that means we re going to need a pair of customers!

Becht: [Deeply frustrated] Damn! I ll start again . . . Amongst our weaponry are such diverse elements as . . . fear, or is that courage? Tasty snack treats . . . and . . . two dedicated on-site customers who code acceptance tests, speak with a single voice, manage the schedule, and ”

Geoffrey: Hey, wait, let s turn the dial all the way up to ten and bring in a whole squadron of customers!

Becht: Good idea. Amongst our weaponry are . . . ten on-site customers who provide snack food, speak with a single voice, code acceptance tests. . . . Now, let s see. Henrik! Sit this rag-tag team in some comfy chairs and feed them snack food . . . and . . . fizzy cola!

[Dramatic organ music plays . . . lights flash . . . scene fades to darkness , to faces of puzzled-looking programmers.]

 

^[5] Of course, XP doesn t actually say, While the cat s away, the mice should play ping-pong, but if the customer is the programmers sole source of details for their user stories, what else are they going to do for those 2 weeks?

^[6] This isn t necessarily a problem, but it can become a problem if the single on-site customer isn t up to the job (e.g., if the customer doesn t understand the business sufficiently well). If the team increasingly needs to gather information from outside the room (bypassing the on-site customer), this is a good sign that the on-site customer snake is starting to slip.

^[7] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p. 143.

^[8] Arie van Deursen, op. cit., pp. 1 “2.

^[9] Chet Hendrickson, Will Extreme Programming kill your customer? http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html , September 2001.