EventStorming is a collaborative workshop technique with roots in the Domain-Driven Design Community. At an EventStorming session, which typically lasts an entire day, business experts, developers, and other stakeholders come together to model their collective understanding of a complex business process. By intent, every workshop starts out somewhat chaotically. People are introduced to the task at hand (identify business events) but quite often are uncertain about whether they’ve identified a meaningful business event.
Our latest experience report podcast is with Kenny Baas-Schwegler, who presented an experience report at Agile2019 on EventStorming, and Alberto Brandolini, the inventor of the EventStorming technique. Kenny and Alberto also presented EventStorming sessions at Agile2019.
In our conversation, Kenny, Alberto, and I discussed the benefits of EventStorming as well as tips and techniques for getting people to come to a mutual understanding. We continued this conversation, joined remotely by Paul Raynor, on a VirtualDDD meetup live broadcast also recorded Agile2019.
EventStorming workshops can be conducted either to model a high-level or “Big Picture” view of a complex business process or to model events at the system architecture level. Kenny’s experience report describes a Big Picture level EventStorming session and what followed after that event.
Early on in any EventStorming workshop, to soothe people’s anxiety Kenny, “tell[s] people that there will be chaos but that we will eventually bring order to it. I get a lot of laughter when I tell them this, although some people become worried. I’ve found that many people can’t easily handle this unstructured agenda at the beginning, which is why it’s so important that I tell people everything will be fine.”
After the group has individually written down events and placed them on the wall, they are asked to arrange those events in “time order.” Much discussion follows. People may be uncertain about whether an event is at the “right” place on the wall. They may disagree about whether something is an event, whether an event is in scope or not, whether or not two events are the same event, or whether one event should be two. They have to sort through these issues through conversation and discussion. As they do, they tell each other stories and share memorable experiences.
Once the events on the wall are sorted out, someone is asked to tell a story from the beginning to the end of the timeline. “At the end of the day,” Kenny says, “we finish the workshop and ask everyone to vote for a constraint or opportunity they think will help the entire line of business the most. We give each person two arrows to place on the wall indicating their votes. The one that gets the most votes becomes … the bottleneck that needs to be fixed.”
“At first look,” Alberto says, “EventStorming is deceptively simple: just have a long paper roll available, and a virtually unlimited stock of colored sticky notes and start modeling problems that looked too big to be modeled. But the ability to visually master large-scale complexity opens the way to many interesting outcomes.”
Since our conversation at Agile2019, I had the opportunity to visit Kenny’s company, Xebia, to observe a half-day modeling session organized by Kenny and his colleagues. In just a few short hours, that group identified dozens of business events and agreed on one area to focus on improving. It all seemed to happen smoothly (in hindsight, it was accomplished by light touch and highly effective facilitation). People walked into the room with wildly different experiences and expectations. But they left with a sense of purpose and shared understanding.
There’s one key point about EventStorming to emphasize: Successful collaborative modeling doesn’t happen by chance circumstance. At first glance, facilitators may not seem to be doing that much. However, facilitators pay careful attention to small details. They give attendees just enough guidance to start, but not so much that they rely on them to offer opinions on the events being discussed. Facilitators occasionally make small nudges by noticing and remarking on what they see. For example, a heated discussion may occur around some events on the wall, or people may be talking away from the wall, not adding newly mentioned events. After pointing out their observations, the facilitator steps back and lets the participants sort things out themselves. Aided by this skill combination of observation and gentle nudging, a shared understanding emerges.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
