I n t r o d u c t i o n s

1. Programmers are from Mars, Customers are from Venus:A practical guide to working with customers on XP Projects A n g e l a M a r t i n . R o b e r t B i d d l e . J a m e s N o b l e

2. I n t r o d u c t i o n s • … and you … Angela Robert James

3. O v e r v i e w • We expect that by the end of this tutorial you will have gained: • A realistic understanding of the complexity and difficulty of the XP Customer role. • An understanding of the key roles required on a customer team, both what they are and why they matter. • An understanding of the nine practices that enable customers to sustainably drive XP projects to successful completion – think “XP practices” BUT for customers.

4. A g e n d a Introduction (15 mins) The XP Customer Game (60 mins) Reflection (15 mins) Customer Team (30 mins) Break (30 mins) Customer Practices (50 mins) Summary (10 mins)

5. I n s t r u c t i o n s • The Goal: • To allow you to explore the issues faced by a customer on an XP project in a dynamic, light-hearted and fun way. • The Set-up: • Divide into groups of 4 or 5; • Nominate someone to be the customer (our suggestion – nominate someone who isn’t typically a “customer” or analyst) • Everyone else will be the programmers • The Task: • Develop a 5 minute presentation (for a book proposal) with visual aids covering your best & worst customer experience

6. G a m e p l a y T i m i n g • The customer has 5 minutes to write stories • An XP story is typically written on an index card and describes what the customer needs; but it is not a completely detailed requirement, rather it is a “promise for a conversation” between the customer and developer • The group should set aside 5 minutes to plan the iteration • During the XP planning game the customer describes the stories, the programmers estimate the stories, and finally the customer decides what to do in the time available • … and 20 minutes to “develop” the visual aids

7. T h e R u l e s • Only the customer can talk to the “Big Boss” • Only the programmer can “develop” visual aids • Once the planning game is complete, each programmer should: • Pick up a card, • Follow the card’s instructions • Once complete, pick up the next card … (and repeat) • The customer should be available to the programmers throughout to ensure their visual aids are ready for their presentation at the end

8. G a m e • Goal of the game • Walk a mile in customer’s shoes !! • Mechanism • To develop a 5 minute presentation (for a book proposal) with visual aids covering your best & worst customer experience • Timings • You have 5 mins to write stories • You have 5 mins to plan the iteration • You have 20 mins to develop the “visual aids” • Remember • Only the customer can talk to the “Big Boss” • Only the programmer can “develop” visual aids

9. So, how did that work for you? • — “Dr Phil”

10. T h e I s s u e o f O v e r l o a d • “I think it’s worked very well, but … I don’t know how long [I can] keep this pace up” • Customer, EagleCorp • ““Overall – I love this approach to development and I’d certainly like to use it again in any future projects I am involved in … • … We probably needed about three of me … it’s been my life for about a year … look at these grey hairs” • Customer, KiwiCorp • Visionary of start-up: “I’ve always worked at least 70 [or] 80 [hrs a week] I don’t even mind it, its like what I do” • Customer, RavenCorp

11. So, what is the solution?

12. The Solution • — We are proposing based on our research and experience

13. This section outlines the nine key roles on successful customer teams that are: Programmer facing Organisational facing Skill support … and the identified customer lead (On-site Customer) T h e C u s t o m e r T e a m

14. G e e k I n t e r p r e t e r • H3Y D00DZ, L3TZ C0D3 UP SUM ST0R1Z • Customers who are not themselves (ex-) programmers often lack expertise in the jargon of programmers • The Geek Interpreter provides a “sounding board” or sanity check for the customer

15. T e c h n i c a l L i a i s o n • Most projects don’t exist on their own • They have to deal with existing organization technical infrastructures • Customers who attempt to deal with all of the technical liaison quickly become overloaded • This liaison task deserves a person to be responsible for it

16. P o l i t i c a l A d v i s e r • Customers are project focused and so cannot be involved in organization politics • Customers need help to identify players & rules • Who needs to say “yes!”, Who needs to stop saying “no!” • Which rules to follow, Which rules to break • The Political Advisor(s) works with the customer to ensure they succeed: • This role is always unofficial and a wise customer will find political advisors they can trust quickly

17. A c c e p t a n c e T e s t e r • Acceptance testers are found as assistants to Customers on almost all large standard contemporary XP projects • Original XP had programmers seconded to customer • But … real testers understand testing, are good at it, and take the customer’s side!

18. U I D e s i g n e r • Programmers focus on the system model • UI Designers focus on the user model • …to design tothesystem image (UI) • So the UI needs its own big picture • So UI designers need to introduce requirements by being on the customer team

19. T e c h n i c a l W r i t e r • XP downplays technical documentation but user documentation is still important • User documentation requires a special skill-set • Real technical writers end up on customer teams • Technical writers love Agile Development • At least I’ve got something to write about from the start

