How I Discovered Event Storming
The problem
For around 20 years I've been working with software, usually with enterprise software development, at the intersection of business and IT. I’ve seen countless failed projects. I've worked with projects that I thought would be successful at the time, that ended up failing. More than once I took part in building solutions that never got used as intended. Or never got used at all.
One example was a company in the construction industry, let's call it JCC Construction Ltd. At JCC all the sales reps created offers using Word. One of our project goals was to replace Word with a centralised Offer & Order Management System. The purpose was to enforce the use of templates, gain more control, create better sales forecasts, and quickly convert offers to accepted orders. Then new signed deals could easily be passed on from sales to the next person in line: project managers and supply chain staff.
We made deep interviews with all relevant stakeholders. We turned every stone. We went to great lengths to accommodate for every department’s needs. We iterated and made sure to get plenty of feedback. Still, to make a long story short, the project failed. The system never got used by sales.
But why? We had done a solid job to the best of our knowledge, right? Well… there was one thing that in hindsight should have made us more worried. We had discovered that some of the detailed information we got during interviews with different departments were not fully consistent (for example, there where different views on the structure and price model of certain articles in the system, sales wanted more freedom to choose suppliers). In these cases, where we found inconsistencies, we did additional interviews and if that still didn’t resolve the conflict, as a last resort we asked the most experienced domain expert in the area to make the call. This was, it turned out, where we went wrong.
I think it wasn’t until I saw Alberto Brandolini’s talk from DDD Europe 2019 (the inventor of EventStorming) that I learned to fully express the problem:
Typically organisations work in silos. And they work inconsistently across silo boundaries.
If you do isolated interviews, you end up with pieces that don’t fit together. If you translate these pieces to software, it won’t work.
So you turn to the domain experts and let them decide. And this is were you get the wrong answer. Because domain experts also work in silos. They also don’t have the full picture. Often no one has the full picture.
The organisation is not aligned and no one has the full picture of how it is supposed to work!
The solution
Ok, so where do we go from here? The challenge looks substantial! Do we have to wait for the organisation to align themselves before we can move forward? This sounds like change management? Which sounds like it won’t happen, right? This is where Event Storming comes in! Instead of waiting for the organisation to align, Event Storming sets a highly ambitious goal:
Let’s explore the domain
Let’s visualise the inconsistencies
Let’s create consensus around the key problems and their solutions
Let’s align the silos
Let’s do it all together
Let's do it fast! In one day!
Ok, so how do we do that?
I won't cover all details here, instead give you the high level and some links to other blogposts and videos. On a high level, there are 3 kinds of Event Storming:
Big Picture – To align a large team, up to 20 persons at the same time.
Process Modelling – To model and agree on a specific process, around 5 - 8 people at the same time.
Software Design – Same a process modelling but here we take extra steps do design software components.
In the example with JCC above, Big Picture Event Storming would have been the right choice. Because we would have needed to align a large group of people, up to 20 stakeholders from different departments.
Before I knew about Event Storming I was never able to facilitate a truly effective meeting with such a large audience. Either it turned to chaos or I had to run the meeting so strictly to the agenda that I killed the creative discussion.
Big Picture Event Storming is an extremely effective workshop format for up to 20 people at the same time. It's designed to first of all make everyone in the room understand the business, not just in their own silo, but understand it across silo boundaries. First after we understand the business we can move forward and decide on our needs.
Big Picture - Summary of the steps
You need a room with a large wall. Up to 16 m for a large session. Prepare the wall with whiteboard plastic.
Let the participants write down Domain Events. A domain event is:
written on an orange sticky note
contains a verb written in past tense
relevant for the business domain
Let the participants arrange the domain events on a time line. This is where everyone is forced to interact and understand the business outside their own silo.
Add additional information:
people on yellow sticky notes
systems on pink sticky notes
problems on red sticky notes
opportunities on green sticky notes
Finally vote for the most important problems to fix or the most important opportunities to explore.
An Event Storming session is a massive learning experience. When every person in the room understands the business across silo boundaries, then alignment tend to happen naturally. When we all understand each others problems there is not much left to fight about. You are almost guaranteed to leave an Event Storming session with:
A whole new level of understanding of the business
Alignment across silo boundaries
Consensus around the most important problems to solve
Does this sound interesting? If you want to discuss Event Storming feel free to reach out. You can use our contact form here.
More info
Here are a few links with more information:
