Event Storming – how to use it for business processes analysis?

Have you ever thought, that the process you are in might be better, but it was hard for you to decide which part of it needs improvement? Or which part you should choose to get the best outcome? Especially when it was not the only process you’ve been working on at the same time.

Did you ever think that you had quite a good flow in your product but on the other hand you still had a feeling that you are missing some important details? Details that might be crucial for the success?

Or more specifically – did you ever made recruitment process mapping but it was too general to talk about improvements? Or it was useless during your conversations with technical recruiters because it was boring for them and not engaging enough to spend with you the time needed to collect all the data you might be interested in?

If you answered yes to any of those questions – I might have a perfect solution for you: Event Storming method.  At Pragmatic Coders, we used it to review our recruitment process, but you can use it also for other processes in your company, e.g. sales or marketing.

Event Storming lets you create a business model that can be used during the development of almost any process, to get the big picture of the environment, its needs, and goals, and to assess its complexity.

Business processes analysis – gathering the data

As a software development agency, developing software is what we do best. But what about other processes in the company? Usually to resolve a problem or make a business decision you need to gather information from different teams or departments.

When several teams or specialists are working on the same processes separately,  they tend to go in slightly different directions. In the end, it can make a big difference in the conclusions they draw. Is there a way to avoid that?

Software development is a journey that involves collective learning and close cooperation. But building a self-organizing and constant-learning company is even a more demanding journey. If there are well-checked methods for solving very complex software development issues, why not use them for other processes as well?  It might be a shortcut to a more engaging way of doing your business overviews and rebuilding company processes.

What is Event Storming

Event Storming is an engaging way to bring specialists from different teams or areas together, drive your analysis from the outside, and quickly explore complex business domains in hours instead of days or weeks. It was invented by Alberto Brandolini to create a business model that can be used during development, to get the big picture of the project environment, its needs, and goals, and to assess its complexity.

But going further there is more. Event storming supports group learning and is a great way to integrate teams that can have different perspectives on the same issue. It helps if teams want to create alternative solutions together (especially interesting for startups) by visualizing and selecting them. Event storming may also be useful for teams with a mature approach to order the process and find out about bottlenecks and areas of conflict.

Event Storming is an approach for modeling complex business flows. There are three basic strengths of this method – speed, collaboration, and clarity. How we went through the Event Storming workshop to learn more about one of our internal processes and the methodology itself?

Event storming in action – case study

At Pragmatic Coders, we have built a community of people who love to learn, share experiences, and experiment. Some time ago Kamil, one of our most experienced developers, came up with the idea to show us a methodology that helped his team to understand a client domain in an extraordinarily short time. He decided that it would be great if we can solve some internal company issues and at the same time learn a new method, which can be used in other projects.

Our main goal was to work on the basis of something that is familiar to us and will allow us to focus on the technique of Event Storming itself. This is how we have chosen the workshop material – the recruitment process. Almost all of our developers are recruiting, but they are mostly sharing best practices between their small technical recruitment teams and rarely with other teams.

How to start Event Storming workshop?

First of all, we needed to agree on who will take part in the workshop. It’s important to invite people who know the right questions to ask (typically developers) and those who will know the answers (domain experts).

Workshops like Event Storming work best only in a limited group, usually from 6 to 15 participants. It gives everyone the chance to be heard and express their thoughts.

We have chosen representatives from each technical recruitment team and also two “recruitment domain experts” – HR specialists (me and my colleague Ania), who know all processes from the beginning to the end.

The goal of our workshop was:

• Learning the Event Storming method and creating a visualization of the recruitment process with its possible improvements.
• Evaluation whether Event Storming could noticeably help teams in effectively expanding domain knowledge and modeling processes (flow / process / journey / etc.) and if it can be an integral part of the created solutions.
• Make it easier to introduce Event Storming to all teams at Pragmatic Coders.

We wanted to kill two birds with one stone – share Event Storming methodology and make improvements to the recruitment process itself. You might run the workshop to grasp the big picture really quickly and to provide a physical space where discussion around the flow happens.

Running an experiment isn’t that difficult. All you need is:

• A quiet room, with large space to contain the modeling surface, no tables and no chairs (during workshops people are standing, sitting is less effective, because movement helps to keep you focused and energized).
• A writable surface (e.g. an Ikea paper roll – codename Måla, you can find it in the kids’ area).
• A LOT of sticky notes, in different colors and shapes.
• Working markers, ideally one per participant plus backup.
• Some masking tape, just in case.
• The right people.
• A facilitator.

The facilitator keeps the group focused and engaged, guiding progress toward a complete model of the domain. This person will introduce the notation e.g. we use orange sticky for events (something that happened in a process and usually is known best by domain expert).

Running the Event Storming workshop

Step 1 – Domain Events

We briefly discussed the main goals and frames of the Event Storming method and the reasons why we choose the recruitment process as a workshop.

After this short introduction, we started by naming the domain events. We tried to answer the question ‘what happened’ in the context of our business domain.

The facilitator added the first post-it with a domain event to encourage everyone else. Then the group just ‘stormed’ the ideas, not focusing on the actual timeline. Some of the participants pointed out that it might be helpful to define the events marking the beginning and end of the business process so that it would be easier for people to continue. This part of the Event Storming is designed to encourage people to collaborate and let them integrate.

Step 2 – Explore the origin of Domain Events

“Why did this happen?” This was the question that we started the next session block with. It was a great way to ensure that we have the right chronological order in our events. It is relevant at this stage to point out to the participants that command is something that people can do in the domain, otherwise, they may become stuck in places where actions are not triggered by users, but other factors instead.

At the end of the block, we spent a moment reflecting on events and commands. We walked through the model forwards and backward to ensure that everything is covered.

At this point, I noticed that adding the commands and other triggers raised more discussion than during the first part of the process. People were actually asking questions and thinking about what should happen, adding new events.

Step 3 – Other triggers

Events may have their roots in commands, but they might also be triggered by people, time, documents, or external events. During this session, we filled our model with these additional elements. Some stickies with commands were now replaced by notes representing an external event or time.

Step 4 – Propositions of improvements

There was a time when the real magic happened! In silence, each person had an opportunity to give some propositions of action we can start to prevent possible problems or lower the barriers for the candidate and for recruiters.

During creation, a big picture is important to discuss a general context, highlight critical events, and flows. Then you choose the places where we can get the biggest advantage of making improvements.

You can find more information about Event Stoming metod in Kamil’s presentation.

Our key takeaways from Event storming for recruitment process

Our participants jumped from the role of developers to the role of recruiters, so the goal was understanding the system by asking the right questions. And we did it in a couple of hours. At the end of the workshop, everyone had a clear idea of what we were supposed to do with our recruitment process.

We had a few main takeaways:

• Keep the process simple – We had two kinds of recruitment processes: with technical hangout or technical task. It was not clear when to use which. Thanks to Event Storming we organized the process and  decided to do technical hangouts with mid and senior developers and send tasks only to junior developers.
• There was a space to share experience between people who create a bit different model of a technical interview and it was a base for remodeling technical interviews for other specialties.
• We should put a bigger emphasis to keep an internal tract of not only verbal but also written feedback between the recruitment stages.
• We made a list of points where we need to be more clear about things e.g. the moment of recruitment start, how we make the final decisions about the candidates, how we treat recommended candidates, how to help new recruiters to join the recruitment team, how to keep recruiters on the right track of recruitment needs.

I hope that you will find Event Storming as an interesting methodology and you will check it within your different teams and processes. We perceive it as very practical and we are using its elements constantly at our process modeling.