How to coach developers to get a chat with their product experts

Getting these crucial chats with product experts is often a brain-teaser! Let’s show devs how to trigger short, practical, immediate Example-Mapping sessions.

Unfortunately, the tools have taken over the meaning, and I need to chant, “The card is a token for an ongoing conversation” over and over. [George Paci extremeprogramming@groups.io]

Engineers no longer can talk to users. [Slava Imeshev extremeprogramming@groups.io]

What we did was wrong. - [Note: and so we had to] Rip out the wrong code and tests and start over with the right functional test. [Steve Gordon extremeprogramming@groups.io]

Product experts are crucial… Yet unreachable!

Developers won’t do an excellent job without first-hand domain knowledge. It is no coincidence if XP recommends an onsite customer or Scrum a dedicated Product Owner.

When developers and product experts don’t collaborate enough:

• The team risks building the wrong stuff. As a result, devs will need to throw away a large chunk of work and rebuild it.
• The team creates more bugs. In the end, everyone spends more time bug fixing and less time building new features.

In the long term, these problems erode trust and leave no time for more valuable topics.

Unfortunately, it’s often tough to get the needed information from product experts!

• First, product experts are already busy on the other side of the product definition work. Spending time with developers often takes a back seat.
• Second, being experts, they forgot what it means to be new on their topic. They tend to omit many details, thinking these are obvious or that ‘everybody knows this’. Unfortunately, developers, who are not product experts, need these details!
• On top of that, they have no idea what programming is about. Product experts tend to underestimate the details that writing working software requires.

• Finally, the ‘specification’ handover mindset is still pretty alive in the workplace. Many product experts’ job is to write detailed specifications for developers to execute.

Example-Mapping injection!

Here is a recipe to get product experts involved in a conversation about a story.

Are you noticing collaboration issues between your coachees and the product experts? Here is what you can do:

1. Find 1 or 2 team members who are suffering from a lack of collaboration with product experts.
2. Make sure they are willing to experiment with you.
3. Present and practice Example-Mapping with them
4. Ask them to be on the lookout about situations that would need a product expert. Tell them to call your little group when they spot such a problem.
5. As soon as this happens:
   1. Call the domain expert as a group.
   2. Tell him you are blocked.
   3. Ask for an on-the-spot 15 minutes remote chat.
6. If he cannot right now, schedule something with him as soon as possible.
7. Use these 15 minutes to run an Example-Mapping session.
8. Help to convert the notes from Example-Mapping to automated acceptance tests.
9. Repeat until Example-Mapping becomes a habit

It’s as simple as that! Direct phone calls are still the fastest way to get in touch with someone. It’s like if bureaucracy makes us forget that! Fortunately, technical agile coaches are here to challenge the status quo 😉

An Example-Mapping success story

A few weeks ago, I worked with a team that wanted to collaborate more with the product experts. They had tried a different approach, but with mitigated results up to now.

For Example, I had helped them to run a Big Picture Event Storming a few months ago. The feedback from the different audiences showed the communication gap:

• Developers had enjoyed the Event Storming. They said it had helped them to understand the domain a lot better
• Product experts, though, estimated that they had not shared that much information!

This time, I paired with a developer to experiment around Behavior Driven Development. We started the day by calling a product expert, and we ran a 30 minutes Example-Mapping session.

At the end of this experiment, they decided not to take 100% of BDD but to stick to Example-Mapping sessions! Here is the kind of feedback that we got from product people:

I really liked behind included in the work, engineer and designer working together is still a pleasure.

I already started to look at the domain from an engineering point of view in order to improve my design thinking.

Example-Mapping is excellent at hacking more collaboration between developers and product experts.

What is Example-Mapping?

At this point, you must be wondering what Example-Mapping is? It’s a structured conversation format that was invented by the Cucumber team. It’s a way to capture the business rules and associated examples out of a story. 

It captures just-enough details for devs to build the right thing.

It’s then straightforward to convert Example-Mapping notes into automated acceptance tests. No more throwaway and rewrite, way less bug fixing… Example-Mapping is one step more towards calmer work!

In our situation, it also has many extra advantages:

• Sessions are quick. There is no need to schedule a formal meeting.
• The format is simple. We won’t frighten the product expert.
• It’s easy to learn. We can master it in 1 or 2 hours max; we don’t need to organize a long training.
• It’s remote-friendly. This makes Example-Mapping perfect for injecting in a telephone call.

