Last year I was introdu
ced to a new (for me) workshop format, called ‘Event Storming’. It is a technique developed by Alberto Brandolini and is meant to quickly explore complex business domain. It has already been adopted within the Domain Driven Design community.
When I learned about it in a Domain Driven Design workshop by Mathias Verraes I wanted to try this at my own company. Last week I finally got an opportunity. Our team will start developing a new application that will replace a pilot project. This gave me the chance to run an Event Storming workshop.
It was a nice experience. I had to facilitate the workshop myself, which gave me two problems:
- I never facilitated a workshop before and certainly not one that I had only experienced once myself.
- I would have to restrain myself to be only facilitator and to leave the discussions to the participants.
However, I found a blog post of Verraes where he lists some tips based on his own first time. These were very helpful. I will describe my own experience here for other people. Maybe it will help someone like me, looking for tips&tricks.
Organizing the workshop
First I introduced the idea of doing this new workshop as an experiment. Luckily our product owner and two stakeholders from the business liked to do an experiment. I mentioned that this new technique is very useful in transferring the domain knowledge to the team. It was actually very easy to arrange a 3-hour block in everyones agenda.
Then the next hurdle was that I had to keep the number of participants low. At the one hand, I wanted the whole team to be present, since everybody needed to gain domain knowledge about the new application. On the other hand, we also needed enough domain experts to be confident we could answer all questions from the team. In the end we had 9 people, including myself.
What I learned during the workshop
The workshop went very well, although there were certainly things I could have handled better. I decided to let people find out the ‘why’ of the several steps by themselves. For example, I let them work on the domain events, without much of an explanation why we worked this way. I hoped they would find out themselves later on. This caused some confusion, especially from the business people who compared the technique to some Lean workshop they did. People found it also hard to write their notes in an ‘event style’ like “A product was added to the shopping cart”. Maybe some better explanation of this step would have prevented this.
It was very interesting to see that once you start adding the commands to the events, the real discussions start. At this point, it becomes clear for all participants that alternate flows exist. Some these alternate flows are already discovered, but the structure of the business process flow only really emerged when the commands were added. It was however not possible to move beyond commands, due to time constraints.
Having a group of eight people was a bit awkward at first. Only once I had them split into two groups, they really started discussions. However, this also made it somewhat harder for me to guide the modeling process. I tried to help the groups when they got stuck at a certain point.
You really never have enough modeling space. The first space quickly ran out. I had to add two other pieces of paper (one for each group and a part where I parked a part of the process that was less relevant to the new application).
In general people were enthusiastic about the experience. We really had the feeling that the team learned a lot about the business process. Although it took three hours, we really did cover the main process from beginning to end. Some people found it a bit unstructured, although in my opinion that makes the whole process more creative.
Experiences after the first workshop
I found that it is hard for people to throw away their efforts, so I just let them take their paper with the sticky notes. But when we did a small part of the model again (for more detail) I persuaded them not to take the old one. Then it becomes clear that you can replicate the work very easily, but also that model differs somewhat from the older version, due to new insights. In the end, it doesn’t matter much whether people take the models with them. The paper rolls are very unwieldy and are just lying in a corner.
When we did that part of the model again, we had the goal to produce some user stories. Although we took 2.5 hours, we had about 10 ready user stories, 7 other stories to be refined later and some optimizations we might want to make later. And we were confident we had covered all that was needed. All this from scratch, it was the first time we refined this subject.
Conclusions
Event Storming is a very useful technique to quickly cover a lot of ground. It makes refinement discussions a lot more focused. Instead of sitting around a table, you model the business process flow. Although the first two sessions took pretty long, they also delivered a lot. I have to see more of it, but I think that it is a huge time saver in the refinement process.
I loved that the intuition of why you perform this exercise became clear for everybody, just like it did for me at the training.
