That s the Customer s Problem

Karl Marx  

I cannot agree that XP is ˜just part of the growth of software development best practices . It is a change in the social contract of working uncertainly on technology of uncertain value. The role of technologists, business people, and managers change under XP. If this isn t your experience of XP, I d love to swap stories with you. ^[2]
”Kent Beck

A major weakness in XP is the continuous delegation of responsibility for minor items like requirements management and project schedule away from the programming team and onto the customer. So the (overloaded) on-site customer becomes a single point of failure, while the programmers just keep on refactoring away and go home at 5:00 PM every day.

In Agile Software Development , Alistair Cockburn describes a degenerate scenario (in a hostile XP environment) in which the customers are not quite sure what they want, but the programmers insist, Tell us what to build!

The programmers escape the pressure of the situation by shifting the burden over to the customers (which they are allowed to do). The customers experience the situation as unsettling: There is little time to reflect, examine, experiment, and sort out options. ^[3]

Just how much burden gets shifted onto the customer in XP? Here s a list from the XP2001 workshop report Customer Involvement in Extreme Programming :

. . . extreme programming (XP) insists on an on-site customer, who has many different tasks :

Understanding customer wishes, maintaining regular contact with end users, and balancing their potentially conflicting interests.

Talking to developers, clarifying feature requests when needed, and understanding some of the developer s technical concerns.

Specifying functional tests for user stories, and verifying that these tests run correctly.

Participating in the planning of iterations and releases.

Maintaining good contact with management, explaining progress, and justifying the time spent with the development team.

. . . Being a customer requires a number of skills that are independent of the application domain. These include balancing potentially conflicting end-user needs, experience in requirements gathering, reporting to upper management, controlling the budget, and checking for forgotten requirements. ^[4]

Damn! That s a load. Notice how all of this hard work has been offloaded from the development team and its manager to the customer (see Figure 5-1). The programmers are free to refactor, eat snack food, and go home clean every day at 5:00 PM. All this and they don t have to document their work either, or do any up-front design! Whee! Thanks, Kent!

Figure 5-1: Schedule is the customer's problem. Requirements are the customer s problem. The customer seems to have lots of problems.

The Customer s a Beast of Burden

(Sing to the tune of Beast of Burden by the Rolling Stones)

The customer s a beast of burden
Ain t got no specs
So nothin s certain
Everything is done from memory

The customer s a beast of burden
He s bifurcated
The project s hurtin

He didn t speak with a single voice to me

Ain t it hard enough
Ain t it tough enough
Ain t it late enough
And you still think that change is free?

It s pretty pretty pretty pretty pretty pretty strange
Really pretty pretty pretty pretty strange
Can t you see what happened on C3?

The customer s a beast of burden
We leave at five But he s still workin
He always writes all the acceptance tests for me

The customer s a beast of burden
We code in pairs Don t feel like workin
The schedule
Doesn t mean much to me

Ain t it hard enough
Ain t it tough enough
Ain t it late enough
And you still think that change is free?

It s pretty pretty pretty pretty pretty pretty strange
Really pretty pretty pretty pretty strange
The customer s really got it tough with XP

The customer s a beast of burden . . .

^[2] Kent Beck posting to the newsgroup comp.software.extreme-programming, subject: XP/agile disservice to the industry: an example, September 14, 2001.

^[3] Alistair Cockburn, Agile Software Development (New York, NY: Addison-Wesley, 2001), p. 103.

^[4] Arie van Deursen, Customer Involvement in Extreme Programming, XP2001 Workshop Report, http://www.cwi.nl/~arie/wci2001/wci-report.pdf, May 2001, pp. 1 “2.