Chapter 6. The Workshop Format

You can use Domain Storytelling just as a graphical notation. But it is much more than that. It is a method for having meaningful conversations about business processes. That’s why you typically don’t do it on your own. The most important factor is having the right people in the room. When you have the real domain experts in the workshop, with Domain Storytelling you will gain insight into their knowledge.

Before the Workshop

The time you can spend with domain experts is usually scarce. A bit of planning may therefore be in order to make the workshop an exciting experience for everyone and to achieve a good result.

The workshop brings together what belongs together: people who want to exchange knowledge using Domain Storytelling for a specific purpose. The purpose is so important that we have dedicated the whole Part II of this book to it. The purpose also determines the granularity of the stories (see Chapter 4, “Scope”) and affects the mix of participants.

When we are brought into an organization to moderate a Domain Storytelling workshop, it is usually because one person (from business or IT) has invited us. Let’s call that person the host. The host is the one who organizes the meeting and invites the participants. The host usually has some idea of what should be modeled. In our experience, however, certain questions and topics will always be important. A moderator can help the host by asking questions like these:

• What questions need to be answered?

• What are the biggest problems?

• Who is involved currently to try to solve these problems?

• Whose perspectives need to be considered? Who should be involved in the host’s opinion?

• Which key activities are at the core of the organization?

The host and the moderator should then clarify key activities, use cases, or business processes they want to cover. In a workshop, not just one but several domain stories are told and discussed. Decide what the scope (or scopes; see Chapter 4) of the domain stories should be. The answers to these questions will also help them to choose the right participants.

Inviting the Right Participants

Having the right people present is crucial and therefore needs particularly careful consideration. This is something that Domain Storytelling shares with other collaborative modeling methods.¹

¹ If you are interested what other authors in the collaborative modeling community suggest, check out Alberto Brandolini’s Introducing EventStorming [Brandolini 2021] and the Visual Collaboration Tools book curated by Kenny Baas-Schwegler and João Rosa [Baas-Schwegler/Rosa 2020].

Who are the right people? In some cases, a single person is able to tell a whole domain story. But usually, nontrivial business processes require cooperation. Several participants should therefore contribute so that the domain story embodies the shared understanding of its narrators.

Do not let yourself be limited by organizational boundaries. Especially for domain stories that cover business processes from beginning to end on a coarse-grained level, there is usually no single person who is an expert on the whole process.

In organizations in which the domain knowledge is divided into silos, it is necessary to invite experts from each silo and get them all to contribute. Gaps and connections between silos will be discovered.

Also, take care to invite real experts—people from the trenches—and not proxies who know the domain from hearsay. Workshop participants generally include the following:

• Storytellers—people who can share knowledge (often domain experts from several departments)

• Listeners—people who want to learn (often development teams)

• A moderator and a modeler who facilitate the workshop

• The host

In the end, all participants will take away new insights from the workshop, no matter if they were invited to share, to learn, or to facilitate.

If you are building a product for many customers, you would usually be faced with a challenge: It would be great to have your customers’ view represented in the workshop, but you cannot simply invite a few random customers. In this case, we recommend that you invite a domain expert who works directly with customers (e.g., someone from customer service, sales, etc.) or who has information about customer behavior (e.g., someone from the business intelligence or analytics teams).

In organizations that operate legacy software, the developers who maintain these systems can give valuable input and should be invited to participate. Their views are important not just because they know how to program or administer a database. They sometimes have a more holistic view of the business than domain experts who were trained for years or decades to think within the boundaries of their departments.

How Long Will It Take?

With a little experience, 30–45 minutes can be enough for one COARSE- or FINE-GRAINED AS-IS story. TO-BE stories often take longer, because they are basically design sessions and involve a lot of discussions.

We recommend 60–90 minutes or 2–3 domain stories in 1 session. Continue only after a break or in a follow-up workshop. The length of a workshop would likely be limited by the availability of the people you want to invite. Sessions of two hours, half a day, or a full day can all work, depending on the context.

Preparing the Room

