Being an XP customer is a lot of work, but this can be separated into roles and split among multiple people. There are also practices that can be used to make the customer’s life easier.
Of the entire conference, this was probably the session that gave me the most practical tools to take back to my team, and in the most straightforward way.
It’s a lot of work being a customer in an Agile project. Rather than heroic programmers, we’ve moved towards needing a heroic customer – there’s a lot to do and it can be exhausting. Many customers need to be available to the programmers to answer questions when they are needed, but still have to fit in their other work. However, most customers agree that the reward of having working software every iteration does make it worthwhile, so how can we redress the balance?
The customer role can be divided into nine sub-roles to form a customer team. One person can take on more than one role, or they can be taken on by different people.
This person helps the customer to understand the programmers. This is probably not a full time job.
Almost no software development project is new, so there is a need to integrate with existing organization technical infrastructures. This role takes the responsibility for making sure that the integration happens in a sensible way. It may or may not be a full time job, depending on the business.
This person helps the customer to get agreement from others in the organization. It’s always an unofficial role, to help the customer get through organization politics.
This person works to support the customer and define acceptance tests.
This person designs how the system looks to the end user, which creates requirements for the system itself.
This person creates the documents required for the end users of the system.
This person supports the customer in the organization, talks to the people who “matter” and report back.
This person completes the administrative work necessary to support the customer.
This is the traditional customer role. This person must be flexible, agile, and decisive; able to work at the big picture and detailed levels. The Negotiator is the point of contact for developer questions, although would likely field these to the acceptance tester.
There are also several practices that can be used to support agile customers:
- Programmer on-site – to help programmers understand the users better.
- Customer apprentice – to help programmers understand the customers better.
- Programmer holiday – allow the team to spend a week or an iteration focused on technical debt, refactoring, or spikes – while the customer has time to catch up.
- Story standards – common templates for the stories.
- Show and tell – to show the sponsors the return on their investment.
- Look before you leap – create a business case for the features, and use release planning.
- Be prepared for the “three month crisis” in long term projects, when they realize “their eyes were bigger than their stomachs”
- Plan for this and be upfront when things slip
- Customer pairing – divided geographically, or by functional line
- Customer counselor – to allow venting, and to coach the customer