Remote Event Storming Takeaways
Nowadays, COVID-19 has forced many of us to work from home. Some activities are less affected by this, like programming software. With a good internet connection you can nearly work from everywhere. However, software development is not all about writing code. Most of the time is about communication, like collecting information or getting feedback from the domain experts. Communication is complex, error-prone and subjective because every person has their own mental model and interpretation of information.
To build good software, we need to reduce this complexity as much as possible. Additionally, we need a common understanding of the domain to avoid mistakes. Therefore, different workshop methods have been invented. One is event storming.
Readers of this article should already know this format, because we would like to share our experiences we have made regarding the differences between the on-site and remote variant. For all who do not know event storming or need a short reminder, the next section gives a short outline of the subject. If you’re proficient with Event Storming you can directly skip to the next section.
Event Storming in short
Event storming was invented by Alberto Brandolini and is often used as a tool within domain driven design. It brings together domain experts and developers to get a common understanding of the domain and its business processes using the same ubiquitous language.
On-site, this is best done in an empty room with a large empty wall. The developers, domain experts and everyone else participating in the meeting won’t sit down at the tables of the room. Instead, they meet up in front of the wall. The event storming is split into various phases. During those, different sticky notes are stuck to this wall in order to map a business process. First, all of the domain events are collected and written down on most of the time orange sticky notes. After this chaotic exploration, the events are sorted and important ones could be marked as pivotal events. Next, commands (blue sticky notes) causing the domain events, are identified. In most cases this is enough. Nevertheless, event storming doesn’t have to stop there. Other usecases can be identified. For example, policies which are triggered by domain events, dependencies to external systems or hotspots to identify topics to discuss. A more detailed explanation is shown in figure 1.
Depending on the level of detail, at some point one does not talk about big picture event storming but of design level event storming. Our experience comes mainly from big picture event storming. Next, we take a look at the differences between on-site or remote event storming.
The Scenario
The experiences documented in this article mainly originate from a remote event storming workshop, that we conducted with one of our customers. Subject of the workshop was a pretty specific subpart of the logistics domain. The participating development team already had considerable experience with DDD and event storming. The invited domain experts were all first-timers. Although the timebox was relatively short with 4 hours, we had plenty of time to prepare.
Tooling
Let‘s begin with the tools we used to conduct the event storming remotely. Actually there‘s only two essential ones.
The first one is the video conferencing software. There‘s a lot of reliable solutions out there by now and most companies have one of them licensed. Our customer uses Whereby for everything which proved very stable and performant in the past, so this was already set. We considered using the breakout room feature but eventually decided against it as we feared the overhead and loss of communication when splitting and merging the group again.
The second one is the collaborative board. We chose Conceptboard for its simplicity and strength in collaboration features. Conceptboard‘s moderation mode is especially useful during the introduction of the workshop. Miro would be the obvious alternative and is also proven to work flawlessly.
Even more important than the choice of tools turned out to be their preparation. We prepared a Conceptboard with the initial state of an event storming board, containing these elements:
- The center piece is a large canvas area. Although we chose generous proportions for this area, it turned out too small in the end. The canvas had to be resized twice during the session to be able to fit all events. So we recommend to size the canvas area stupidly large up front or maybe even make it infinite without borders. After all, we are not restricted by walls, ceilings or people‘s heights as would be the case in a real room.
- Next to the canvas we placed a legend explaining the color and meaning of the different post-its so every participant has it in plain sight all the time. We kept to the types we aimed to actually use in the workshop: Domain Event, Actor, Command, External System and Hotspot – leaving out things like Business Process and View Model to not confuse the participants too much on their first event storming.
- In real life, every post-it has the same size and a fixed color. To avoid that every participant draws his own post-its in different sizes and slightly wrong colors, we prepared the post-its for them. Above the board we placed about 50 copy-pasted orange post-it sized squares for the domain events and about 10 post-its for every other color. They could simply be dragged-and-dropped on the canvas and filled with text by doubleclicking.
No matter which tools you use – none of them will be as intuitive as grabbing a post-it with your hand and writing on it with a pen. In our session we observed the participants having difficulties to actually use the board. That reached from simple mechanics of how to move the screen around to one participant actually not being able to interact with the board at all – turned out the participant was trying to move things on the screenshare of the moderator instead of opening it on their own computer.
To guard against these problems we strongly recommend starting the workshop with some kind of interactive check-in where every participant gets to „practice“ navigating and manipulating the board. We conducted an introductory session on a separate Conceptboard segment, where every participant had to „pull up a chair“ and write his/her name on it before introducing him/herself with a few words. This helped to mitigate some (but not all) interaction obstacles right at the beginning. Depending on the audience and complexity of planned interaction during the workshop you might even want to do a separate tutorial meeting with the group beforehand to do a dry run and help get everyone accustomed to the tooling.
One more interesting thing happened during the event storming. Some of the more techy participants discovered the commentary function and used it to add questions and additional info to events. This turned out to be very useful later in the workshop when the group tried to carve out the details of the process and clarify business behaviour. On a spatially constrained real-life board it is pretty difficult to fit things like this between the post-its. On a digital board they just hide behind an icon or comment indicator without disturbing the space too much. Maybe it would have been a good idea to introduce the commentary function from the start and use it as a normal tool for taking notes and asynchronous communication during the workshop.
Organizational Arrangement
Regarding organization there are only a few differences between the Remote event storming workshop and an on-site workshop. You actually save a lot of overhead as you don‘t have to book and prepare a location for the workshop and the participants don‘t have to travel. This gets replaced by preparing the digital board as explained above. As always, you pick your attendees from business and technical experts. You send your invites with time and location (link to the video conf) and decide on an agenda. You define format, scope and goal of the workshop up front.
One thing that is optional on-site but mandatory when remote: You have to decide beforehand if you want to do group sessions. In a real room with the dynamics of an event storming, groups can form spontaneously and work on the board simultaneously. In a video conference call this is impossible as no two people can speak at the same time. You can use break-out rooms but this is no spontaneous action, it has to be part of the agenda. We thought about this but had difficulties finding a good, pre-defined spot to continue in groups. In addition the time box was short and we feared losing time when the groups exchanged their outcomes after merging again. So we decided against it. This might be different depending on your situation.
Moderation
For our workshop we formed a team of two moderators. One agile coach to perform the frame moderation like introduction, check-in, break management, feedback session etc. and one DDD coach to moderate the actual event storming.
Throughout the event the biggest issue was to get the attendants to participate in a remote format. It is too easy to hide behind a muted microphone and a deactivated camera and let your focus drift. The energy level is low as everybody sits in a comfortable chair all the time instead of standing and walking around. To counter this we did the following:
- Ask all participants to turn their cameras on.
- Start with an activating Check-In. As mentioned before, the check-in is especially important in a remote workshop to get the participants accustomed to the tooling. But first it should serve its classical purpose of „warming up the crowd“.
- Try to keep visual contact to the people, not only the board.
- Ask for the opinion of passive participants and encourage them from time to time to contribute to the board and the discussion.
- Use moderation features of the Board from time to time to focus the participants on the correct part of the board and make sure that all relevant things are clearly visible.
As always, the actual event storming should be prefaced by an introduction into the method. This should actually be easier in a video call as you can use your screenshare to show a prepared example. You can prepare your own demo or use one from the internet like this one. It nicely visualizes the different phases of an event storming while explaining what Domain Events, Commands etc. are and how to use them. During these guided first parts of the meeting it is useful to use some kind of „moderation mode“ like in Conceptboard to focus the screen of all participants on the same part of the board.
When kicking off the event storming with the „chaotic exploration“ phase and actually letting the participants loose on the board, a few differences to our previous on-site experiences became obvious:
It is not possible to have multiple discussions at the same time. Usually two or three people speak about a specific thing while a lot of action happens in the background without anyone talking about it. The moderator should address this from time to time when discussion subsides and ask about things that appeared on the board in the meantime.
Sometimes no one speaks and still things magically move around on the board. As moderator you should regularly encourage people to speak out loud what they are thinking about.
When discussion and movement on the board finally died down after about an hour, we transitioned into the second phase – refining the timeline and filling in the gaps of missing events. Knowing that in a video call only one discussion can take place at once, it helped to pick a specific area of the board to talk about and then move through the different areas one by one. Things got a little confusing towards the end of this phase and the group was losing its focus. More structured guidance by the moderators – like working through the board strictly back to front – might have helped with that. Also on a remote board it is easy to clearly cluster and correctly align the post-its and arrows on the board to reduce visual clutter and confusion, which would have helped.
What‘s completely missing in a remote workshop is the after-event socializing with pizza and beer where the day wraps up nicely and everybody can let the impressions sink in. As a minimal replacement for that, we wrapped up the meeting with a short 10-minute retrospective feedback format. It helps the participants to better capture what they achieved today and the moderators to improve on the format.
Ultimately we can say that remote event storming required a lot of attention and moderation by the DDD coach, probably even more than on-site.
Methodology
In terms of methodology, we can say that nothing changes. The procedure remains the same remotely as it is with the on-site variant.
Documentation and Follow-up
One advantage of event storming is that you already have your documentation afterwards. It is the board itself. Usually you want to digitize the result and persist it somewhere like in your ticketing system or wiki.
On site, you need to take one or multiple pictures and upload them to your system. If you let this slip instead of doing it right after the workshop, some pieces of paper may have fell down or may get lost. After taking the picture you can put away the board.
In a remote setting this is not necessary at all. The whole board can be exported as a picture at a high resolution. Afterwards you can upload it in your system or even reference the board directly.
The advantage of remote format is that it is more accessible later on. It is not necessary to switch between different pictures which may lead to loss of focus. Additionally, the result can serve as a basis for further work and can be improved incrementally as a living documentation.
Conclusion
As mentioned at the beginning of the article, communication is very important. Unfortunately, this does not take place as intensively in the remote version as it does on site. Due to the “anonymity” of remote events, moderators have to motivate participants to express their opinions more often. In addition, the group dynamic is not as high because there are few opportunities for parallel conversations.
Although in tooling the remote variant allows more different actions, the on-site variant promotes interaction better. A major barrier to entry with the remote variant is the usage of the board. A group of inexperienced users will most likely progress faster on-site than remotely.
In terms of documentation, the remote variant is better because for future workshops you can build on the already existing board and thus enable a living documentation.
For the reasons described above, we would recommend that such appointments be held on-site if possible. However, since we are not experts in this subject and we only wanted to reflect our experience, those points does not have to apply to other teams. Therefore, we would be grateful for any feedback or suggestions for improvement. We are also interested in what experiences you have had with event storming. Feel free to write them down in the comments or contact us at info@synyx.de or on twitter.
Sources:
- Alberto Brandolini – event storming
- Judith Birmoser – Miro Event Storming Template