To get a good conversation going, we want to gather people as if around a campfire. For that, we need a pleasant atmosphere and the right setup in the room.

The ideal is the so-called Stonehenge setup or horseshoe setup (see Figure 6.1): The participants form a circle that is open on one side. This way everybody can see and hear everyone else. From the open side, “the sun will shine in”—that’s where the whiteboard or the projection screen (the modeling canvas) goes where the domain stories will be drawn.

People can stand or sit on chairs, beanbags, or whatever your room provides. Tables are not required (and in fact are rather a hinderance). Of course, a table with coffee and cookies makes for a welcome change (especially in companies where people aren’t used to being catered to).²

² On the importance of breaking bread together, consider the pattern “Do Food” in More Fearless Change [Manns/Rising 2015].

It is important that the depicted domain story is always visible to all participants. The number of participants is therefore limited by the visibility of the story. This affects the choice of the tool you use to record the story (see Chapter 5, “Modeling Tools”). If you use a software tool, use a projector to share the moderator’s screen with everyone in the room. Only then is a computer allowed, and only for the moderator.

A remote setting requires different preparation—please see recommendations in the upcoming section “Remote Workshops.”

The Workshop

When everybody has found their place and some icebreaking chit-chat has taken place, the moderator opens the actual session. The moderator briefly outlines what is going to happen. This is the right time to clarify the workshop’s goals, scope, and content.

Next the moderator explains the agenda. We recommend you write it on a flip chart next to the modeling canvas. Typically, the agenda will change again during the workshop.

After the introduction, the moderator motivates the participants by asking, “Please tell me your story!”

Storytelling

During the workshop, the moderator needs to steer the storytellers in the right direction to ensure that their contributions serve the overall purpose. Domain experts are not always born storytellers. The crucial prerequisite for good storytelling is a skilled storyteller. That’s why the moderator keeps the participants’ story going by asking questions like these:

• “What happens next?”

• “Where do you get this information?”

• “How do you determine what to do next?”

• “How do you do that?”

Engage the participants without imposing your opinion on them. Use the language of the participants, not your own!

Sometimes, activities seem to lack an obvious purpose. It is important to understand why activities are carried out in order to later design useful software and processes (see Chapter 11, “Working with Requirements”). The answer as to why something is done a certain way often reveals serious problems with current processes or how they are supported by software:

• “That is the way we have always done it.”

• “I don’t know why we do that.”

• “We have been assuming that this is necessary for the folks from the other department.”

• “Because the software forces us to do it this way.”

You might have to ask why repeatedly to get to the bottom of the problem.

Graphical Recording

As the participants tell their story, the moderator records it graphically—step-by-step, thus determining the pace of the storytelling. While recording, the moderator should retell the sentence that they are modeling. To make sure that the actual terms from the domain language are used, confirm by asking, “Is this the right term?”

In addition, the moderator should introduce an icon when it first appears in the story: “I will use this receipt icon to represent the ticket.” The participants see what gets recorded and can give immediate feedback. Most of the story should be presented in the pictographic language, with some textual annotations—not the other way round!

Try to avoid plot holes in the story—identifiable by parts that are not connected by arrows (see Figure 6.2).

You can see that the story in Figure 6.2 jumps from the moviegoer to the usher. How does the usher get the ticket? Is the ticket checked before or after the moviegoer enters the building? With some experience, you will come to realize that the pictographic language helps you to ask the right questions: “Who does this?” “How do they know that they have to do this now?” “How do the actors communicate with each other?”

When participants tell their story, they are likely to complain about something: “This goes wrong all the time!” “We have had this problem for years!” Although this is not exactly part of the story, it is valuable information that is worth making a note of. If you have chosen a whiteboard with sticky notes, use a sticky note in a different color to highlight pain points.

It is also important to check that the scope of the story is consistent (see Chapter 4).

When You Are Stuck

This section addresses obstacles and how to overcome them.

If you get stuck right at the beginning, consider starting the story differently. Try to replace the beginning of the story with an assumption. In the cinema example, you could suggest: “Let’s assume that you have already decided which movie you want to see. How do you buy the tickets?”

