Extending the DDM modules in Liferay with custom field types isn’t that easy. This blog post is the result of our attempts...
EventStorming: how to understand every processKoen Wellens
Last month, well-known facilitator Alberto Brandolini taught us a few things about EventStorming. In his workshop, which lasted 2 days, he taught us the basics of the EventStorming technique as well as how to facilitate it. 12 lucky colleagues were part of this masterclass. Two of these are consultants at the same company and decided to try it out there. In this blog post, they’ve written down their experience with EventStorming and 3 tips for performing the technique.
EventStorming is a technique to visualize a process. This can be any kind of process, actually. Whether you want to display your business process, development process, or even your blog writing process. The idea is to write down every event that occurs during your process. For example, code is written or mail is sent. By putting all these events on post-its and hanging them on a wall, you think about everything that needs to happen. Thanks to the visualization, you’re also able to indicate concerns, issues or opportunities.
“It’s not your understanding that’s going to be shipped into production. It’s your developer’s misunderstanding. I want to visualize that.”
– Alberto Brandolini
Given all these events on your wall, you create a shared understanding with everyone in the room. Everybody now knows all the steps of the given process. You’ll be able to spot bottlenecks by looking at all the concerns or issues raised during the discussions. This makes sure you’re all working towards the same goal!
Alberto started the workshop by welcoming us and wasted no time getting right into the action. He phrased it as : “I’ll teach you how to swim by throwing you in the water”. Just like that, we were given two simple rules: we needed to use orange sticky notes and verbs in the past tense. That was all we needed to generate the events of his workshop’s use case.
We put our post-its on the wall, describing events as we thought fit. Afterwards, we went over these as a group. Alberto taught us that it’s not only important to look at the post-its, but as a facilitator you need to register the way your participants behave. In many cases, their behaviour already predicts the outcome. For example, when people hardly participate in putting events on the wall, it’s probably because they don’t know or understand the process they’re supposed to work on.
Putting the theory to practice
Two of our colleagues are currently consultants at the same company. They decided to take this technique and use it to improve some of the processes there. They had a look at development process and the release process of the company’s software department.
After explaining EventStorming and its benefits, the developers did not have a hard time visualizing their development process on the wall. We held important discussions and they asked some great questions, such as: are we doing enough pair programming? Is everybody doing test-driven development? This session went furthest with the theory we were given at the masterclass. Not only did we highlight events and concerns/issues, the developers were also able to indicate commands and actors. Even systems and opportunities were visible after the session.
When we handled the release process, we invited developers as well as ops engineers. A lot of events were put on the wall about deployments, risk documentation and security assessments. Again, there was some discussion. Do we really need four environments? What kind of testing (performance, penetration, regression, etc) does everybody do? These are just a few of the many questions that arose during the workshop.
The participants of the sessions were excited about EventStorming. Afterwards, they took actions to tackle the raised concerns and issues. Sadly, we couldn’t complete the workshop in which we handled the release process, because we’d timeboxed it. We couldn’t ask the developers and ops engineers whether they wanted to do a next session because they beat us to it. However, we planned a follow-up workshop in a few weeks!
3 tips on facilitating an EventStorming workshop
During these workshops, we’ve had the opportunity to experience some of the pitfalls Alberto Brandolini warned us about and put his sound advice into practice. Here are a few lessons we’ve learned.
1. Make sure your wall is long enough
Make sure there is enough wall during a session. We did our EventStorming workshop about the development process on a wall with a pillar in the middle. Stickies on the right hand side of the pilar were less discussed because they weren’t as visible.
2. Let your participants put the first sticky on the wall
Don’t lead by example here. If you do, you’ll be likely to be putting all sticky notes on the wall for the rest of the workshop. Instead, invite the participants to create the first post-it. Afterwards, you’ll see them flourish in your EventStorming session!
3. Don’t stop naming things
While it is in our nature to do so, we tend to have a lot of discussions about how we name some concepts. It’s actually better to have multiple names for the same concept on the wall, as long as they’re all used in the company of course. This visualizes the core of what will probably cause miscommunication due to different names for the same concepts.
Does EventStorming spike your interest?
At ACA, we really believe in this technique. Not only does it help us understand processes we work with, it creates a shared understanding for us and our customers. We’re able to highlight bottlenecks and point out the lack of ubiquitous language through the process. And we can also do this for you! All you need to do is contact us and we can provide you more information or even host an EventStorming session with you. The call is yours!