Agile 2006: Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle

Wednesday 13:30-17:00

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.

Geek Interpreter
This person helps the customer to understand the programmers. This is probably not a full time job.

Technical Liaison
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.

Political Adviser
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.

Acceptance Tester
This person works to support the customer and define acceptance tests.

UI Designer
This person designs how the system looks to the end user, which creates requirements for the system itself.

Technical Writer
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

Agile 2006 – A Story of Stories – David Hussman

Sunday – 13:30-14:15


How to collaborate and write effective user stories.

Requirements gathering has evolved over time into the form of use cases. Good use cases are short, simple, focus on the use cases and stay current through continued collaboration. Bad use cases replace collaboration, are long and expensive to write.

Burying requirements in long documents doesn’t work. People can’t find or estimate them. Testers, developers and customers interpret them differently.

As an alternative, collaborate to write small, short chunks of work as user stories. Write them down on 3×5 cards and post in a common area for easy access. Let the customer say what done means – and write it on the cards as acceptance tests. In a healthy community, everybody writes the stories.

Hold “story jams” to create the stories (think like music jams – let the creativity flow). Use a long table and invite lots of people. Create personas, and walk through a day in their lives. The list of stories doesn’t need to be complete after the story jam.

Good user stories conform to the INVEST acronym:

  • Independent – breaking dependencies increases agility, so that the business can choose the really valuable stories.
  • Negotiable – they can be changed. Build a ubiquitous language, so that everybody knows what the story really means.
  • Valuable – in terms of the customer, or whoever it’s being built for.
  • Estimable – sized appropriately for accurate estimates.
  • Testable – it’s a story smell if they can’t be tested as done.
  • User stories work because they are available, they bring people together, build trust, promote innovation and are humane. Stories are completed only when the customer signs them off.

Key points to put into practice

  • Review user stories against the invest acronym.
  • Create personas and walk through a day in their lives.
  • Don’t focus on completing ALL of the stories in a story jam.

Recommended further reading

Being Jane Malkovitch – the Life of an XP Customer (included in conference materials)

The powerpoint presentation contains photos and examples of personas, story jamming, and further explanations.