There are some common pitfalls that will make you feel like you’ve lost control of the story:

• Are you mixing story lines? Stick to the story—there should always be just one story line.

• Are you mixing AS-IS and TO-BE processes? Decide what you want to model and focus on that.

• Are you having trouble dealing with objections, alternatives, and ideas for improvements? Use annotations to get them out of the way. Make it clear to the other participants that they need to focus on one story line and that you will go through the collected annotations later.

When the storytelling hits a dead end, it can be helpful to remind everyone of the purpose of the workshop. Remind them why you chose the particular scenario. Revisit your assumptions. Then, tell the participants the story from the beginning, sentence by sentence.

Another source of trouble are participants who cannot agree on anything. In such cases, we have found it useful to make the stories more concrete by naming actors with people’s names instead of their role. This clarifies that the story is told from one person’s point of view. For example: The Metropolis employs two cashiers—Charlotte and Carlos—who sell tickets in completely different ways. Instead of modeling both Charlotte and Carlos as “cashier,” start with, e.g., Charlotte and use her name for the actor. Then ask Carlos how his version of the process is different from Charlotte’s version. Making differences visible is a good first step toward resolving them.

As the moderator, you also have to ask yourself if Domain Storytelling is the right modeling method for the job. Use it if you think it will help with the goal you are trying to achieve. Do not use it blindly because it has been useful to you in the past, because it’s new, or because it’s the only modeling method you have experience with. If you come across a situation where are you having difficulty using Domain Storytelling, ask yourself what is causing it:

• Is it a problem with the domain itself (e.g., it is inherently hard to understand)?

• Is it a problem with your modeling skills?

If you can answer both questions with “no,” you are probably trying to use Domain Storytelling for something that it should not be used for. We want to encourage you to learn more techniques of collaborative modeling and facilitation. Some of them we will briefly describe in Chapter 7, “Relationships to Other Modeling Methods.” It can also be useful to look at techniques from the design world (such as mock-ups). Also, Liberating Structures can help with problem-solving, decision-making, planning, and feedback [LiberatingStructures Website].

When the Story Gets Too Big

Depending on the modeling tool, the potential length of a story might be limited. As a rule of thumb, the following limits apply:

• Flip chart: 10 sentences

• Large whiteboard: 15 sentences

• Digital tools: 20 sentences

In some situations, we have exceeded the limits. But at a certain point, the visual recording becomes too cluttered, unmanageable, or hard to grasp. See, for example, Metropolis 5 in Figure 6.3: If you open the model in Egon.io and use its replay-function, the story is still manageable. But if you want to use the picture in books or presentations, it is worth considering splitting the domain story into shorter ones.

Here are some strategies for dealing with big stories:

• Change to a more COARSE-GRAINED scope, especially if you have not grasped the big picture yet.

• Thin the plot: Choose an easier story line or avoid side plots.

• Use assumptions to skip the first few steps of the story. In Metropolis 2 (see Figure 1.10), for example, instead of modeling how a moviegoer chooses the movie they want to see, write an annotation: “We assume the moviegoer has already chosen which movie to see and there are shows that fit their time.”

• Split one story into several stories: If none of the previous strategies works for you, it might be because your story requires a certain depth and cannot be thinned or aggregated. Still, you can split it into several stories. Try to cut the story after an intermediate result is reached, or use a handover of a work object as the last sentence of one story and the first sentence of another story. When the story line moves from one subdomain to another or from one department to another, that is also a good place for a story split. Please keep in mind that cliffhangers are exciting when they happen in your favorite TV series, but not in a domain story.

How to Create the Right Atmosphere

As a moderator, you can take certain measures to create a productive atmosphere.

Keep an Eye on Your Participants

• Does someone dominate the conversation and need to be reminded of boundaries?

• Who is silent/shy/uncomfortable and needs encouragement?

• Who is reluctant to speak and needs to get something off their chest?

Establish Rules

