top of page
Search

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:


  1. Typically organisations work in silos. And they work inconsistently across silo boundaries.

  2. 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.

  3. 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:

  1. Big Picture – To align a large team, up to 20 persons at the same time.

  2. Process Modelling – To model and agree on a specific process, around 5 - 8 people at the same time.

  3. 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

  1. You need a room with a large wall. Up to 16 m for a large session. Prepare the wall with whiteboard plastic.

  2. Let the participants write down Domain Events. A domain event is:

  3. written on an orange sticky note

  4. contains a verb written in past tense

  5. relevant for the business domain

  6. 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.

  7. Add additional information:

  8. people on yellow sticky notes

  9. systems on pink sticky notes

  10. problems on red sticky notes

  11. opportunities on green sticky notes

  12. 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:



153 views
bottom of page