Our journey to Event Storming

As you may have noticed, or not, for some time we are talking a lot about Event Storming. This workshop technique amazed us at the first sight and we successfully incorporated it into our work standards. But it was a bumpy ride. Let me tell you the whole story.

Before...

Since the very beginning of Visuality, we have shared many values described by Alberto Brandolini. One of them is the beauty of personal contact. Whenever we start a new project, we try to meet our client and the project team in person. We travel to their office or invite them to our mansion. This is a great occasion to see how communication works and gain more information about the project or product. We organize a workshop meeting. We ask many questions and clients describe the most important parts of their business. Such meeting includes also developers who can get details about technicalities.

Unfortunately, we've always felt that those sessions are not enough. First, at the beginning of the relationship with the new client, we simply don't know their business. Thus, we don't know what we don't know. A bunch of right questions won't be asked. Second, people from the client side tell us only what they know or think. We don't have a chance to see their business from different perspectives. Typically, after such workshops, we know only the surface of a client's product. It's very visible in first sprints - developers feel often lost and lots of effort is put into describing tickets in a detailed way.

A change was needed

We started improving the process of gathering information. In the beginning, our CTO, Mariusz, introduced a more workshop-like style to the meetings. Using a whiteboard for drawing or designing things came naturally. But it wasn't enough.

At this moment Event Storming enters the scene. The method was mentioned in many courses, always in a very positive light. So we decided to try it out. We read about it, discussed it, made notes, and eventually performed a few internal ES sessions. It was a blast. So we prepared to use it in production, with real clients.

…and now

The technique created by Alberto Brandolini belongs to a different league when it comes to the amount of gathered knowledge. What is Big Picture Event Storming?

• gather key people in one room: managers, developers, representatives from different departments
• visualize all business processes on sticky notes and put them on the wall
• debate about all uncertainties and make events ordered
• profit.

I don't want to describe how exactly the Event Storming session looks like (you can read about it here or watch it here). Instead, I want to focus on how we use it and what profits we see.

New formula

Again, we try to meet the client in person and organize a workshop (although it's also possible to make it remotely). We invite more people - not only managers but also developers, QA, and people from other departments. We spend one or two days on Big Picture Event Storming, which is led by one of our consultants. This is no "one more meeting". We gather in one room and use tons of sticky notes. And we have lots of conversations and arguments. Eventually, we gain a deep understanding of the business and its most problematic places.

The biggest benefits:

• no preparation is needed from the client's side. Just one room (or online tool), colorful sticky notes, a blank wall, and key people. That's it and we can start.
• huge exchange of information. I can't compare it to any other workshop (or non-workshop) technique. Potentially, each discussion about problematic sticky notes reveals new information about the system. Or, provides the background behind the debated problem.
• a common understanding of the business domain. It's more than knowledge about certain features or bugs. It's learning which are vital parts of the business and what is the unique value of the company. Without it, developers could introduce correct code that won't reflect the business domain. With it - they can build software that is 100% tailored to business needs.
• flexibility. Each ES starts with a certain goal, but how you achieve it is up to the participants. Workshops have proposed flow, but it isn't mandatory. So Event Storming can evolve into drawing diagrams or context mapping sessions. Or even writing pseudo-code solutions.
• spreading the culture of openness. Event Storming efficiency is based on the number of questions and answers exchanged between people. Simply put: workshops need straight communication. If you are not afraid to ask evident questions to your CTO during ES, you will not hesitate to do it later too.

Few challenges

There are some things you need to be aware of when doing Event Storming:

• Find the right person to lead the workshop session. While participants don't need to know anything about Event Storming, a competent leader is a must-have. The skilled moderator needs to have a plan for every workshop. He or she needs to know how to interact with attendees. And of course - how to facilitate the whole process to make all discussions productive.
• Be ready for talking. Stereotypical software developers want to just sit in front of their computers and hit fancy keyboards. ES forces them to step out of their comfort zone and talk to real people. And talk a lot, sometimes about difficult topics. So you can imagine it's not easy for everyone.
• Prejudices. From our experience, we can tell that people from IT don't trust workshop techniques much. Everyone (at least once in their life) experienced a boring, time-wasting workshop. That's why kicking off the Event Storming session is very important.

To sum up

Considering all mentioned factors, Visuality uses Event Storming whenever possible. Initially, we schedule an ES workshop with our new clients. But we also do workshops for long-running projects. Or, we even do workshops for already finished projects ( aka retrospective Event Storming). In all cases, we see that the time and effort spent on Event Storming are worth it.