No Safety Net

What happens if the customer (or customer team) has a glitch?

This is likely, given that it s unlikely the customer will have received any training on how to be a well-behaved on-site customer (apart from being handed the white book and being asked to read it on the train to the programmers office).

Here s a discussion we found on comp.software.extreme-programming:

There are so many ways that the Customer can screw up an XP project. And there is no mechanism for:

1) Managing the Customer

2) Ensuring the Customer checks in and has clearance with his Management

3) Ensuring the Customer is correct, even if he means to be. and most importantly

4) Ensuring The Customer s mistakes don t hose the project

5) No Cover Your A$$ paper trail

Consider: Everybody s job depends on the customer (1 person) getting it right. If that in house guy does a bad job, YOU take the fall, and so does your team. That is a very high risk methodology that is out there. 15

But, you ask, what could possibly be done to prevent this sort of thing? Well, here s how it s usually done.

Developers elicit requirements from the customer(s). Then they write these requirements down in a specification. The specification is reviewed by the development team members internally until they think they ve got it pretty close to right, and then it s reviewed not only with the customer folks who provided the initial input but also with other project stakeholders. Because the specification is a document, it can be e-mailed out to people who are not colocated with the development team. After the specification is reviewed, the gold owner signs-off on it. Developers have access to the specification whenever they need it. After the system is built, the QA folks can compare the delivered system to the specification and determine whether or not the developers met the requirements. And the development team is accountable for making sure it meets the requirements.

Thousands upon thousands of projects have used these techniques. They re not perfect, they re not extreme, and they don t absolve the programmers of all responsibility, but they are intended to eliminate the single point of failure.

FANGS  

The Trouble with Customers Is . . .

The trouble with on-site customers done the XP way is that if the on-site customer is a single person, she becomes a single point of failure in an incredibly difficult, stressful, high-profile position of great responsibility.

If the on-site customer is really a team of analysts, then confusion reigns because it s difficult to get everyone on the team to speak with a single voice and not enough detail gets written down. Too much potentially architecture-changing detail is left to promises for future conversations ”but with whom?

The On-site Customer Defanged

If you have access to a single on-site customer who really understands the system requirements, go for it ”the arrangement can prove invaluable in clarifying ambiguous requirements and providing early feedback. However, don t make the mistake of using the on-site customer as a regular source of new requirements. There s no substitute for requirements that get written down in detail and signed-off in unison by the project s many masters. If project sign-off can t be achieved, then this is a major risk that has just been identified early on, rather than being left to fester, resulting possibly in a sudden inexplicable project cancellation sometime later.

If a team of analysts is providing the requirements, make sure the analysts write the requirements down in detail (not just in sketch form as promises for future conversations between the programmers and the analysts).

Also, don t assume that because a customer understands the system requirements she is skilled at project management and quality assurance and should be given responsibility for budget, schedule, and acceptance testing.

SOLUTION  

Also see the sidebar Oral Documentation Defanged at the end of Chapter 7.