EventStorming in COVID-19 times

by Alberto Brandolini

Disclaimer

If you already know me, you should remember that my position towards "remote EventStorming" wasn't exactly favorable. However, the Coronavirus changed everything in or space, so a different position might be needed. Before starting to read this post I suggest you to read Remote EventStorming first.

At the moment of writing, Italy is in lockdown. EventStorming, as it was conceived like put all the key people in the same room, is forbidden, dangerous and strategically suicidal. So I guess some of the thoughts in my previous article needs to be reconsidered in the face of the changed scenario, where working remotely, possibly from home, becomes the norm.

This article's approach is not general purpose: my consideration about remote workshops in normal times still stand, and I really hope to revert back to that status quo. But we're not there anymore, and here I will write my current thoughts about EventStorming in a world where meeting in person is a risky luxury and still people need to explore complex domains, design sophisticated processes and collaborate across silos.

Big Picture in forced remote style

My recommendation for this format in remote mode was basically: "Forget it. It won't work." ...under the assumption that the in-person version was viable, or just a matter of money. Now it's not.

So here are a few ideas if you think you have to run a Big Picture EventStorming no matter what. If you've read my previous post you already know that it's not going to be easy.

Clarify the purpose

What are we calling the workshop for? The purpose is important in the physical version, but being colocated allowed a lot of maneuvering space and multiple valuable outcomes. I am afraid we don't have this luxury anymore, at least in a smaller time-box. So it becomes really important to clarify the purpose up front and design the steps to lead the workshop to the desired goal.

  • Is it a company retrospective? Maybe we don't need the full exploration if we already run one a while ago. The shape of the organization is already known and we can seed it in advance (see later: Seed the structure) or keep it a little fuzzier (and drill down into events only where it hurts).
  • Is it a startup envisioning? In this scenario, we can assume to have fewer people involved, and the need to clarify the structure of the to-be state. This scenario is probably the most resilient to the format change, it just takes a little more time.
  • Is it a business redesign? We've been doing it a while in these days. It's usually valuable to start from a validated model of the status quo: if you have it (past Big Picture, maybe) you can move quickly to exploring what-ifs on top of the existing structure. If you don't have the as-is model available it will feel useless to build it in pain (your current problem should be the future, not the past), but be ready to revert to visualize portions of the status quo on-demand, whenever contradictions arise.

Seed the structure

The emergent structure doesn't work that well in an online tool. Instead of starting with Chaotic Exploration, it may be better to provide some structure (Pivotal Events or Temporal Milestones first) before starting, hopefully reducing the impact of the initial stand-off.

Keep in mind that Emergent Structure was there for good reasons: better learning and challenging the current understanding. By providing some initial structure, you take the risk of caging the exploration, or worse, sterilizing it.

Provide more detailed joining instructions

Part of the explanation can be anticipated: the initial steps, and possibly some examples can be part of the workshop invitation: this can reduce the initial tension. Keep in mind that the facilitator is almost completely blind at this moment and can't help as much as in the real version.

Start with different colors

One big limitation of the online format is that handwriting is lost. And the handwriting is an implicit signature so it becomes a lot harder to understand "who write this one?"

Well... digital format allows some magic like Select all and changing the color later. You may want to start seeding the big picture in different colors, and then flatten the modeling space to orange only after you sorted it out, ideally after Enforce the timeline or Explicit walkthrough, or during it like a visible cursor.

Split and Merge

