The bulk of the first half of the session was an extended planning game, with several elements of chaos thrown into the mix. The intention was to give us all a good idea what it was like to be a customer. From the reactions indicated by many, the feeling wasn’t exactly pleasurable.
The answer being proposed by Angela, James and Robert was to build a customer team, in some ways reflecting the XP development team.
The Customer Team
UI Designers – Programmers focus on the system model, UI designers focus on the user model to design the system image.
Super Secretary – intimately familiar with the stories, writes them down and keeps them organised.
Negotiator – The on-site customer.
Most of these are meant to be roles, rather than individual positions. The ideal customer people should have people doing all of these roles.
The Customer Practices
The customers need to adopt practices to manage their relationships.
Programmer on-site – Get them to understand and respect their users, and to understand the context in which the software is used.
Customer Apprentice – Have a developer writing up their stories, acting as their secretary, attending meetings with users and stakeholders. Have them walk a mile in the customers shoes.
Programmer Holiday – Customers sometimes need to give the programmers a project holiday, perhaps give them an iteration where they focus on technical refactoring/debt.
Story Standards – Use a common template for every story. Remember that customers need reasonable time to get their stories right.
Show and Tell (Demo) – To the customer. Programmers can learn much from user/sponsor reactions to their software. Also gives useful material for sales and marketing to use.
Customer Pairing – Yep, just like with pair programming, it can be beneficial to have a pair of customers dealing with the developement team.
Customer Counselor – Provides professional support to the customers. Just as XP programmers should have a coach, customers need one too. Should be outside the project, and not a manager.
Look before you Leap – Do just enough analysis upfront to make decisions and set expectations. See also Agile, Lean methodologies for more of this. Maintain continuous analysis throughout.
Three-Month Calibration – After three months, projects usually realise that their eyes were bigger than their stomach. During this crisis period, productivity and morale can drop. Need to be upfront when this happens, and prepared for it, be ready to change scope and embrace change. Possibly similar to the lull you get after starting a new job, once you’ve had your training and got used to things, round about the same sort of time people often find themselves suffering doubts as they assess the job properly, before building up again to fulfil themselves in it.
So what did I think?
I think some people, including myself, were put off slightly by an over-long and somewhat chaotic exercise at the beginning (although as I said, the chaos was intentional). However the second half had a lot more meat in it, definitely worth looking at your relationships with your customers, and seeing if they measure up to this sort of ideal. Chances are you could be a long way short, and keeping some of these in mind could help.