As we said before, polite manners are easily forgotten in a heated discussion. Therefore, it can be useful to establish some basic rules or a code of conduct. Here are some ideas:

• Let others finish their sentences.

• Treat each other respectfully.

• When discussing problems, do not blame each other.

• Be truthful to the best of your knowledge.

Stay in Control

Even with a code of conduct in place, you should watch out for people who pose a threat to a productive atmosphere:

• Attention seekers who see collaborative modeling as a chance to boast about how great they are.

• Frustrated people who treat collaborative modeling as a chance to let off steam.

• Managers who used to be domain experts before they got promoted to management and have since lost touch with the domain.

Even for experienced moderators, situations like these are difficult to handle. But it is your responsibility to achieve a good result. Hence, you have to intervene:

• Make it clear that for a good result all perspectives must be considered, not just the managers’ or longest-serving employees’ opinions.

• Emphasize the goal of the workshop and the time frame you are working with. Postpone discussions that are out of scope.

Finishing a Domain Story

When the story seems to be finished, tell the story from the beginning and try to get agreement: Did we miss something? Is something obviously wrong? Do all domain experts agree with the story? Revisit the annotations for possible alternative stories. Let the participants decide which ones are minor variations and which deserve their own domain story. As a moderator, you can stimulate this discussion with questions like these:

• Are we talking about the same task that is sometimes done differently? Or are we talking about a different task?

• What would be different if…?

• Am I right that the only difference would be…?

If necessary, model another domain story. Maybe you’ll want to schedule a follow-up workshop to take a more detailed look at parts of the story or to deal with important variations. If everything went right, you have now built a common understanding about a relevant part of the domain. However, you will rarely succeed 100% in bringing the views of several people to one common denominator. Be careful not to jump to abstractions in order to avoid conflicting views. Instead, use annotations to bring unresolvable differences to everyone’s attention.

Write it down as an annotation. Then, people can see it, can point to it, can object to it. Making things visible adds quality to the discussion.

After the Workshop

When the workshop is finished, the result should be documented. Take a picture of the whiteboard. If you drew the picture with a tool, it is good practice to tidy up the model to reduce clutter. Then, share the picture or file. Note, however, that the visualization of a domain story was not intended to be a stand-alone document. First and foremost, the picture is for the people who are telling the story while they are telling it. Later, it will serve as a memory aid for those who participated in the workshop and for telling the story to other people.

Other artifacts of the software development process will crystallize and grow around the domain stories as well. Take, for example, context maps (see Chapter 10, “Finding Boundaries”), written requirements (see Chapter 11, “Working with Requirements”), and the code model³ (see Chapter 12, “Modeling in Code”). You can also continue the conversation about the domain with the help of other modeling techniques, such as Example Mapping [Wynne 2015] and EventStorming [Brandolini 2021].

³ In the end, the code is the model, and the model is the code.

If you missed the workshop, you missed the “campfire” experience. Looking at a finished domain story is not the same as participating in the making of it, because Domain Storytelling is a collaborative learning experience. The participants reflect on their own day-to-day work and learn from their colleagues how they perceive the domain in a different way.

TO-BE Workshops

In the spirit of collaborative modeling, we see process design as a collaborative activity in the form of workshops. In a TO-BE workshop, several things have to be done differently than in AS-IS modeling.

When modeling AS-IS processes, you are mainly analyzing. You look at the world through your domain experts’ eyes and describe it as these experts perceive it (as well as you can). You are focused on the present and explore the problem space. The main goal is understanding.

With TO-BE processes, on the other hand, you will find yourself in the solution space and in the future. Also, you are not analyzing, but constructively designing—usually on the basis of a previously analyzed problem space. That means you look at the world and describe how it will be (or how you hope it will be). This usually includes some sort of improvements and process changes, especially if the TO-BE process will be implemented through software. After all, you do not want to just re-implement a bad AS-IS process. For more on that topic, see Chapter 13, “Supporting Organizational Change.”

When preparing for a TO-BE workshop, keep in mind the following:

