Remote EventStorming

Disclaimer

This is my position about the idea of Remote EventStorming before the COVID-19 which changed a few things. I suspect it will be interesting again once the emergency will be over. If you're under restrictions and need to keep on modeling, you may want to have a look also to EventStorming in COVID-19 times after reading this one.

EventStorming is not a single recipe for workshops. It comes in different flavors, and with different purposes.

Before exploring the impact of turning it remotely, we need to make sure we understand what we're talking about.

These are the most popular recipes for EventStorming.

• Big Picture is used for project kick-offs, organization retrospectives and redesigns, startups envisioning and so on. It is mostly about discovery, and involves 20-30 people on average since multiple perspectives are needed.
• Process Modelling has a more focused scope, on a single cross-functional process, usually spanning multiple departments, and can involve 5-15 people depending on the process complexity.
• Software Design has more or less the same scope as Process Modelling but goes deeper into the internals of the software we're designing.

The workshops have very different dynamics. Big Picture can be a revealing experience for some, since it basically digs into the deepest contradictions of organizations, trying to visualize a consistent business narrative for the organization and discovering interesting impediments along the way.

Process Modelling and Software Design usually assume that a Big Picture exploration has happened, and implement collaborative games mechanics in order to make design a team activity.

Now let's see if we can make them happen remotely, in the different formats.

Big Picture

The underlying assumption of a Big Picture workshop, is that we can provide a massive amount of discovery by having experts available full-time, under the promise that it's just for one day.

Some experts are not that easy to get. They'll start asking for clarifications or "am I really going to be needed for the full day?" their time can be really valuable, and they are legitimately balancing hypothetical cost and revenues.

But Big Picture is also a format where surprises happen, and they happen because of a somewhat chaotic structure (I mean... just enough structure to make the magic happen) and because it's massively immersive. Many things - and many conversations - will happen in parallel, because when the workshop starts, it will be a big unescapable puzzle to solve with your peers, and everybody will have to contribute in one way or another.

Things that won't happen remotely

• Parallel Conversation - this is probably blocker number one. The conversation bandwidth of conference calls is <1. You can't usually have a single decent conversation ... having more than one at the same time is not feasible. Some conversation will not happen - and you'll lose precious information - others will happen anyway - and you'll lose precious time.
• Localized Conversations - people talking about different topics right by the problem location, it simply won't happen. It improves learning, awareness, and establishes better human relationships between stakeholders and the development team
• Body Language - it's a great source of information, whether you process it consciously or not, you'll remember it. Without this precious source of information, the understanding will be more shallow, or people will be more likely to say something they'll regret without key signals.
• Active Facilitation - In a few moments, the facilitator is really active in understanding participants' attitude and stance, and should try to remove impediments to engaged participation. In virtual mode, this becomes a lot harder since most of the micro-impediments will not be visible, or even addressable (can you do something to stop a remote cat from interfering with your workshop?). The workshop can go astray and the facilitator might not have much control over it. I usually describe the facilitator as a dee-jay for a party. Can you be a good dee-jay without knowing if the people are dancing?
• Full Immersion - You can be in full immersion mode if you're in a room full of colleagues doing the same thing you do. There's a commitment, there's peer pressure, there's some degree of complicity ... all of this is sadly gone if you're somewhere else. A workshop of half-committed attendees is very close to being just one more dysfunctional meeting.
• Full day - Now, seriously, would you really go full day remote workshop? Extending the pain of a conference call from morning to evening? If we go remote, this won't be sustainable.
• Interruptions free - having the entire workshop paper-based guarantees that no interruptions will be channeled by the workshop tools (ok, maybe a depleted marker). An online version means that you'll be connected to the internet, with the full scale of popups and interruptions (which you should have disabled already, but can you guarantee that everybody else did?), not to mention opening the door to partial commitment. You'll be remote, after all.
• No scope Limitation - Big Picture builds upon not limiting the exploration scope upfront because I know that we can deliver within the one-day time-box. Unlimited scope implies that the main constraint is visible and part of our exploration, and it's making the arrow voting really powerful (see also 'The punch'). When everything is slower we might not be able to guarantee the depth of exploration, sacrificing relevant portions of the flow.
• Moving Around - being able to move around allows for a more immersive experience, but also for some healthier stance during the workshop. More oxygen, and so on.
• The Punch - Big Picture is a facilitated path to get to a revealing moment. This moment is designed to be a punch in the face (you may want to read Switch about it) to be more effective. In a remote workshop, the punch effect is gone.

The sad summary

At the current state of technology, I can't see ways to have a decent (I am not even looking for comparable) experience for a Big Picture EventStorming. The remote format will be more painful, creating impediments that will prevent key people to contribute and ultimately delivering more pain and lower gain, possibly leaving in place exactly the blind spots that we aimed to discover.

Even worse, if you try to run a Big Picture with this format, and call it "EventStorming" you may harm your political chances to run a proper workshop in person later on because the name is now associated with a please-not-anymore painful experience.

Process Modelling

The story is different for Process Modelling and Software Design formats. I'll talk about the two formats now, and go deep later into the dynamics for Software Design, in the next section.

The two workshop rely on a smaller number of participants, hopefully from an interdisciplinary background. I usually refer to the three stereotypes of Driller, Pragmatic and Empathic for the perfect modeling team, and they usually map into software, business, and UX specialists, with all the possible nuances: they're more personalities and attitudes than roles.

Both formats share a different set of assumptions, let's make them explicit.