Another idea might be to ask the different participants to start bringing their homework to the workshop: it will look awful in the physical world, but it can be just a matter of copying, pasting and rearranging. Of course, this portion of the process is unchallenged (it's basically what some people write on their own stickies before placing them in bulk on the modeling surface), so keep in mind that we'll have to challenge the local narratives when building the global one.

You should also be aware of the asymmetries: some department might already have a formal model of their procedures, others may have not. Some might be tempted to just cut and paste an existing model because it's the same thing! :-(

Last but not least: the creation dynamics of the local portions would not be observable. In a physical workshop, the facilitator has the duty of breaking up committees, that tend to present a too clean view of reality. Committees can still happen when you're not looking and hide the local contradictions before getting to the big picture.

You can make yourself a lot blinder this way. Maybe this is not a great idea, after all... 😔

Set Inspect and Adapt checkpoints

Make sure to have a few reflection moments asking what is working and what is not, and eventually correct the direction of the workshop. This happens in the physical world too, but in remote-digital we need to make these moments explicit since the implicit indicators like smiles and body language are essentially gone.

Allow multiple conversational channels

The online bandwidth for a voice-based conversation is <1, but there are other media other than voice. Some people are using Zoom multi-room features, chat channels can be another idea, to keep the conversation parallel and traceable at the same time.

Set peer pressure

Being co-located with a big wall and an overwhelming task to complete establish a useful lot of peer pressure: everybody is doing EventStorming so ...I have to do it too. Being remote makes people less affected by peer pressure so some key participants may end up being distracted.

Using different colors per person or department can help highlight the lazy contributors and increase the pressure a little, but I guess explicit time-boxing is going to be the most effective too here.

Make disagreements visible

Funny faces and rolling eyes are not working remotely. We'll need to find a way to make disagreements visible without getting in the somebody's wrong on the internet mood. Tools like Miro allow the possibility to have comments, they're not as powerful as the Hot Spots (I will miss a lot the possibility of drawing on the stickies) but they may do a decent job.

Keep also in mind that hotspots could have been somewhat anonymous, while comments are signed.

Warning: convergence may never happen

One thing needs to be absolutely clear: we need an even stronger commitment to make a Big Picture work online. The in-person version is a little friendly trap for some people: once you're in, the conversation becomes deeper and touches the real problem.

Given all the impediments to flow in the remote version, we can't expect to deliver in one day. This means finishing day one (maybe timeboxed to a shorter session) without a tangible/valuable reward. Some people may not be available for the second day after a very tiring and disappointing experience, so you'll have to listen to the pain as much as possible.

But long-lasting activities, especially if interleaved with some others, may never get to the point of getting everybody's full attention. Workshops leverage full immersion and a sense of urgency to deliver results in a time-box. Without the time-box magic, the probability of never getting to the point increases enormously.

Process Modelling in forced remote

Process Modelling implies a smaller group of participants, with diverse backgrounds - ideally business, service design, and software people - to sketch a complicated process together, usually spanning multiple departments.

It relies on the Collaborative Game metaphor. We are a team looking for the best strategy to accomplish our specific task. In other words, inspect and adapt is embedded in the design activity. In a real workshop, we'd probably switch between different modeling strategies (brainstorm first, forward modeling, reverse modeling, split and merge just to name a few) according to the emergent situation.

Well, we can play table games with our friends at home, and we can play games online with virtual friends too. It's not the same thing, but some dynamics are preserved or enhanced. Playing soccer on the PlayStation is not going to make your healthier, but maybe you will never be able to play with Leo Messi or Cristiano Ronaldo in the real world.

Keep the legend Visible

Keep in mind that not everybody is an expert, make sure the grammar and the rules of the game are available to everybody. Since only one conversation is possible at the same time, the pressure on the newcomers in need of clarification goes up.

Make sure participants can access all the fundamental information without feeling guilty for slowing everybody down.

Don't discuss invisible things

This is exactly the same recommendation for the in-person version of the workshop. Except that we're (once again) missing body language clues, and we need to contrast the blind spot with some discipline, like "we're not wasting time discussing stuff that we don't see"

Split and compare

Some good news here: the digital format makes some issue resolution actually easier: creating an alternative version of the flow is just a matter of selecting, copying, pasting and rearranging. Diverging ideas can both be visualized.

At the same time, it's easy to get lost on virtual modeling surfaces which are really unlimited, so some discipline in naming and structuring alternatives needs to be put in place.

Time-boxed mob modeling

Modeling sessions can be split into short (5-7 minutes is my preferred size) session where only one person is allowed to lead the modeling. You may want to find the perfect balance for your team, some people like to speak with someone else writing, others like to take the active lead showing off their mastery with keyboard shortcuts... just find what works best for you.

In 5 minutes you can deliver interesting portions of value if you have a clear idea of what to do. The little magic of this approach is that people think about what to do before taking the lead. After a couple of embarrassing "who's next?" people will usually volunteer and go straight to their point.

When I said: "lead the modeling" I meant it: one person is in charge and you should not stop this person's train of thought with your objections unless this person is explicitly asking for clarification. The pressure of doing it under everybody's eyes is relieved in the online version, but no human being can solve a complex problem in 5 minutes while being continuously interrupted.

Make disagreements visible

Since body language is gone - am I repeating myself? - making disagreement visible becomes vital. Remember, we're only discussing visible things, and if your disappointment is not visible, then everybody can assume you agree. Or that you even like the crap that your colleagues are calling "emerging design".

Interrupting the modeling flow with your objections isn't helping, so physical or virtual, we should make the disagreement visible but not necessarily vocal.

Hot Spots - magenta stickies, usually turned 30° anti-clockwise - are my favorite tool in the real world, because they look so annoying to modelers with a mild OCD (my personal OCD is at the "I established the degrees of the stickies rotation" level). The goal is to deliver a "can you really tolerate all this mess?" type of message, inducing people to clean the objections one by one.

Unfortunately, digital tools tend to make everything too tidy and nothing really stands out. So, part of the annoying force of hot spots is somewhat muffled. For example, Miro doesn't allow stickies to rotate, and comments look so polite.

In general, you need to make the process of getting rid of hotspots something to celebrate. You need to feel that you're making progress.

Have grammar compliant chunks ready

This one is a small little improvement, but that can speed up a lot. The grammar is fixed and comes in blocks. You can have the blocks ready in bulks so that you're not wasting time selecting shapes and colors.

This is very platform-dependent: some modeling tools like Draw.io allow stencils, while Miro doesn't, but comes with templates instead. In general, there are ways to speed up the experience. Be careful not to increase the tool divide by abusing them.

Rush to the goal

Your worst enemy when modelling processes and software is to try to solve all the problems at the same time. Well ...you can't. Physical or digital, it doesn't matter: this strategy still stands.

In short, you have to find a baseline solution - respecting the color grammar - as quickly as possible, visualizing the alternatives that you're ignoring with hot spots (you're not really ignoring, only postponing them), and move on towards your goal which is to make all the stakeholders reasonably happy.

