How to run Specification by Example remotely

One of the best things about Specification by Example is how it allows a group of people to quickly get to a shared understanding, and collaboratively discover and define exactly what they need to build. Specification workshops are the most effective when everyone is in the same room and has access to the same information. For better or worse, that’s impossible to do in most countries around the world at the moment. So here are some tips on getting the benefits from spec workshops without having to be in the same place.

For remote work where everyone is in a different location, the key constraints for the facilitator are engaging everyone in the discussion and keeping the conversation going without visually observing the whole group. Although group video-conferencing tools have advanced significantly in the last few years, allowing multi-screen and multi-camera views, the view is significantly more filtered compared to a group in a big room with a large whiteboard. Mostly you can see people’s heads, and not what they write, observe or touch. The flip side is that you can engage much larger groups over a video link than around a single whiteboard.

# Preparation

For remote spec workshops, the preparation is almost the same as for a large in-person workshop, but there is less opportunity to improvise and experiment on the spot. The facilitator needs to choose a set of topics upfront, and ideally come up with some initial examples that would reflect the scope of each important topic.

Matt Wynne’s Example Mapping is a great way to break down the scope of a large story and identify the key questions you might want to discuss with examples. If you need to facilitate a specification workshop with a smaller group, you can start directly with an example mapping session. For larger groups, you probably want to do an example mapping session with a smaller group, maybe one key representative of each role involved in the delivery. This will help set the scope for the larger group conversation.

I suggest using audio-conferencing with screen share, ideally some collaborative way of note-taking. We tend to use mind maps when discussing topics, other people use Excel/Google Sheets or some type of online whiteboard. Collaborative editing will be better than passive screen sharing as more people can join in, but it’s not critical. Watching people’s faces during a scoping discussion is nice, but if you have to choose between observing people and observing content, go with the content.

# Discussing examples

Once you have a set of topics, and some key examples and questions about each one, organise a discussion on each of them in sequence. Remote discussions generally require a bit more structure than in-person ones. I suggest using the modified _Commander’s intent template_, proposed by Gary Kein in Sources of Power. (I wrote more about this in How to develop software like commanding a tank in 2006).

• Here’s what I think we face
• Here’s what I think we should do
• Here’s why
• Here’s what we should keep our eye on
• Now, talk to me

With groups physically present, I usually suggest facilitating these discussions in Diverge/Merge cycles where each group goes through simple examples, leading to a structure, then doing boundary analysis. (If you attended one of my Specification by Example workshops, is the famous „algorithm” I talk so much about). Some video-conferencing solutions support dynamic breakout rooms, so you can in theory simulate this experience remotely, but I would not suggest that. The critical aspect of Diverge/Merge workshops is being able to quickly identify and compare differences between groups visually, which is often not possible on small screens.

For the discussions, the facilitator should introduce a topic quickly with basic examples, potentially presenting some key open questions, then letting people suggest additional ideas until a clear structure emerges for the group of examples (That’s one of the reasons why I don’t like starting with excel, it constrains the structure too quickly). When a participant has a question, ask them to propose an illustrative example that shows the potential uncertainty well.

After a few minutes of discussion, you should see a common structure among the examples. Prepare for the boundary analysis by restructuring the data on the screen, so that there is a clear relationship between inputs and outputs. Don’t waste time on making this too formal (proper Given-When-Then syntax is too much at this point).

# Boundary analysis

With physical meetings, groups usually do boundary analysis as a quick informal discussion, and the facilitator picks conflicting examples and invites people to explain them. With remote participants, you can’t do that easily. The key risk is that people don’t engage fully in thinking about individual examples, since you won’t be able to pick and choose participants that look confused or strongly convinced easily.

Instead, I suggest doing boundary analysis by inviting participants to list inputs and do not provide their opinion about the outputs and outcomes yet. (That’s why it’s so important to have a good structure of inputs and outputs for examples before this step). Then the facilitator should choose some examples from the group to run feedback exercises, to discover differences in understanding and further topics for discussion.

If you participated in one of my workshops, feedback exercises were those parts where everyone wrote their opinion on a sticky note individually, then we compared the results and looked for differences. Remotely, you can ask people to write down the outcome on a piece of paper and keep quiet about it. To speed things up, you can do so even for a whole group of examples instead of doing them one by one. As a facilitator, you can then ask someone to say their answer out loud and ask other people to complain if their answer is different. Then discuss the differences, and either get the decision makers to provide an answer, or note the example as an open question for follow-up discussions if nobody in the group can provide a definite conclusion.

Using screen-sharing or collaborative document editing is very helpful at this point since you get meeting notes for free. However, actually watching people’s faces during the boundary analysis might help you identify further misunderstandings, or pick better people who need to explain their opinion.

# Share the experience

Finally, it’s worth noting one more rule, that Chris Matts recently wrote about in the Spec by Example mailing list. „One golden rule for distributed meetings is everyone should have the same experience”. Make sure everyone has access to the same visual or audio features. Some people contribute over screen sharing with other people just dialling into audio is a great way to make people feel isolated and left out, and miss out on important discussion hints. If your goal is to reach a shared understanding, start with a shared experience.