Decoding complexity: EventStorming insights
Dealing with complex problems brings significant challenges: the sheer scale of operations, the interactions between components, or the inherent complexity of the domain itself. These challenges often give rise to communication barriers and divergent perspectives, frequently causing delays in progress. In such intricate scenarios, achieving a shared understanding among teams becomes pivotal.
In 2013, Alberto Brandolini created a series of workshops called EventStorming to ease the communication challenges and enhance the decision-making process. The essence of these workshops is to gather a group of individuals in a shared space and, by generating a unified perspective of the problem, design a solution in a collaborative way.
In this article, I will share what I have learned running EventStorming workshops at ClarityAI. I firmly believe that it’s one of the most valuable tools for you and your team and you will benefit enormously from implementing them in your projects.
But first…
This article is for you if you are…
A tech person
You are used to making many micro-decisions based on documentation, meetings, tickets, and conversations, and you think more is needed. You want to understand where the product comes from and the impact of your work. You don’t want to do a lot of re-work.
A non-tech person
You want to understand where the complex parts are and grasp how it’s done. You want to see where the bottlenecks and pain points will be. You want your colleagues from tech to understand you and vice-versa. You want to confirm why your product is the best or where it can be improved.
What is EventStorming?
EventStorming is a flexible workshop format for collaborative exploration of complex business domains. [Source EventStorming.com]
This workshop aims to model a complex process (line of business, feature, etc.) collaboratively to explore, analyze, visualize, and agree upon its details.
For this workshop, we only need two ingredients:
- to invite the right people: a combination of domain experts and tech
- to have unlimited space and tools: a wall (or roll of continuous paper), sticky notes, and markers
We will use sticky notes to create a visual representation of the different aspects of our domain and the interactions between them. The colors of the sticky notes are used to make it easier to distinguish between different types of elements in the model.
A team-building experience
Mostly, it’s a great team-building exercise because it is not about the system or the process under design; it’s all about people. Everyone invited has unique skills and knowledge, and we want them to be together as soon as possible. The value will be in the interactions between each other.
What if you work remotely?
Absolutely no excuses! At ClarityAI, we operate as a fully remote company, conducting sessions seamlessly through tools like Miro. While it might lack the thrill of in-person interaction and multiple parallel discussions, it will be enough to run a productive workshop.
Types of sessions
A complete workshop has three flavors, depending on how deep you want to go on a particular process. These sessions follow a progression from a broad, strategic overview to more detailed technical discussions. As we go deeper into the exercises, we might find it optional to excuse individuals less familiar with technical aspects.
Disclaimer: there is no need to do all sessions; we often do just Big Picture and Process Modeling. Optionally, the developers finish (remotely) with Software Design.
1. Big picture
Here, the objective is to provide an overview and a high-level understanding of the business. We will make sense of a big mess. It’s a large workshop. The sweet spot to me is up to 20 people, but it could be even 30.
Outcomes:
- the whole process is visible using events
- massive learning, silos are broken
- reach agreements on some core problems
- visualize pain points or bottlenecks
- value propositions
2. Process Modeling
Here you will create a visual roadmap of how actions flow within a system. It details steps, interactions, and dependencies with other systems. Serves as a basis for refining, standardizing, and improving specific processes, aiding in better performance and efficiency. Also, you will enforce the ubiquitous language.
Outcomes:
- policies: business rules (whenever this happens, that will happen)
- external systems
- commands: the actions that trigger events
- consistent language among all the areas
3. Software Design
The most technical of the sessions. You will talk code and model the solution at a deeper level. EventStorming is considered under the umbrella of Domain-Driven Design (DDD) practices, so it’s where you will talk about its tactical artifacts.
Outcomes:
- aggregates, entities, value objects (VO’s)
- domain events
- bounded contexts
- commands & queries
The tools
As mentioned above, we will use sticky notes to help us visualize every piece of the process, with the Events at the center of our narrative and a common guest during all exercises.
When should I use it?
Arranging this kind of workshop requires a lot of effort and takes many resources. You may wonder when it’s the appropriate time to run them. Here are two scenarios that I find will be perfect for applying EventStorming:
There is an existing process that you want to know deeper
This is the perfect scenario to start. The domain experts, and hopefully almost everyone, know what we will discuss, but you want to shed light on some aspects of the process. This scenario also serves as training for you and your team, providing an understanding of the exercise’s dynamics and paving the way for tackling more complex ones.
You want to design a new complex process
You have a new feature, a new line of business, etc…, and you want to move fast. The best way is to get everyone on the same page. Here, the product team (or the domain experts) plays an important puzzle piece. They will have to explain what we want to do, and everyone will ask questions to cover all the possible scenarios.
Some tips that may help you
EventStorming is fun, but it’s hard work. Here, I leave some insights that you might find helpful when facilitating a workshop:
- Keep the flow going: it’s better to put your ideas into the board and later discuss them. If you have doubts about a specific sticky note, rotate it 45º to return to it later.
- Try to postpone long debates: save implementation details or long discussions for later. If it takes too long, people will start to disengage. You’ll have the chance to schedule a specific meeting for that.
- Chaotic exploration: invite everyone to add sticky notes at their own pace (chaotic exploration); you will see how fast your board will be filled up. When you see that the rhythm is decaying, start the guided exploration. You can time-box these parts, but I encourage you to read the room temperature and know when to jump from one to another.
- Guided exploration: time to listen to what we have on the board. Invite somebody to explain a “story” by reading their sticky notes, starting from left to right. Invite people to question what’s on the board.
- Enforce the ubiquitous language, but not at first: as soon you have come up with a timeline, review if you are being consistent with the naming. Rewrite the sticky notes to match the language in use.
- Reduce distractions: we need to ask many questions and generate debate. Try to keep people away from computers and invite people to focus on the subject when conversations drift.
- The most important: there’s only one correct way to peel a sticky note. And it is from left to right (or vice-versa).
Resources
If you want to learn more, here are a few resources that might help you along the way:
- Alberto Brandolini‘s talk: Event-storming and DDD
- An excellent guide to how running a workshop: Event storming recipes
- More on Process Modelling: Collaborative Process Modelling with Event-storming
- How to do remote EventStorming: Remote EvenStorming