• TO-BE domain stories usually take longer to tell and record than AS-IS stories. We recommend you allocate 50% more time.

• Be prepared for a lot more discussion compared to an AS-IS workshop.

• Come ready to use other workshop techniques that complement Domain Storytelling, e.g., to collect feedback on a proposed process improvement (see the upcoming section “The Moderator”).

What can you do as a moderator to facilitate a successful TO-BE workshop? Here are our recommendations:

• Avoid confusion by talking about a specific point in time: Define the point in the future when the TO-BE processes take place. It makes a big difference if one of the participants thinks of the future in 6 months and another one thinks of the future in 24 months.

• Do not settle for the first result: Model and compare different variants of the future process (for the same point in time).

• Make room for improvements: As a moderator, you need to challenge the participants’ story more rigorously. Question every sentence to uncover hidden assumptions. For example, ask “why” again and again to discover the purpose of a proposed activity (or the lack thereof).

• Free the participants’ minds from current system boundaries: Instead of using the names of existing systems as actors, use fictional names that describe their job (like “a system that schedules marketing campaigns”) or placeholders (like “System X,” “System Y,” “System Z”).

• Free the participants’ minds from current roles and responsibilities: Instead of existing roles and job titles, use fictional names and placeholders for human actors.

• Challenge the scope of the proposed software systems: Ask if the TO-BE process would lead to a tight coupling of software systems—meaning, is a system able to fulfill a task only if it cooperates closely with another system? That would be bad, of course!

• Challenge the proposed processes: Try to re-enact concrete examples from the past with the TO-BE domain stories. Can the proposed process handle the examples?

Remote Workshops

Domain Storytelling was conceived for on-site workshops. We have since found that it also works well in remote settings if you take into account a few things:

• All participants need to be able to see the visual representation of the domain story (in real time, as it evolves).

• All participants need to be able to hear each other.

The first point requires a digital modeling tool and screen sharing. If the modeling tool doesn’t already have this capability, you should use a videoconferencing software. We have used the combination of videoconferencing and Egon.io or virtual whiteboards (see Chapter 5, “Modeling Tools”) successfully.

In addition to the previous two requirements, we have some recommendations:

• Use video (not just audio) and ask all participants to do the same. Seeing the participants enables you to read at least some body language. A setup with two screens (one for the video feed and one for the modeling tool) is helpful.

• Split the roles of moderator and modeler, especially for larger groups. The moderator can focus on the participants. Handling a group of people can be difficult even if everyone is in the same room. Dealing with muted microphones and people cutting each other off makes the moderator’s task even more challenging in a virtual setting.

• Set a timer for a short modeling session (around 45 minutes) followed by a break. This helps people to stay focused. Try to tell a story from beginning to end within the time frame.

• The experience is usually smoother if the participants and the moderator/modeler are already familiar with one another. Then the information loss (body language, interpersonal relationships) that occurs in a remote setting is less of a problem.

• For important workshops, do a pre-event check to ensure all participants are comfortable with the software used.

Our impressions so far are mixed: While remote workshops can encourage some participants to ask more questions, others are more reluctant to give negative feedback. Perhaps these are side effects of not being fully immersed in the workshop. After all, it is so easy to get distracted when one is at the computer. A moderator can help the participants to keep (or regain) their focus by retelling the domain story from time to time. In addition, the moderator should request feedback frequently.

If you follow these recommendations, you will be able to run successful remote workshops. The spirit of Domain Storytelling can easily be carried over from on-site to virtual settings.⁴

⁴ You can watch Stefan do a remote modeling session on YouTube [Hofer 2020]. Even though this video shows a session with just one domain expert and one moderator, it gives you an idea of how it is meant to work.

The Moderator

The moderator’s responsibility is to bring together storytellers and listeners and help them to create a shared understanding.

Facilitating a workshop may sometimes be challenging, but it can be learned. It in this section, we have compiled some advice for moderators. In our experience, moderating workshops can be incredibly rewarding and is worth the effort.

Who Can Play the Role?

