Is getting the developers and the business stakeholders in the same room the way to build a quality product? Well, according to Alberto Brandolini, the creator of the concept of event storming, the answer is, “Yes!” This article explores everything you need to know about event storming.
Who would have thought that colorful sticky notes could be the solution for all the long and inefficient conversations between developers and business stakeholders when building a product? Well, Alberto Brandolini did and wrote a book about it to share it with the world.
Years ago, the only ways to learn about your business systems was to map your processes using technical modeling practices or to use costly trial and error to write the code as you go. Now, these models still work and have done their job before the concept of event storming took off. Yet, these models’ technical nature meant that some domain experts were left out of the conversation.
Then, event storming came into the scene and not only simplified the approach but also included multiple levels of stakeholders in the business. It takes a bunch of colorful sticky notes and a willing group to reveal business processes more efficiently and enjoyable.
So, what event storming really is? And how do you use this model with your team? Keep reading below.
Event storming, explained
Don’t be fooled by the fancy name, event storming isn’t rocketing science, and any team can use it to understand any technical or business domain, especially those that are large or complex.
So, what event storming really is? It is a rapid, engaging, and lightweight group modeling technique that incorporates facilitated group learning practices from Gamestorming and domain-driven design principles. Simply put, it is basically a type of workshop when the whole team, including both developers and business stakeholders, meets and uses magic-whiteboard paper and colorful sticky notes (of varying colors) that symbolize events, actors, and puzzles.
But what is event storming used for? This workshop-based approach to finding out what is happening in the domain of a software program can help developers, and business stakeholders create a business model they will later use during the development process. It enables the team to understand the big picture of the product environment, what its needs and goals are, and how complex it is.
In other words, event storming is all about conversation used to understand business objectives and product goals.
Why use event storming? Event storming is different than other process modeling techniques by being significantly faster and, let’s be honest, a lot more fun. What’s more, it facilitates conversation and collaboration between business and IT by establishing a common and shared language by both departments.
Tips for facilitating event storming
Now you know what event storming is, and you may already have an idea of how it can help your team. But how do you make sure that your team will make the most out of this workshop-based approach? Here are a few crucial tips that will help facilitate event storming.
Offer domain-specific learning material
If your business has a complex domain, developers will have a lot of new stuff to learn. What’s more, think of the new-joiners who may have a hard time following the discussion during the event storming without understanding your business domain first.
So, make sure you share snippets before the workshop so that everybody who takes part in it knows what you’ll be talking about.
Prioritize sharing
Although event storming incorporates group learning practices, the number 1 priority isn’t that everybody learns everything during the workshop. The no. 1 goal is knowledge sharing, and the second goal is learning.
Think about it: what truly matters is that, at the end of the workshop, developers understand your business domain and can transform your business goals and processes into software. So, prioritize knowledge sharing so that the workshop is efficient.
Ask candid questions
One of the tips shared by the event storming concept’s inventor, Alberto, is to play the silliest person in the room to facilitate the workshop. Why? Because the silliest person is the one that asks the candid questions that lead to more discussion.
However, when you ask these questions, make sure that you are following the content of the workshop so that you don’t miss important points or overwhelm the team.
Ask newcomers to write down definitions
Who can better play the silliest person in the room than the newcomers who have very little knowledge of what you are talking about?
If you are the facilitator, also playing the silliest person in the room can be tricky, so you can leave it to the new-joiners to ask the candid questions and write down the answers.
What’s more, since the newcomers know very little about the domain or the business, they are more likely to eliminate all the “noise” and detect the most important buzzwords.
Give time to rest
If you are a business representative, you may be following the saying that “time is money” and want to make the most out of the workshops. So, you probably neglect the fact that breaks are important too because people who get tired aren’t that effective anymore.
So, give your team time to rest and come back with a fresh mind. This may help them come back with smart ideas they couldn’t think about on an empty stomach or with mental fatigue.
End the workshop with giving tasks
The worst thing that can happen is investing a lot of time and effort in your event storming, building some shared understanding among business stakeholders and developers, and then doing nothing with it.
To make sure this doesn’t happen, you should book the last 30 minutes of the workshop’s agenda for agreeing on the next steps. In other words, take time for delegating tasks after the workshop is done.