• We expect a Big Picture workshop to have already taken place in the same organization. Process Modelling or Software Design workshops are ideally zooming into the solution space for the most critical blocker in the organization right now. The bottleneck that was highlighted in the arrow voting phase.
• We expect the past workshop to have laid the ground for better collaboration. Physical bonding, openness and so on. People should already know each other. Exceptions can, of course, be possible, but this is the default.
• We also expect these formats to happen more or less regularly, like at the beginning of an iteration, or when exploring a new set of features.
• We also expect to need more fluency than active facilitation. The workshop is intended as a cooperative game: like every game, the first time we play is bumpy because we need to check the rules, and we're not confident yet. After a couple of games, the rules are assimilated and we can focus on the game strategies, without having a game master to refer to.
• It won't take the whole day. A good Process Modelling session can be performed in half a day, some holes may still be there, but there are often issues that need further digging and clarifications that need to happen offline.

The collaborative game metaphor is probably the key for translating the in-person modeling experience into the digital world: if we're a good team, then we'll find a strategy for winning regardless of the game is online, or physical.

However, the change of media impacts the behavior of the modeling team more than we can admit.

The Virtual DDD Experience

Interestingly... we have data! We run an online Process Modelling session a few weeks ago, to explore the possibility, and it was disturbingly dysfunctional. The magic I am used to didn't happen even if most of the participants were EventStorming experts. Even more disturbingly, I've found myself doodling on my iPad, bored. Something that never happens in physical workshops.

It was a demo session, and it was happening in the evening when people are tired and possibly hungry, so there were a few things that could have made the situation worse, but here's a little summary of my observation.

• Body Language was gone - it really felt like modeling in a vacuum. When saying something, I was desperately in need of confirmation, a smile or a nod. All of this was gone. And I felt guilty whenever I was speaking for more than 20 seconds.
• The structure was not emerging quickly - some actions like grouping or removing duplicates didn't happen as quickly as we were used to. Probably due to the limited bandwidth. To remove a duplicated sticky in a physical workshop I need to find the owner - handwriting and proximity help - and ask permission - sometimes a silent nod is ok. To remove it in an online session I need to have space in the single main conversation just to establish ownership (all stickies look the same in digital) and then use the mouse to drag or delete. Slow. Boring.
• People were not talking - our voice was our only media left, and we were not using it. It could have been lack of structure, but it happened disturbingly often.

The tail of the session was even more annoying. The online conversation about the experience went quickly dysfunctional on twitter, ironically proving my point that face-to-face conversation is a lot better.

Something that can work

Ok, regardless of how much I didn't enjoy  the experience, I am still a compulsive improver so here are a few tricks that may help in this scenario.

• Seed structure in advance: Pivotal Events are usually emerging in the flow, but since the process is a lot slower, you may take the risk of cheating a little, and start with some structure in mind. But keep in mind that no matter how smart you are, this structure can be badly wrong.
• Enforce the game rules - Modelling is a collaborative game, with a few rules: all path need to complete, the grammar needs to be respected, stakeholders needs to be happy and hotspots need to be addressed. Keep the rules visible. They're only four.
• Establish Mob Modelling discipline: a strategy that plays well online is to establish leadership rounds of 5-7 minutes to improve the design. It's something similar to Mob Programming but not exactly the same thing, so don't be strict about it.

Physical modeling is still vastly superior to the digital format, in terms of efficiency and quality of exploration. But it can build on top of the discoveries that already happened during the Big Picture workshop.

Every digital modeling session will miss something. But it may be a reasonable price to pay. If you started with a physical workshop, you may be able to feel what you're missing.

Every online session will miss something. Can you estimate what you're losing?

If you're never experienced a real EventStorming session, you won't have any ground tom understand what you're missing, or how big your blind spots are. So, please, please, please don't start digital, and more than anything, don't call it EventStorming because there's no "storming" in it. It's an online collaborative modeling session, using EventStorming grammar.

Software Design

Software Design is format that can better tolerate the transition from physical to digital.

• The scope is probably smaller - I usually like to have a scope as large as process modeling, but you can also go incremental modeling at the beginning of an iteration.
• The duration can be shorter - 90 minutes is a reasonable session, clarifying enough aspects to allow development to move on, and to gather some insights from coding, in a Modelling Whirlpool attitude.
• Most of the participants are software people - they're more used to online interaction, and to the specific discipline required here.

If the original assumptions are still valid - most of all, if there's been an in-person Big Picture workshop before - then the cost/benefits balance trade-off can be acceptable. Especially if being colocated requires plane tickets and hotel costs. But - I am repeating myself - it's a trade-off: you'll be losing something, and more annoyingly, you might not be aware of what.

To be honest we do some online sessions in my company too. But I am a business person and a software architect in the same conversation. Wearing so many hats doesn't make me a viable example.

The blind spot

There's a giant blind spot if you're a software developer, and it's my duty to remind you.

EventStorming introduced a few ideas in the notation, for a very good reason. Lo-fi tools like sticky notes together with Fuzzy Definitions and Incremental Notation are intended to provide a safe space for interdisciplinary contribution, by allowing the simplest possible notation that makes a significant conversation possible and then progressively improve the precision of the discussion.

Existing notations, like UML or BPMN are more precise than our sticky notes, but this precision becomes a barrier for contribution. With EventStorming I tried to create a more neutral language, closer to structured storytelling than to software development, to allow a more collaborative contribution from every expert.

Some software people seem eager to bring the conversation back inside a tool - albeit more collaborative than the old CASE tools - possibly underestimating the impact that it will have on the other side of the conversation. It won't happen on neutral territory any more: it will happen on a modeling tool designed by software developers, with software developers in mind as an audience.

To sum it up:

Ok... then the pandemic happened, and a few things are no longer valid, or they may sound too stiff and pretentious, so it's probably time to have a look to EventStorming in COVID-19 times.

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.