The role of the moderator stands out. It can be played by a neutral facilitator with no prior knowledge of the domain and with no other intention than helping the participants. A Scrum master, agile coach, or external consultant can be a good fit for this position.

However, the moderator role is often assumed by the host (the person who has initiated the workshop and invited people to participate) or a listener. As a product owner, software developer, or business analyst, they want to learn about the domain and its business processes. Staying neutral as a moderator is usually a concern when you are in the problem space. When moving on to the solution space, moderators may give advice on how to optimize the process and use new technologies.

There is, however, another possibility. The moderator could also be one of the storytellers. In this case, the moderator needs to be careful not to forget their primary responsibility. They might be tempted to steer the conversation into a direction that they prefer. This is risky because it undermines the purpose of the workshop. It also damages the credibility of the moderator, making it harder for them to resolve conflicts.

In summary, the moderator could be the following:

• A neutral person

• The host or another listener

• A storyteller

Learning to Facilitate

By now, you have read a lot about Domain Storytelling. Maybe you have also seen a video recording of one of our tutorials. But reading and watching on their own don’t make you a practitioner; you need to practice. We recommend the following.

First, try it on your own. Pen and paper are all the tools you need. Model a process that you are familiar with. Here are some ideas:

• Having dinner at a restaurant

• Buying groceries

• Going on holiday

• Electing the government of your country

Focus on the pictographic language. Get familiar with the way a story is visualized. Experiment with variations of your process: What if you model the variation as a separate domain story? Or can you capture it as a textual annotation?

The next step is to ask a friend or a friendly colleague for help. Grab a whiteboard or a flip chart, some sticky notes, and a marker. Have the friend tell you a story that they are an expert in. Focus on being a moderator: How do you motivate your domain expert toward intensive cooperation? Can you keep up visualizing the domain story while listening and asking questions? Try to capture your expert’s point of view and not your own. Learn how to avoid making implicit assumptions or drawing premature conclusions.

Then, think of a real-world problem that you have encountered and that can be explored with Domain Storytelling. Ideally, pick something that can be discussed with a small group of domain experts. Focus on managing the group and turning their individual stories into one domain story that everyone can agree on.

The Modeler as Separate Role

Since moderating and modeling are demanding tasks, we recommend beginners separate the role of the moderator from the role of the modeler. One person assumes the role of the moderator and is responsible for managing the domain experts. Another person becomes the modeler and captures the domain story. To make that work, both need to be familiar with the method. They also need to communicate well and support each other. For example, the storytelling needs to move at the same speed as the visualization.

For large workshops and heated discussions, we would also recommend splitting the tasks so that one person can focus on moderating, and the other person can focus on modeling.

If you are the modeler, you should keep in mind that modeling is not about (software) tools. They are there only to support you and should not distract the participants.

The more experience you gain with modeling domain stories, the more relaxed you will be about the grammar of the pictographic language that we described in Chapter 2, “The Pictographic Language.” Once you know what a domain story should look like, the training wheels can be taken off. After all, the point is to convey meaning, not to follow strict rules. Of course, we are not encouraging you to throw everything we have written out the window. But at some point you should start treating it as advice, not as law.

Moderated Mode vs. Co-Op Mode

If you work with a small group of participants who are already familiar with Domain Storytelling, modeling can be a collaborative activity that includes all participants (co-op mode). Such a setup can be more fun than having designated moderators/modelers who do all the modeling (moderated mode).

If the participants are not used to the domain story way of reasoning about workflows, shared modeling responsibilities can lead to a chaotic workshop that will make the moderator’s life hard. There is a good chance that you’ll end up with an incoherent model or a model that reflects the view of the loudest participant. Thus, working in co-op mode requires a few agreed upon guardrails: which scenario the domain story is about, which icons to use for the pictographic language, and which scope to aim for.

Whether distributing modeling tasks is an option for you will also depend on the tool you use to visualize the story (see Chapter 5, “Modeling Tools”). To enable it, you’d need everyone to have access to the canvas and the ability to change the model.