Peer To Peer Proposal
Title
Stop interacting with the customer! (...until you know the safety rules.)
Topic summary
Pivotal to all agile methods is the notion that customers work closely with the development team. Regardless of the excellent customer interaction techniques you've learned elsewhere, you will not be successful until you have established a working relationship. As with any relationship, things can go wrong.
Developers and customers talking, isn't that dangerous?
Why yes, that might be dangerous.
In this peer to peer session, we will learn to navigate the pitfalls in customer interaction. Endowed with a few simple guidelines, techniques, and knowledge you and your budding agile team will have the courage to be more involved with customers.
Duration
90 minutes
Audience
- Those who interact with real customers.
- Those who are afraid to interact with customers.
- Those with unsatisfying customer experiences.
- Those who have taught customers how to interact with agile teams.
Goals
Using the experiences of the attendees, we will create two lists:
- Pitfalls experienced in agile customer relationships and
- The rules of engagement that support developers and customers.
These lists and the discussion which created them will help the attendees feel comfortable initiating contact with real customers, regardless of the experience of their teams.
Process
The format for this session is a highly interactive and collaborative peer-to-peer. If fewer than 15 people, it will take the form of a moderated roundtable, where all issues are presented to the entire group. Otherwise, it will proceed as follows:
1. Introduction
2. Participants brainstorm their customer interaction fears and experiences to 3x5 cards
2. Refine and focus brainstorming ideas into "Pitfalls of Customer Interaction"
- Divide into groups of 2. Each person reads and explains the context of their cards to the other. Together they choose the top 3 cards.
- Groups of 4-6 are formed by combining 2-3 pairs. Top 3 cards from each pair are read and explained to the group. Duplicates are eliminated, and the top 3 from the group are chosen. A presenter is chosen to elaborate on these 3 cards to all participants in the session. Again, the group chooses the top 3 from among those presented.
- Each presenter presents the top 3 cards to the group. As presented, each "pitfall" is recorded on a large "sticky" sheet of paper. After all are presented, duplicates are consolidated, questions are fielded and the list is congealed.
3. Develop Rules of Customer Engagement
- On a second large sheet of paper, ideas of how to best mitigate each "pitfall" are recorded. This proceeds on a new sheet of paper for each "pitfall" until all are explored.
After reviewing & clarifying all responses, these sheets become the "customer rules of engagement".
4. Wrap up
- Each participant is given 30 seconds or less to share what concept or insight was most important to them.
Deliverables
Participants will produce:
- "Anti-patterns" (or pitfalls) of customer interaction
- "Rules of engagement" for customers and developers
- And a tacit understanding from the discussion of what effective interaction patterns apply to them
Session Leader Resumes
Zhon and Jeff have taught, led, and moderated successful agile customer interaction for companies ranging from small start-ups to large enterprise software companies.
Jeff Grover has worked in the software industry for 14 years and is currently a Principal Engineer for Symantec's enterprise security products. He has participated in 'Extreme Fishbowl' presented at XP/Agile Universe, UJUG, and XPUtah. He represented Symantec on the Agile Experiences panel of XP/Agile Universe 2002.
Zhon Johansen co-founded Acadyn, a company helping small businesses with IT and information security needs. He has studied, practiced, and taught Extreme Programming since early 1999. He also co-founded XPUtah (http://www.xputah.org) in December of 2001. He organized and presented 'Extreme Fishbowl' to XP/Agile Universe, UJUG, and other conferences. He also helped coach 'XP for a Day' presented at XP/Agile Universe.
Zhon & Jeff both presented "Making money with (or without) software" at the 2004 Agile Development Conference.
NOTES
What is the objective?
- Create a set of rules for developer-customer engagements
- Change the world by giving developers permission to talk directly to customers
Who is our audience?
- Programmers, Testers, Product Managers, Project Manager, UI Designers, Customers.
What is the strategy or game plan?
What is the hook?
"Don't just understand the customer, be the customer". "I'd love developers to talk to customers... Wouldn't that be dangerous?"
What is the subject?
- What preparation should be done with the team? How should a software team interact with a single, real customer? How should the team select the customers they speak with? How long should any single interaction last? How often should the team meet with the customer? Who else should the team meet with? Sales, marketing, tech support, senior executives, focus groups. What is the agenda for this interaction? Introduction, customer speak, ask questions, agile wrap up.
What should we ask for?
Contributions, an email, interacting with the group, try it and report
What picture should we paint?
stories, role play, charts with lists
What is the agenda?
How long do we want? What is the schedule?
- 1 Ask, don't tell (ixnay on project plans) 2 Pointed, open-ended questions 3 Agile Roundup
Zhon will be adding to this page <I hope>
Customer "spying" = interaction?
"Exercising your mirroring neurons on behalf of the customer"... http://www.infinityinst.com/articles/mirroring.html
Part of an email ZhonJohansen sent to LisaCrispin:
We feel very strongly the *rules of engagement* between customers and programmers is important. People are asking us how:
"Agile tells us to put customers and programmers together, how do we do we get started?"
"Wouldn't that be dangerous?"
"Once we have them together, what should we do?"
Our techniques and rules have been successfully used. We would like a PeerToPeer to define and clarify the *rules of engagement*. I am a little worried the topic might be mix in with effective, agile requirements gathering (for example Jeff Patten or Luke Holman's work). It shouldn't, but if you think the topic might be reject because of classification, please let me know and we will choose a different topic or rename this one.