21 More Event Storming Tips - part 3 - Anti and Meta Patterns
Even more Event Storming tips! 3 will help you to avoid the mistakes we did. The last 2 are the recipe to learn more tips by yourself!
ℹ️ NOTE: Parts of this post has been republished and updated on the Event Storming Journal blog
This was the last of a 3 posts series compiling Event Storming best practices. The previous post contained tips about facilitation and dealing with existing code. If you haven’t you might also start by the beginning!
Anti-patterns
As we tried variations around Event Storming, we also learned from our mistakes. Here are a few:
17. Adding special post-its
Before getting Alberto’s advice about logging decisions, we tried to use custom post-its. That did not work well. Event Storming already has a pretty large post-it bestiary, adding more is too much. Plus, it’s almost impossible to find a post-it color that is not already used!
When we tried this, people ignored these post-its. They made decisions but did not record them.
18. Remote participant
Our company is over 3 main offices: Beirut, Dublin, and Paris. With this constraint, organizing an Event Storming is often a mess. We have to bring some key people from different cities to the same office. Sometimes, we have to delay a workshop for a few weeks because a single person is missing!
I heard good feedback from remote-robots at a conference. We thought we could give it a try for Event Storming. The idea was:
- Pair up the remote participant with someone in the room
- Let the remote attendee contribute through his robot-avatar
We could not pay for a robot without being sure it would work. We tried to hack one with a moving speaker desk and a laptop… This was a disaster! The only outcome was that the poor remote-guy ended-up with a headache…
Up to now, we did not find a satisfying way to run an Event Storming with remote participants.
19. Big Design Up Front
Event Storming is a design activity. Like any design activity, we risk pushing it too far. I wrote that it works best as a tool to do a Rough Design Up Front.
You can always add more refinement to your design. I’m sure you could spend a full week doing detailed Design-Level Event Storming. Though that’s not how it’s meant to be.
You’d have better results by:
- Drafting just enough to get started
- Building something
- Learning from it
- Repeating
Meta
Here are 2 extra ‘meta’ best practices about Event Storming.
20. Create an Event Storming community of practice
Spreading Event Storming in a small organization is straightforward:
- Get everyone in
- Make it a success
- You’re done!
It’s a lot more complicated in large organizations. Building a community of practice helped us a lot.
We started ours as I animated a training about Event Storming to other people in the company. We ended this training with time for open discussions. This was the first ‘community’ meetup.
We then created a wiki space and a chat channel. We used them to exchange best practices and experiences around Event Storming. It’s a great way to learn from each other. It’s also very encouraging to hear other’s success stories.
21. Ask Alberto!
You might have noticed that some of these best practices come from Alberto Brandolini. I don’t know Alberto in person, but he’s kind enough to answer my naïve questions on Twitter. So I guess he would answer your questions too!
Run your own!
Event Storming is a magic workshop that unlocks complex decision making in a short time! It can help you with:
- Agree on a target functional architecture
- Decide what to buy or build
- Decide what to rewrite or refactor
- Self-organize the best team structure for your architecture
- and a lot more
Running an Event Storming is rather simple once you get the hang of it. The trick is to get started! Find a forgiving audience, and follow the guide.
I hope these tips will help you along your Event Storming journey. Whenever you discover your own tips or anti-patterns, take a minute or so to share them with a comment!
Leave a comment