Building Trust

I l @ ve RuBoard

As you can imagine, all of these problems contributed to a complete lack of trust and respect on both sides, which gave the Web industry a clear challenge: How could it avoid all these problems?

A Customer Bill of Rights

A good relationship with a customer is based on trust. By following XP best practices, we can build that trust and avoid most of the problems just discussed. With Web XP the customer will become more involved in the project and will be able to make decisions along the way. The iterative nature of XP allows customers to trust you for a couple of weeks at a time. Being fully involved in the planning process, they know what you are going to do and why. They also have greater influence over what is done, and when, than ever before. In the process they learn about how quality, scope, price, and time are interconnected and they , not you, start making the trade-offs.

Customer participation to this degree amounts to a customer Bill of Rights, first put forward by Ron Jeffries, one of the early pioneers of XP. The following sections describe a practical Bill of Rights for Web projects that helps build and maintain trust.

The Right to an Overall Plan

Customers have the right to a release plan that outlines what can be done, when, and at what cost. ^[1] They have the right go through the development of that plan with you. How do you get customers and developers to agree on what is included in a project? You develop iteratively and agree in small pieces. This means developing a plan for every iteration of work. The iteration plan has to be detailed enough to describe what is to be done, when, and for how much. ^[2]

^[1] See Chapter 4 for a full discussion of release planning.

^[2] Chapter 7 contains a full treatment of the iterative process.

The Right to Make Changes

Customers will change their minds ”substitute functionality and alter priorities ”and shouldn't have to pay exorbitant prices to do so. It is the nature of any Web project that, before the Web site is launched, something will change that. At the beginning of each iteration, give the customer the opportunity to change direction by requesting new stories or reevaluating story priorities. (See Chapter 7.)

The Right to Get Value

Customers should receive the greatest possible value out of every development week. While they are paying for your time, they are also paying for your experience and good-quality work. Engage customers in the process ”let them see what you are doing.

The Right to See Progress

Customers should be able to view a running system at the end of each iteration. At the beginning of each iteration, a set of stories is approved. For each story a provable deliverable is defined, which is what the customer will review at the end of each iteration to determine that the story is complete. This can be done by running the code and having it pass repeatable tests.

A customer Bill of Rights breaks down the walls between the customer and the team and builds trust.

The Right to Be Informed

The project manager and team members should have regular access to customers in order to keep them informed. Communication is critical to the project, as it gives customers a chance to become more involved in development of the Web site and therefore more able to make key decisions along the way. Don't hide from customers. Keep them involved in everyday project development. If something comes up tell them right away; don't procrastinate. It is their right to determine the impact of a problem, and only they can say what an acceptable solution should be.

The Customer Bill of Rights as a Selling Point

A customer Bill of Rights makes an excellent selling point for any Web developer. It sends two important messages to a potential customer:

• You are confident in the abilities of your company to deliver a good product.

• You respect the customer's expertise in his own business and value the contribution he will make to the project.

I l @ ve RuBoard