What does Example-Mapping look like

Sample Example-Mapping cards on the introductory post about Example-Mapping, by Matt Wynne

Example-Mapping uses colored cards to capture the details about user stories:

• A yellow card for the title of the story
• Blue cards for business rules
• Green cards for example-scenarios associated with each business rule
• Red cards for problems or unanswered questions

With this in mind, the group simply discusses the story and tries to find the rules and examples. Everyone should bring their unique point of view to make the exchange more valuable. Someone in the group is the notetaker. This person keeps track of the conversation by writing and arranging cards on the table.

That’s almost all there is to know!

How to coach Example-Mapping

Example-Mapping is straightforward, but it still needs a bit of practice to get used to. On top of that, you want the product expert to have an excellent first experience with it.

First, learn how experts are doing.

There is a lot of existing material to learn Example-Mapping on the web. The Cucumber team created a webinar to teach Example-Mapping. The simplest thing to do is to watch it with your coachees and have a quick follow-up discussion.

You might also have a look at these other references, depending on your styles of learning:

• Cucumber’s introductory blog post about Example-Mapping
• Another blog post from them
• If you prefer to go in-depth, you might have a read at BDD Books: Discovery
• There is even a free course on Pluralsight, but I did not went through it

Would you instead give a short crash-course yourself? Here is a presentation made up by my colleague Matthieu Tournemire. We’ve been using it successfully at Murex for a few years now.

By Matthieu Tournemire and Philippe Bourgau, under CC BY-SA 4.0, Full Presentation

Second, practice!

Your coachees should now have a clear idea about how an Example-Mapping session should go. Let’s get them to practice a bit! Find a user story that one of your coachees knows well and that the others don’t. Take 30 minutes to try Example-Mapping on this story. Park any question or blocking point on red cards.

Run as many sessions as needed for your coachees to feel really at ease with Example-Mapping. It won’t take you more than 2 hours in total.

Tools

Example-Mapping was first thought of as a co-localized activity. If you are all in the same room, all the material you need is a set of colored cards and a few sharpies.

Co-localized Example-Mapping is simple, but…

• Sometimes, co-localization is not an option!
• Even if you are all in the same building, Example-Mapping needs everyone to be in the same room! This is yet another barrier to reach the product expert.

It’s effortless to run an Example-Mapping remotely! I don’t know of a dedicated Example-Mapping online tool, but here workarounds:

• An online collaborative spreadsheet might be all that you are looking for. Here is a template you can reuse. Fill any cell, and it will color according to the row’s nature.

By Philippe Bourgau, under CC BY-SA 4.0, full spreadsheet template

• An online whiteboard, like Miro, works wonders to simulate cards.
• Last, one of the significant advantages of using real cards and pen is that you can draw! A picture is worth a thousand words. It’s not a surprise that drawings are great for capturing scenarios. If you have a device that lets you draw well enough, then, by all means, use it!

Don’t forget to share the screen so that the product expert can see what is being captured. The above tools also enable collaborative editing. Once everyone is used to the format, it’s better to share the link instead of the screen!

Give it a try!

Keep your ears open when you are with your coachees. Next time you hear someone having troubles understanding what they are supposed to do:

• “I don’t understand the specs!”
• “I have no specs!”
• “I don’t know how to test this story!”
• “Jim (the product guy) is never available!”

Try to get them into trying Example-Mapping with the product expert.

There is more to Example-Mapping than what I quickly presented. For Example, you can also use it to…

• Detect stories that are not ready.
• Detect stories that are too big and split them.
• Write and automate Gherkin scenarios.
• …

If you have questions about Example-Mapping, don’t hesitate to ask! I’d also love to read how your own experience went: the comment section is yours.

---

Here are other posts that might interest you:

• Organization refactoring: Event Storming and DDD injection. It presents a ‘refactorging’ technique to introduce Event-Storming after Example-Mapping
• 5 Views to Capture the Outputs of an Event-Storming workshop. It explains how to use Example-Mapping to capture the outputs of an Event-Storming workshop
• First rule of DDD is: let’s not talk about DDD. Fun infographics explaining that it’s better to do DDD instead of frightening people with it
• Event Storming lessons from Post-It haters. A reflection about why stickies are so effective for group collaboration

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!