How we use EventStorming to make our processes clear

Like any other company, we have many processes at Easy LMS. For example, how we handle support tickets or develop new features. We use the Improvement Kata to optimize our processes. One of the first steps is to specify the current situation. However, it turns out everybody has their own view on what the current situation is. EventStorming is a technique we use to define our processes unambiguously.

Imagine you're a new employee joining a company. You're paired with a more experienced team member and go through all, mostly undocumented, business processes. You create a mental model of the process by asking questions and reading documentation. The more experience you gain, the fewer questions you need to ask and the less documentation you have to read. Most things, you'll do (semi-)automatically.

Less up-to-date documentation on a process will lead to more variation in the mental models employees have of that process.

Then, if you compare how you handle the process with another team member, you'll notice you do some things quite differently. This happens because your mental models differ.

When you optimize a process using the Improvement Kata, describing the current situation can be difficult when the mental models differ significantly. If only we had a way of turning these mental models into documentation.

How we came to EventStorming

Early 2020, I attended the Domain-Driven Design Europ conference to learn more about modeling our software better. One workshop that I wanted to join was about EventStorming. I read about it before, and I thought it could help us get domain-specific knowledge out of our experts' heads in a way that's easy to share with the developers. Meaning we could build better software. It turned out that EventStorming is very useful for modeling software but also for modeling business processes!

Unfortunately, the pandemic hit. We closed our office and started working remotely. EventStorming revolves around having a group of experts in a room working on a large shared surface. This was no longer possible to organize. Fortunately, Alberto Brandolini, the founder of EventStorming, also realized this and organized another workshop to solve this problem: Remote EventStorming. I joined it and afterward waited for an opportunity to experiment with EventStorming.

Modeling our development process with EventStorming

In the last few months, we've been changing our development process a lot. Sometimes, the process failed, and it became apparent that nobody had a total overview of the process anymore. The perfect candidate process to try EventStorming on!

I tell the team I want to experiment with EventStorming. I'm confident we can get a good overview of the current development process by doing this. I invite a couple of interested developers from both teams and create a shared remote whiteboard using Miro. We follow the default steps of EventStorming:

1. Chaotic exploration: create sticky notes for all the events you can think of that happen in the process.
2. Enforce the timeline: order the events from the beginning of the process to the end.
3. Enriching the events: add meta information to each event. The command (action) that fires the event, the data needed, the system that acts, and the policy that says what to do next.

Chaotic exploration

At first, it feels a bit awkward. But as soon as the first sticky notes appear, the pace really picks up, and everyone is into it.

We start by giving all participants their own piece of the whiteboard and a color (but not orange, more on that later). They have 25 minutes to create sticky notes for all the events they can think of that happen during the process. An event is something that happened in the past and cannot be changed anymore. That's why you write them down in the past tense. For example: "Code repository created" or "Code deployed to the production environment."

I encourage them to "cheat" and look at the events other participants write down because it can open up a whole new part of the process you didn't think of before. It's perfectly fine to add events that other participants also have.

Enforcing the timeline

After I notice that no new sticky notes appear on the board, we move on to the next step. I draw a line on the whiteboard. Then I ask everyone to pick their sticky note of the event that happens first in the development process and move it above the timeline. We shortly discuss which event is really the first and place it at the beginning of the timeline. To signify that we all agree on this event and its place on the timeline, we change the color of the sticky note to orange (that's why there were no sticky notes in this color before 🤓). Then we move on to the next event.

We get into a more extended discussion on an event. To keep the flow going, I create a special type of sticky note called a hotspot. On it, I describe the problem, and then we move on. We'll come back to the hotspots later on. We encounter an event that multiple participants created. We keep the one that describes the event best, and we remove the others. We also add branches for conditional events. We place them above or under the timeline of the primary process.

After two and a half hours, we stop. The timeline is done, and all hotspots are solved. Everybody is energized, and we immediately plan the next meeting to make the process clearer by enriching the events with metadata.

Enriching the events with metadata

Explaining this step works best with a picture:

At the start of our (sub)process (large black sticky note), we have to take action (blue sticky note) to divide work. To do this, we need information (green sticky note) in the form of the user story we're going to work on. Jira is the system (large pink sticky note) we use for this. When done, we have divided the user story into so-called sub-tasks. That's an event (orange sticky note). The development policy (large purple sticky note) then tells us our following action: to put a subtask into progress in Jira.

We follow the timeline and enrich every event. If we're unsure how to enrich an event with metadata, we create a hotspot and move on. Later on, we revisit all hotspots. Some hotspots we can't fix. For example, when we demo the story because that depends on the planning of stakeholders. Or when we create documentation for the story because that's not a part of our process yet. That's ok; we're just describing the current situation of our process. But it is something we can improve on!

Experiment completed successfully

Everybody is enthusiastic about EventStorming and the results we got out of it.

I was confident that we could get a good overview of the current development process by doing an EventStorm. In the end, we do indeed have a clear picture of our development process:

It's now easy to explain to others what our current development process is. We also know we're missing some essential parts in our current process.

I can't wait to start modeling our other business processes!