How To Ruin An Event Storming With Two Little Techie Mistakes

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. ― Antoine de Saint-Exupéry, Airman’s Odyssey

By Philippe Bourgau, under CC BY-SA 4.0, high resolution image

If you are not careful, you might get carried away by Event Storming and make these newbie mistakes! Here are two anti-patterns that people with technical backgrounds are particularly subject to! Unfortunately, these mistakes can transform a successful Event-Storming workshop into a mitigated initiative and leave participants with a sour taste.

Fortunately, these two anti-patterns are easy to avoid! So keep them in mind, and everything will go great!

Mistake 1: Continue the workshop until you reach a big-upfront design

Event Storming is a design activity. Like any design activity, we can push it too far. You can always add more refinement to your design. You could spend weeks doing detailed Design-Level Event Storming and filling Bounded Context Canvas for all your subdomains.

By doing this, you would return to the usual Big Design Up Front: spending time and energy on design activities instead of learning more by building something and adapting. Event Storming is not another way to do Big Design Up Front. Event Storming shines to create a Rough Design Up Front.

You will have better results by timeboxing the workshop and following the walking skeleton approach:

1. Set a timebox for the workshop—never more than two full days! Big Picture Event Storming often takes one day, and you can run follow-up activities on the second day.
2. Draft just enough to get started
3. Build something
4. Learn from it
5. Repeat

Mistake 2: Talk about Domain Driven Design (aka DDD)

By Philippe Bourgau, under CC BY-SA 4.0, high resolution image

Event Storming and Event-Driven Architecture came out of the Domain Driven Design communities. DDD is one of the most powerful tools to build solid software systems. Yet… It’s also full of obscure concepts and alien jargon!

This is especially problematic when doing a Design-Level Event Storming, which goes deep into the DDD concepts. Starting with this flavor of Event Storming might be too big a step for people who don’t know DDD.

Here is what you should do instead:

1. If you can, replace DDD keywords with synonyms that the participants will be more familiar with—for example, Functional area instead of Bounded Context. You can quickly mention the DDD name to DDD-savvy participants.
2. If you cannot find a satisfactory synonym, slowly introduce the DDD keywords and concepts, one by 1, only as needed during the workshop.
3. Start with Big Picture Event Storming. It lets people get used to some DDD concepts.
4. Only later dive deeper with Design-Level Event Storming

People may love it so much that you might start to do Domain Driven Design more explicitly!

Bonus tip: share with your participants!

I said it would be easy! Just remember these two anti-patterns as you walk into the Event Storming room. Whenever you catch yourself doing one of these, stop! If you are the facilitator, you can also remind the participants of these two pitfalls at the beginning of the workshop. Finally, whether you are the facilitator or a participant, if you feel the workshop is drifting towards any of these mistakes, raise your hand and voice your concerns!

---

This blog post is part of the 1h Event Storming book that we are currently writing.

This post was built from 2 posts originally published on Philippe’s blog 7 tactics that will make your DDD Design-Level Event Storming pay-off and 21 More Event Storming Tips