Blog

Making the most out of remote EventStorming

19 Mar, 2020
Xebia Background Header Wave

A while back the virtual Domain-driven design meetup experimented with doing a remote EventStorming. The outcome was that doing remote EventStorming as you would do it offline is sub-optimal. The interaction was lacking during the storming parts, and the number of insights gained was lower. That is the power of EventStorming, and it was not present. Still, we asked ourselves how we can make remote EventStorming more optimal, and with most of the world being stuck at home due to corona, I started experimenting with it. In this post, I will describe heuristics about my first experience with remote EventStorming.

Copywrite: Avanscoperta

What is the problem with remote EventStorming?

I have been facilitating EventStorming sessions for the past 3+ years. For me, the power of these sessions resides in the first stages, namely the chaotic exploration and enforcing the timeline. During these stages, we deliberately guide people to communicate and share their perceptions, share their pool of meaning. Because a person’s pool of meaning is different from others. Heck, most of the times people meet for the first time, especially at a big picture EventStorming session.

The only justification for our concepts and systems of concepts is that they serve to represent the complex of our experiences; beyond this they have not legitimacy.

Albert Einstein

EventStorming facilitates in creating a pool of shared meaning. Groups and teams must have a pool of shared meaning to generate better decisions and have more valuable insights. Writing and sharing your Domain Events seems easy, but does everyone in the team feel safe enough to say what needs to be said?

How do we create a safe environment remotely?

We need to have a dedicated facilitator, someone who does makes it a safe for everyone say the things that need to be said – even ideas that at first glance appear controversial, wrong, or at odds with their own beliefs. Offline it is much easier for a facilitator to use their meta-skills of super listening (hear, see, and feel the energy) than in an online setting.

The facilitator must focus on seeing everyone through their camera at all times. That also means that everyone should also have their camera on and uses two screens. On one screen we can look each other in the eyes and on the other one we use the remote tool. With the power of reflective listening, they can create compassion and show neutrality to the group. Without a facilitator that has these meta-skills and can see everyone through the camera, I won’t advise anyone to do an EventStorming session. Because your outcomes will be highly inefficient, and people won’t give you their buy-in.

How can people be present from the start?

Remote work is something new to a lot of people. Most of the people work from home, where daily life mixes in with work life. Having such flexible lives means people sometimes have a hard time focussing and leaving behind their personal life. To have everyone present and also know what is on their mind for this meeting, always do a check-in. Have people answer three questions, one about how they are feeling, and two opposite questions focused on the EventStorming that is about to happen. For instance:

  • How are you dealing with remote work and balancing private and work life?
  • What do you hope the outcome of this EventStorming will be?
  • What pain points or hotspots do you think EventStorming will bring?

As you see, the two questions focussing on the meeting are opposites. It is very important to always have two relevant opposite questions during check-in to already start creating that pool of understanding from the start.

Yin Yang Cats Stickers | Zazzle
Copywrite: zazzle.com

How do we engage people?

During our remote EventStorming on the virtual Domain-driven design meetup, we observed that while enforcing the timeline engagement was low. During offline EventStorming it can happen as well, but an excellent facilitator will start asking questions. The problem is, using tools like Miro you cannot see where people are working on, so it is hard to know what is going on.

What I tried is for Process modelling and software modelling EventStorming is to do it in a mob programming style. Start enforcing a single flow EventStorm, have only one person able to edit post-its and have the rest navigate that person. We did this explicit walkthrough on the virtual Domain-driven design meetup, just not from the start of enforcing the timeline. Naturally, this doesn’t work for a big picture, and I have not experimented with it before.

How do we keep people engaged?

Engaging people is hard, but keeping people engaged might even be harder. From my experience of leading an online guild in World of Warcraft, keeping people focuses for a long time is hard. We needed to defeat bosses online with 40 remote people, each doing their specific job. These battles could take up to 20-30 min of extreme focus; one mistake by one person could make us fail and start over again.

What we want is short engagement with specific outcomes that people can focus on, and in between breaks. We want to use a visual timer so people know what to expect when they can take a break and for how long. Brain science shows us that shorter trumps longer, so split up your remote work in 10-20 min segments. Especially since brain science also shows us that movement trumps sitting. Meaning we also need to ask the participants to do some movement in between these segments. We might not be aware of the value movement gives us, because we get it out of the box during an offline EventStorming

Copywrite: bowperson.com and
https://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf

How long should a remote EventStorming last?

Sitting for extended lengths of time makes thinking and learning more difficult to do because of the oxygen levels in the body decrease. During an offline EventStorming, we always tell the importance of oxygen. Doing remote work, we often lack that fresh air, we don’t move enough, and that resolves that we cannot stay focused for an extended period, even with short movement breaks in between. That is why we keep EventStorming sessions which are remote up to a maximum of two hours for a day. Running it longer is possible if we have a long break where people can move, get some oxygen and some fresh drinks and food. Just compare it to driving a car for an extended period.

How many people can join a remote EventStorming?

For offline EventStorming, it depends on the type of EventStorming you do how many people can join. I would advise sticking with the same heuristics for offline EventStorming, max seven for a process or design level EventStorming. More than 7 you want to split and merge, using the same working space but moving the teams in separate online rooms. Doing a remote big picture EventStorming might be a real challenge, I have not tried it and will keep it to a maximum of 12 people per facilitator. The big picture is highly dependent on how the facilitator their experiences with remote EventStorming is. I haven’t done a real-life big picture yet, so these are all speculations by me.

I hope these heuristics will help you boost your remote EventStorming sessions. I want to thank Alberto Brandolini, Zsofia Herendi, Marco Heimeshoff, Maxime Sanglan-Charlier and Barry O Sullivan for the wisdom they gave during the virtual Domain-driven design meetup. What I wrote down here is based on that session. I will be doing more remote EventStorming, even hoping to do a big picture one soon. I am also interested in other people their experience, what heuristics did you use? Let’s talk about it and share them, as I did with these heuristics, on Domain-driven design heuristics site!

Also, this post is published on my personal blog site.

Kenny Baas-Schwegler
A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a strategic software delivery consultant and software architect with a focus on socio-technical systems. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change with Deep Democracy by using visual and collaborative modelling practices like Eventstorming, Wardley mapping, context mapping and many more. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing, architecting and building sustainable quality software products. One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts