Just to ensure that we’re all talking about the same thing, a customer is the person who makes the purchasing decisions on a project. The customer isn’t necessarily the person who commissioned the project, or the person who writes the cheques – it’s just a person with the authority to say, “Build this”, rather than, “Build that”.
Let's examine the responsibilities and nature of the role. Because the first thing to realise is that this is a role and not necessarily a single person. If the customer is a team – which is common – then they must have a team leader with the authority to make a binding decision who can arbitrate during disagreements. We call this “speaking with one voice”. Note that although we often talk about the customer as a separate entity we always treat them as part of the development team.
The first job the customer has is to generate requirements for the project. As you know, in extreme programming we prefer stories – represented on small index cards, and written as a simple sentence or two. It is then the customer’s job to explain the stories to the rest of the development team.
Once we have our stories the rest of the team will estimate them – provide a cost for each story – so that the customer can order them by business value. The customer tells us which order to build things in: which story to build first, second, third ….
When a pair of developers chooses a story to develop it is the customer’s job to sit with the developers for a while discussing the story with them, until they’re happy that they understand the requirements. If they’re feeling unsure about anything they may get into the coding for a while, and then call the customer back and show them what they’ve done, asking for comments.
This helps clarify the requirements both in the developer’s mind, and the customer’s. It also gives the customer a chance to see their requirements developed, and allows them to change their minds -- “Oh, that’s not exactly how I imagined it’d look – would it take very long to swap those two doohickeys around?” or “Oh, that’s calculating the mean; sorry I should have told you that we always use the median around here – it looks better on the reports.”
Commonly a customer won’t have the answer to a question. That’s okay; we don’t expect the customer to know everything. The customer must have the full support of their organisation, though, so that they can get the question answered as soon as possible, and deliver the information to the developers.
Now, I said up front that this is one of the most neglected practices of XP. That’s because it’s difficult. I was with a client a few weeks back, talking them into doing XP, and their biggest concern was this practice. One of the client’s team told me a few times that XP sounded great, but that they’ll have real difficulty getting their customer to play the XP way. They are developing software for commercially available hardware and their customer is literally their marketing department.
After a couple of hours of speculation I got them to call their marketing department, and invite someone over for a chat. When he arrived I gave him a brief description of his role as a customer on an XP project. The result: he loved it. In fact, he was excited about it.
I think that what he really liked was the fast turnaround times and the feedback. He fully realised that this meant spending a lot of time in the development lab, but that was okay for him if it meant getting his product out of the door faster, and with higher quality. He also liked the fact that he could steer the product as it was being developed.
The moral of this story is that you shouldn’t speculate about other people’s motivations – a half-hour chat could turn your speculation into facts.
The customer provides live requirements so they’re always up to date with the business needs, and they’re communicated in the most effective manner possible. Because of this an XP team has normally delivered a few iterations of a working system in the time it takes most other projects to document their speculative requirements.
On a development project it’s the customer’s money you’re spending. XP allows/forces the customer to make decisions about how that money is spent. Whenever there is a question about how to spend the money it’s the customer that gets to decide. In return the customer gets very high-quality software at an unprecedented low-level of risk.
Initially most businesses don’t know what to do with this level of feedback and control. Most businesses have had a long history of poor performance from their software developers, and they aren’t ready to handle all of this. However, it is my experience that a business will rapidly adapt to this new way of working and will learn to make use of XP’s frequent releases, and fine-grained control.
And if they can’t? Then Scott Adams can make a book out of it.