On-site Customer: The New Testament

In the foreword to Questioning Extreme Programming , Kent Beck now acknowledges that the whole single on-site customer thing was an error of early XP thinking, and that we should now expect to see customer teams equal to or larger in size than the programming team. ^[10]

This is somewhat problematic because many of the other XP tenets (e.g., reliance on oral communication and keeping the whole team in a single room) are predicated on the assumption that the customer is a single person (or at least speaks unambiguously, consistently, and always with a single voice). Ergo, many of these other XP tenets are based on a fundamentally flawed argument! (We don t want to say we told you so, but . . .)

According to this New Testament theory, it doesn t matter how many customers we ve got, it only matters that they speak with a single voice. We d like to make this observation: If we define the customer team as being equal to or bigger than the programming team, we end up with a team that has doubled in size .

Here are a few questions that occur to us:

• What does doubling the size of the team do to the project budget? (That s the gold owner s problem.)

• What does doubling the size of the team do with regard to exclusively relying on oral communication? (But he said . . .)

• What does doubling the size of the team do to the size of the room? (Madison Square Garden might be available.)

• What does doubling the size of the team do with regard to having the customer speak with a single voice? (Tower of Babel, anyone ?)

• What is the likelihood that our no-up-front-design Extremo friends have considered the ramifications of any of this? (When the problem surfaces, the answer will arise. It s a Zen thing.)

• Why is this better than writing specifications? (What s a specification, daddy ?)

What Can We Expect from XP Customer Teams?

To answer this question, let s go back to the XP2001 workshop report Customer Involvement in Extreme Programming one more time, referring to a project called DocGen:

A first observation during this project was that it involved not just one customer, but with many different ones. These include the end user (and even he comes in many categories), the system maintainers, and management, as well as the marketing people and the developers responsible for implementing particular customizations. Making these ˜speak with one voice involved a lot of creativity during the project.

Another observation was that the project requirements changed frequently. This was partly due to the fact that new people were brought into the project, bringing new requirements. Another reason was that in several cases the people involved in the project easily changed their minds. XP in itself is capable of implementing non-stable requirements. However, the resulting system may be an incoherent collection of features, ultimately leading to project failure.

Furthermore, technology and potential customers experienced a significant semantic gap when trying to talk to each other. In the DocGen case, the developers had a compiler construction background, whereas the end users came from a mainframe background.

This difference was amplified by the fact that neither the developers nor the customers considered talking to each other as their ˜real job, easily considering time invested in talking to each other as wasted . ^[11]

The problems described here are typically solved by introducing a specific role, the analyst, as distinct from the programmers. The analyst is experienced in his field of work and knows exactly how to bridge semantic gaps between the IT and business worlds . A team of analysts, of course, is even better. The one voice comes from writing all the details into a central document that gets sign-off from everyone who should sign off.

Although XP has now recognized the need for a proper analyst (or team of analysts), its practices are still predicated around the assumption that there s one on-site customer (goal donor) who provides story details to the programmers in the form of conversations. As we can see from the description of the DocGen project, this development (the introduction of a team of customers) didn t really help. In fact, if anything it added to the confusion. For example, the programmers had to use a lot of creativity in order to make myriad customers speak with one voice. Surely, the simple addition of a detailed requirements spec would have achieved this and therefore saved a lot of time and effort.

The problem of new customers joining the project and bringing with them new user stories (and the problem of people in the project simply changing their minds) could also have been mitigated through the creation of a proper requirements spec ”particularly if the spec provided traceability back to the original set of project goals, assuming the team had spent time up front thinking about these and writing them down. If people see in writing what has already been agreed upon, then they re more likely to pause and think about whether their exciting new requirements are really going to add true value to the project (i.e., whether the new requirements will help to achieve the original set of goals).

Similarly, when people take the time to write the requirements down in detail, this causes them to pause and think about whether the time spent implementing each requirement is justifiable after all. This also helps immensely in prioritizing requirements for each iteration.

Tracing requirements ( tasks , or use cases) back to a high-level set of project goals can also help the team to manage change (rather than actively embrace change). See the Oral Documentation Defanged sidebar at the end of Chapter 7 and the Taking a Goal-Driven Approach sidebar in Chapter 15.

 

Too Many Cooks

Most, if not all, projects have more than one master (see Figure 2-6, back in Chapter 2). Even the first XP project, C3, had essentially two customers: the goal donor (the on-site customer who contributed the requirements) and the gold owner (the project sponsor, who wasn t directly involved in the project). This highlights the classic problem with XP that we keep seeing: The customer speaks with more than one voice.

It s likely, and somewhat ironic given XP s emphasis on having an on-site customer, that the project sponsor can normally be thought of as the real customer, the one who must be kept happy at all costs. However, the project sponsor is also the person who will almost always be off-site. If the project is going in a direction that this person isn t happy with, the project stands a heavy risk of being cancelled. This is evidently what happened to C3.

We revisit the too many cooks issue in Chapter 7 in the sidebar Did Oral Documentation Kill C3?

 

And What About Those Acceptance Tests?

Acceptance tests are the customer s responsibility, and remember that in XP there are no test specifications, only test code. So don t be surprised if the customer has to write code!

Oh, come on, we re making this up, right? Nobody expects customers to write code, do they? Consider these statements from Chapter 5 of Extreme Programming Installed :

The customer responsibility is to provide those acceptance tests as part of each iteration. . . . There are many different ways to implement the acceptance testing on your project, and the programmers will pick one.

Programmers, you have the right to know what is needed. Insist on this right in the form of automated functional tests. ^[12]

(Rhetorical question: If the customers are already crackerjack programmers, why are they hiring the programming team?)

The arrangement is also described in Extreme Programming Explained :

You will have to learn to write functional tests [acceptance tests]. . . . Some teams may even assign you technical help for choosing, writing, and running the tests. Your goal is to write tests that let you say, ˜Well, if these run, then I m confident that the system will run. ^[13]

Depending on the skill and mind-set of your customer, she may not be able to conceive a systematic test, or understand a test once it has been written, or understand how the written code conforms to the idea she has in mind.

It s worth mentioning that customer test frameworks such as Fit and Fitnesse are starting to be introduced, so, in theory, this is becoming less of a problem. In practice, however, there s still a fundamental leap between stating a requirement in plain English ( I want the user to be able to define a new city ) and stating it in executable form, such as the following: ^[14]

 fit.ActionFixture 
 start eg.net.Simulator 
 check nodes 0 
 press new city 
 enter name Portland 

^[10] Pete McBreen, Questioning Extreme Programming (New York, NY: Addison-Wesley, 2002), p. xvi.

^[11] Arie van Deursen, op. cit., pp. 2 “3.

^[12] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed (New York, NY: Addison-Wesley, 2000), p. 32.

^[13] Kent Beck, Extreme Programming Explained , op. cit., p. 143.

^[14] See http://fit.c2.com/wiki.cgi?NetworkExample.