Organising a remote workshop EventStorming

Recently we have been busy organizing an Eventstorming workshop. It was a bit different than normal though since the goal of the workshop was to show the participants what an EventStorming workshop is and how they can apply it. We organized this workshop many times, but we planned to facilitate the next workshop remotely. The most important thing during an Eventstorming Workshop is the interaction between the developers and the stakeholders. Remote this can be harder to achieve, so we made some adjustments! This blog post will discuss what EventStorming is, how we tackled the challenges, and how the workshop was perceived.

Why EventStorming

In software development, it is essential to build what the stakeholders need. Making adjustments is costly and time-consuming. Furthermore, organizations have become more complex. What one stakeholder might think is true might not be so for other stakeholders.

Most developers are familiar with Scrum. In Scrum, the product owner is responsible for managing priorities, the order, and the backlog quality. But, in most companies, the product owner is also responsible for understanding the stakeholders and explaining this to the developers. What developers will implement is their understanding of the explanation from the product owner. But essential details might have changed in both transitions.

What Scrum didn’t prescribe is that all the learning should happen through the product owner. This is a dysfunction that lowers the quality of the overall learning and of the resulting product.
Alberto Brandolini

EventStorming is a workshop that tries to solve the following problems:

• Make sure the interaction between the scrum team and stakeholders is back. Here we skip steps where misunderstandings might happen.
• Make sure that the scrum team’s understanding of the domain matches that of the stakeholders.
• Make sure that all stakeholders are talking about the same domain and point out conflicting ideas between them.

How does the workshop look like

One of the most critical steps happens before the workshop: inviting the right people. There should be people who can answer questions about the domain, and there should be people who have questions about the domain. These are usually domain experts or stakeholders and developers. With multiple domains within a company, it is recommended that there is a domain expert from each domain.

The workshop should take place in a room without chairs. Preventing people from sitting keeps the energy higher, and it makes sure everyone can walk around and use the whole modeling space. There should be a long paper rolled out in the room. Sticky notes will fill the paper with sticky notes based on the domain. Those steps are explained and walk through in our remote workshop EventStorming.

What are the challenges?

Alberto Brandolini discusses the problems with remote EventStorming on his blog . The basis of our workshop is also a big picture workshop; the problems are largely the same. However, the goal of our big picture workshop is to make sure the participants learn what EventStorming is and when you can use it.

The number of participants. In an online workshop, only one participant can talk simultaneously. In our regular workshop, we usually have twenty to thirty participants. This would not be very efficient since we are looking for as much interaction as possible. We decided to split the participants into multiple groups: one business expert, two developers, and one facilitator.

The energy during the workshop. The beginning of the event storming workshop can always be a bit awkward. The participants do not know each other, they do not know the domain, and they do not know what event storming is. During the workshop on location, when one or two people start putting sticky notes on the wall, the rest automatically joins. Furthermore, online participants are sitting instead of standing. Finally, they are behind a laptop which offers even more distractions. During the dry runs, we noticed that the facilitator should take a more active role in keeping people engaged and interested. Mainly to get the ball rolling.

The workshop in action

How did the remote workshop EventStorming turn out?

We received very enthusiastic feedback from the participants, so we are sure that it is possible to teach people what EventStorming is during a remote workshop EventStorming. We also have noticed some differences during the remote sessions. Let’s start with the negatives first so that we can end on a positive note.

The cons

You miss the power of interaction between different branches within a company. In Eventstorming with multiple stakeholders and developers in a room, you also notice that the truth can be slightly different for each stakeholder.
Sticking real stickies, standing, walking around during a workshop on location produces certain energy. Online it is easier to wait and see what others are doing.

The pros

There were also positive differences in the remote session. Since the group is smaller, you can follow the conservation. During the regular workshop, you cannot follow each discussion as a facilitator, as multiple conservations are going on. One of the benefits is that it is easier to explain one of the following steps. During the regular workshop, you have to interrupt everyone, which includes some good discussions. In the remote workshop, you can interrupt the workshop when questions are asked, which reveals one of the next stickies.

For example, during one of the sessions, one of the participants asked:

I notice that some of the commands are always triggered after an event happened. Should we do something with that?

For example, when a bank account request is refused, we should always send a notification. The bank account request is refused is a domain event that happened. The sending of a notification to the user is the command of something that we want to happen. Let us explain the policy sticky. When Event then Command.

The result after introducing policies

There was more space for questions about uncertainties. Because there was one facilitator in a call together with two or three other people, we noticed that participants asked more questions than during the regular workshop.

Overall the remote workshop EventStorming was a great experience. The participants learned at least as much about EventStorming as during our regular workshop. Of course, the ratio of facilitators to the participants was a big part of the success. At the end of the workshop, developers were curious about using EventStorming to design and implement what was discovered during the big picture workshop. There are Design Level workshops that are pretty similar but focus more on a basis for an EventSourcing design.