20. D i p l o m a t • Customer teams require organizational representative(s), including: • Subject matter experts • End users • Senior stakeholders • Architects • They are responsible for representing their organizational area or perspective on the project • The people fulfilling this role may be full-time or part-time

21. S u p e r - S e c r e t a r y • Is intimately familiar with the stories • Write down the stories • And keep them organized! • And track the stories through their lifecycle, often with a sticker system with different colors representing each stage • Follow up the story status with the programmers • Supports the customer team with all of the non-story tasks too • For example, organizing meetings

22. N e g o t i a t o r • The On-site customer is always identified on the customer team • Characteristics of successful customers: • Good (active) listeners • Confident & decisive • Comfortable working at the “big picture” and detailed levels • Know their limitations and work with a customer team • Handle intense pressure … workaholics should apply! • Recognize multiple perspectives exist … and help them see each other’s world • So we are considering renaming the role to Negotiator

23. C u s t o m e r P r a c t i c e s • Customers need to adopt practices to manage their relationships with • Programmers • Stakeholders & the big bad world outside • Customer team

24. P r o g r a m m e r O n – S i t e • Programmers need to understand and respect their users • Very old advice – get the programmers into the field: • “Boeing offers all its avionics programmers seats on an early test flight” • “I worked with a social worker, doing a death review. This is what she does every day” • Not about making decisions! • Understanding the end user and context of use • Making your suggestions actually helpful

25. C u s t o m e r A p p r e n t i c e • Programmers need to understand the customer • “To understand someone, walk a mile in their shoes” • So, rotate programmers to act as the Customer Apprentice: • Writing stories, being secretary • Attending meetings with users & stakeholders

26. P r o g r a m m e r H o l i d a y • XP is intense; Sometimes Customers just need more time to get ahead of programmers. • … The stay ahead dynamic is REALLY important • Customers sometimes need to send the programmers on holiday • For example, an iteration focused on technical refactoring / debt

27. S t o r y S t a n d a r d s • Use a common template for every story: • “persona needs something so that goal achieved” • focus template on acceptance tests (goal) • Customers need to take time to get stories right • Story decomposition is hard • Need to handle exceptions • Need to iterate

28. S h o w & T e l l • Show the sponsors return on their investment • Programmers learn from user/sponsor reactions • Sales & Marketing needs stuff to show • And to bring feedback • Customer needs artifacts to ground negotiations • Working software helps us discover our future direction

29. C u s t o m e r p a i r i n g • If Pair programming is good – pair customering must be good! • It works for the CUSTOMER • In every case we’ve found • Programmers can get uppity about this • Programmers often prefer one customer to another • Programmers play customers like divorced parents

30. C u s t o m e r p a i r i n g • Techniques for managing customer pairs • Divide by functional area • “Along the grain of the domain” (Brian Foote) • Divide geographically • Distributed projects • Most extreme: like pair programming – don’t divide! • Close working relationships are key to any division of the customer role

31. C u s t o m e r C o u n s e l o r • It is a lonely and intense role that we know has “caused” burn-out • A Customer Counselor (think ST:TNG) provides professional support to customers • “Tell me about your problems…” • Programmers get a coach • Customers need someone too!

32. C u s t o m e r C o u n s e l o r • Customer needs: • Someone who is not on the project • Someone who is not a manager • Someone with enough IT & business experience • Someone who will not try to solve their problems • Someone whom they can trust • The Customer Counselor meets the customer: • Private place, completely confidential • Regular, but variable to suit customer • If customer gets stuck can call counselor straight away • The coach and the counselor could be the same person … but the skill-sets are very different

33. L o o k B e f o r e Y o u L e a p • We still need a business case • We still need release planning • The thinking behind what an organization needs • Typically 2-4 weeks of customer-led analysis workshops • Include 1-3 programmers to create a shared understanding and keep the sessions grounded in technical reality • The output of release planning are prioritized and estimated stories with an initial plan • We need to do just enough analysis up-front to make decisions and set expectations

34. T h r e e – m o n t h C a l i b r a t i o n • After three months, projects realize that their eyes were bigger than their stomachs • … And they aren’t going to deliver everything they promised. • During the crisis period: • productivity drops and • morale drops

35. T h r e e – m o n t h C a l i b r a t i o n • We recommend that we all: • Consider planning for this • We must be more upfront about this • We must be more upfront that customer won’t get everything • We must be prepared to embrace change • They will get something but there is no guarantee that it will be enough

36. S u m m a r y • “The customer is Kent Beck’s fantasy • Santa Claus, The Easter Bunny, Monty Hall, • Jeeves, Martha Stewart (pre-incarceration) as the mother of a five-year old” • Canadian XP Expert • “The Customer is anAbsence, a hole, a nullity. The Customer Does Not Exist • New Zealand XP Expert • “But I wouldn’t do it any other way” • NZ XP Customer