After going through why Event Storming uses post-its, we’ll go over alternatives. We’ll then see how to use these techniques to improve Event Storming!
We regularly launch new ambitious projects at work. Event Storming is becoming the de-facto standard to get everyone on board quickly. A few months ago though, I was asked to animate an Event Storming… Without post-its! Attendees were not at ease with walking around and discussing in front of a wall of post-its.
Indeed, Event Storming uses a lot of (orange) post-its. If you hate those, it might be difficult to swallow…
Why Event Storming uses Post-Its ?
Here are a few reasons why post-its work well for creative workshops:
- They are not set in stone. It’s easy to move them around, and to throw them away. This unlocks a quick feedback and improvement dynamic.
- They are introvert friendly. Speaking up in front of everyone can be a challenge for introverts. They will find it a lot easier to write something down and stick it on the wall.
- They work well around HiPPOs, who risk silencing down any other idea at the time they enter the room
- People need to stand up and walk to stick their post-its, which creates engagement
- Humans are visual animals. We are well equipped to grasp complex topics at a glance at a wall of post-its. We were never built to learn through long documents or emails
- Finally, such visual radiators are an invitation and support for discussion
It’s not by accident that designers were the first to use post-its in their creative games. (Check Why are designers obsessed with post-it notes ?)
Traditional (doc and email based) architecture approach take months to get to something.
💡 Thanks to post-its, Event Storming speeds up drafting an architecture from months to days !
What alternatives do we have ?
Ok, got it, you still don’t want to use post-its.
In Want To Be A Great Designer? Ban Post-It Notes. The author suggests we should drop Design Thinking and do Design Building ! The idea is to skip the ‘post-its’ phase completely. Start building something and get feedback. He suggests 2 flavors of that.
Homework and Feedback
Every participant starts by designing something on their own. Next step is to share it with others to get feedback. They then rework their design and share again … and so on until they reach a consensus.
Suppose we want to get out of the workshop with a target functional architecture. People could draft one on their own, and then all share their design in a group session. Then repeat …
The more realistic the design, the more interesting the discussions will be. Drawing ideas from Event Storming and DDD, participants could:
- Identify core, supportive and generic bounded contexts
- Highlight upstream / downstream bounded context relationships
- Define interaction patterns between bounded context
Event storming creates high value secondary outcomes, like problem detection & knowledge transfer. I don’t know how this format would perform according to these.
As I said, the more realistic the design, the better. Pushing this logical to its conclusion, we could build a walking skeleton.
Here is how to use the Walking Skeleton to draft an architecture. Setup a single small end to end and high skill team. This team can start by building a first end-to-end feature. They’ll collect feedback and improve the architecture with every features they’ll add.
Here are the benefits of the Walking Skeleton
- All design and architecture is done with code, by the team working on real problems. Not in big upfront design sessions
- The team delivers end to end features from sprint 1
- We can test Non Functional Requirements can also from day 1
- Finally, the team structure can grow and emerge from the initial team’s work.
Alberto Brandolini (father of Event Storming) suggests the team can maintain a functional architecture as it builds the system. Check Strategic Domain Driven Design with Context Mapping for more details. In Living Documentation, Cyrille Martraire suggests to go even further. The team can actually generate the diagram from the code. That’s as realistic as diagram can be!
Apart from that ?
Surprisingly little! Searching Google with many post-its hater keywords I only found these :
- The Dark Side of Sticky Notes Which highlights the dangers of the glue for people
- Wait, We’ve All Been Using Post-It Notes Wrong This Entire Time?! Which explains that we should be unfolding post its from the side rather than from the bottom !
- In Defense of Post-its explains that post-its are not a silver bullet and can be miss-used. Fortunately, Event Storming got it right 😀.
Mixing the best of all Worlds
The interesting conclusion is that none of these approach exclude Event Storming! Mixing all strategies, here might be the best way to use Event Storming:
- Setup a tight team of domain experts and skilled developers
- Do an Event Storming all together
- Build a walking skeleton
- Get feedback and learn
- Re-do Event Storming (or others)
- Refactor and improve the walking skeleton
The true value of Event Storming is in fast communication within a whole team. By removing middle-men, we save time, money and stress.
💡 Don’t forget that Event Storming builds on a cross-disciplinary team and incremental architecture!
"It's not stakeholder knowledge but developers' ignorance that gets deployed into production" #QuoteServer— Alberto Brandolini (@ziobrando) 27 mai 2016