Is it a payment? Rush to make the money available to the payee.

Is it a purchase? Rush to have the goods delivered to the customer.

Only then start considering impediments and variations, one at a time.

Explicit facilitator

Switching the media creates a whole new set of responsibilities and moves to make sure the discussion is happening smoothly. This probably calls for an explicit facilitator role, to manage, time tools, and the quality of the discussion.

Software Design in forced remote

Everything we said for Process Modelling stands for software design as well, except that when talking about software, the conversation will tend to exclude the other stakeholders.

Explicitly separate software-only issues

There are topics that badly need every stakeholders' opinion, others - like naming classes or choosing size of aggregates - that aren't relevant for the non-technical people, or probably a small selected minority of them.

In general, it is very hard to draw a line in advance: issues tend not to be easily categorized in advance. But you can categorize issues on the fly, like this discussion is software-only, let's defer it to a smaller session.

This way you could converge a little faster on what a given feature is supposed to deliver while postponing the how to a smaller group of specialists.

Collect terms

If you have some Domain-Driven Design experience you know that naming is a really hard problem to solve. During a Software Design EventStorming session, people tend to talk about a lot of different concepts yet using only a few of them.

Having a visible list of terms, or better a Dictionary can make people realize that the problem can have a more sophisticated solution, than the one they're currently envisioning. My personal record was in a session when people talked about 11 concepts, yet they were trying to model a solution using only 2 of them.

Take a break, then repeat

You have found one solution that makes everybody happy. Well, this is great! Now can you find another one? Don't fall into the trap of thinking that since we have found a solution, that's the only solution.

Sometimes finding one solution of the puzzle is just needed to feel safer for the next experiments. We have a solution we can fall back to, but can we find a better one?

It's not something to be done immediately: people can be depleted at the end of one modeling session, or maybe need some time alone to figure out exactly what's not working with the current model. Solo time is as important as collaboration time.

The model is only a portion of the job

A software design EventStorming artifact is not a blueprint for software development, but an exploratory tool to shape the conversation for effective software design. It provides a lot of answers but not all the answers.

If you feel you've been modeling enough, then maybe you need just to spend some time coding, to figure out what's missing. This is a pure modeling whirlpool approach: every tool is giving you some answers but not all of them, if you feel you're running in circles, then maybe it's time to write some BDD tests, write some code, sketch some wireframes... you know what to do.

General recommendations

And, last but not least, a few recommendations, that can apply for a broader range of remoter situations, but which are important also fo EventStorming.

Prepare yourself a stand-up desk

You'll have to type a lot and be in front of your camera. This means you have to be sitting all the time, right? Not really.

Take control of your desk and set up a place where you can be standing. It may require a little more hardware (desk, headphones, mic, etc) but your engagement will be improved a lot.

A big chunk of the EventStorming magic is about standing and walking (and a lot of online gaming is about having pro hardware). You can do it at home too!

Can you use a tablet instead?

Typing forces me into an annoying position, but I realized that I tend to be a lot more comfortable when drawing. I still haven't found the perfect tool to allow me to contribute with a pen instead of the keyboard, but I hope the situation will improve.

Block Distractions

During a modeling workshop, distractions should be muted. You're using your computer, but you should try to provide the same immersive experience. Nobody is checking if you blocked your popups, but you should.

As a facilitator, you should probably ask all of your colleagues to switch off all the undesirable sources of interruption.

You're human, accept it

In-person workshops are tiring, but there are a lot of extra factors that help to deliver. These factors are mostly missing in remote discussion, and people will be tired and depleted a lot faster. So you can't force them into very long sessions.

At the same time, if you find yourself doodling (I did), browsing other tabs and so on ...maybe your brain is just trying to tell you something. Call a break, eat some fruit. Your body needs it.

Conclusions

In case you wondered, I haven't really changed my mind: there is still no such thing as remote EventStorming. Still, we can improve the quality of our remote modeling sessions a lot, especially if we're forced to, and better options are not viable.

I hope you find some of the ideas in this post valuable. Writing this post has been painful for me because for so many problems it just would just be so easier if we could just be in the same room.

At the same time, I tried to take the current situation as a stressor, forcing my thoughts into places where I wouldn't have gone on a normal day.

A lot of these ideas are experimental, and I'd like to experiment further - maybe with a couple of online sessions.

Maybe some of the ideas will stick around even after the virus crisis is over.

Personally, I've never been more eager to have an in-person workshop, with surprised faces, crises, moments of joys, smiles, laughs, high-fives, hugs and the joy of solving it together.

Just like I'd like to have a party with friends after these weeks of segregation.

Learn with Alberto Brandolini

Alberto is the trainer of the EventStorming Master Class (in-person), EventStorming Remote Experience Workshop and DDD Executive View Training (remote).

Check out the full list of our upcoming training courses: Avanscoperta Workshops.