Our team has been beginning a new project, but it's still very early. We're 'discovering' the requirements and considering very high-level milestones.
While the domain isn't wholly new to the team, it still has a few new aspects for us—otherwise, why would it need building?
As part of the discovery, our Tech Lead mentioned the concept of 'event storming' that he's previously been involved in. Another team member has read about it, and the rest of the team has heard of it. There have also been rumblings about us utilising domain-driven design this time—we've loosely done this in the past, just not 'properly'.
So, we gave event storming a go for the first time - and I offered to facilitate.
The premise
Reflections on the session
A deeper dive into the session
Resources and references
The first two sections here will be much lighter and more TL;DR than the last section—it’s just for those who want a deeper insight into the session and want to try to take some direct learnings from it to feed into their next Event Storming meeting.
'EventStorming is a workshop format for quickly exploring complex business domains.' [1]
It's a 'simple' workshop for breaking down a domain into more focused chunks that can be a great reference later, aiding in domain-driven design.
Generally, especially for your first-ever session facilitating, you run them in person and involve as many relevant people as possible - technical and non-technical. You are trying to extract a model of the domain from the collective group's heads.
You make the room you're stuck in as collaborative as possible by explaining the concept, slapping a humongous amount of sticky notes onto the centre table, and shouting go - there are not many rules except the order in which you run the session.
During the session(s), the main things you want the group to model are:
Domain events
Things (events) that happen within the domain - An often-used example is to think of a historical event.
Event triggers (commands and origins)
What causes an event to happen? Commands are from users; origins are external triggers such as time or other systems.
Aggregates
I still struggle with these - but they’re supposed to be related clusters of events and their triggers that can be treated as a singular unit.
If you have the time, care, and energy, you can then further extend the modelling to look at the following:
Subdomains
Smaller domains within the one you are modelling. Similar to aggregates, but mini-domains that exist within the larger domain you are modelling and have tighter focus.
Bounded contexts
Areas that have a defined language in which they can be discussed. Often mapped 1:1 to subdomains, but can also be across multiple. Some recommended watching.
User personas
Detailing your different users' roles, needs, and ways they want to use the systems in the domain.
Numerous things could have gone better in the session and probably dealt with as part of my planning.
Overall, I think the session was productive - maybe bordering successful. We had some failings, but the team learned a lot. We enhanced our knowledge of our domain, particularly the area we wanted to understand further. In my opinion, we also got a decent amount of output for events and triggers, which are the most valuable parts of event storming.
I would happily do more event storming sessions in the future. I can see how valuable they can be in mapping out a domain, especially when moving to a new one as a team.
At the start of the session (or maybe even before, over Slack), I failed to make it clear that we needed to start fresh and try to remove all preconceived notions before event storming. If some people go in with preconceived ideas, it’ll be like having everybody else drink from a poisoned chalice. It influences and removes some of the divergent thinking that happens, and thus, it can ultimately devalue the session.
It’s hard for everyone not to go into the session with these thoughts, as there will always be things ‘decided’ and systems already in place that will influence them. It’s particularly tricky for engineers and product people, as you’re likely doing this while still in a ‘discovery’ phase for the new things being built.
Bringing in the other teams and relevant people may have been worthwhile, but then you're fighting against Brooke's law. This 'rule' of involving everybody relevant is probably better when running in-person sessions rather than remotely, as remote sessions tend only to allow one line of communication to be active at a time. I think we made the right choice here, but only due to the restriction of needing to run the session remotely.
The session would have run smoother and probably had better outputs if I had spent more time defining and providing examples of events, triggers, and aggregates—especially aggregates (due to our failures to agree on anything!).
Reading about others' experiences and having a ‘dry’ session with somebody may have helped. Members from Product and Tech seemed to have slightly different internal definitions and cognitions, so the first five minutes could have been spent better aligning these definitions and examples.
Triggers were tricky, too, as many triggers often had events baked into them. I’m unsure of the resolution, as events are part of the trigger. You can’t just say ‘user pressed button’ because otherwise, you would only have a few triggers. Maybe this was a misunderstanding, however, and more reading would help here.
One of the problems with the format I chose was that we originally didn’t connect triggers and events together when trying to create triggers. Thankfully, it was pointed out early, so we folded the events into the trigger creation—however, it still could have been improved. Rather than just thinking of triggers and linking them to events, we should have looked through each event individually and tried to discover its triggers.
If the session format had been better (as explained above), aggregates would have also gone better. The session was muddied by confusing triggers that contained events, and I think this started to disrupt the team's thinking. We would have been better served spending time scrutinising the triggers and events created instead of trying to discover aggregates.
Lastly, make sure everybody is aligned on the meeting's purpose. Event storming can have a few different purposes, and I think it is useful, so make sure you all know why you’re there!
Based on my reflections, I think I would do a few things differently if I were to run a brand new event storming session.
Before anything, I would ensure I’ve researched DDD (domain-driven design) more. Event Storming’s roots are in DDD; thus, having a decent understanding of it is worthwhile. I went into the session quite blind to DDD, thinking it couldn’t be that hard. It isn’t, but it has a lot of concepts that leak into the session.
The most important change would be the spread of focus. We should tighten the domain we focus on by picking a particular subset. Our session was too ‘Big Picture’[3] for our first session, and we didn’t have the right people for the big picture. The people in the room and what we wanted from the session would have been much more efficient if we reduced the scope to and tried ‘Process Modelling’[3] or just tightened the focus from ‘Trade orders’ to something like ‘defining trade orders’. Perhaps, if we don’t know where to focus, we should run a short session describing and decomposing the larger domain and then picking the sub-domain to run event storming on.
If I could, I would try to run it in person - especially if it’s most people’s first-ever event storming session. It’s a bit like the whole hybrid working setup - some things work better in person. Anything encouraging divergent thinking works better as a group of people in a room around a whiteboard (covered in sticky notes).
Before facilitating the event storming, I did some reading on the subject and formats for the session, first looking at the original blog post[1] and then reading the (small) chapter in the 'Building Microservices' book[2]. I also scanned a few other posts found online.
The session needed to be run remotely because two team members worked from different countries. Most sources suggest having everybody relevant that you can present; we couldn't do that, so we utilised our collaborative tooling - Miro and Zoom. There were only six of us, so it was a small session, but online collaboration was also more manageable thanks to the limited number.
Armed with my limited research, I set up a Miro board with some descriptions lifted from the resources, some relevant examples of each type, and a format looking like this:
With this board, we got started. On the top right is the agenda/timeline I was planning to run the session to across the hour:
5-10 minutes introducing the concept and plan
A storming loop consisting of:
10 minutes individually storming
5 minutes regrouping
We followed the storming loop for events, triggers (commands and origins), and aggregates - with varying degrees of success.
Events were relatively straightforward. We had a high output of events. I think this is due to the scope of our analysis (broad!). However, I noticed people had different views of an event—confusing it with a human trigger (command). There were discussions throughout the session about what an event is. I tried to offer the analogy of 'Something that has happened or will happen, like a historical event', which helped us align more as a group.
Next up were commands and origins. Commands are human triggers, and origins are external triggers. I explained that these were triggers for events— so a trigger produces an event.
We tried generating triggers without reference to events, so we just considered things the user may do or what other systems may do. This wasn't a great choice by me. We discussed and decided to spend more (restricted) time linking triggers to events, putting all events for a trigger underneath it and duplicating events that multiple triggers could produce. It was worthwhile spending the time doing this - I purposefully left some spare time across the agenda for an unplanned scenario like this.
Another problem was that many commands had events baked into them—the reverse of the problem experienced in the events stage!
We then went on to aggregates, which didn’t go very well. Even with my example and definition to steer the group, we had differing views on what an aggregate was. Aggregates failed because of my lack of understanding as the facilitator of what an aggregate should be and my inability to lead the team with my understanding.
The session ended on a low as we spent the remaining time disagreeing on aggregates; we didn't produce any.
There was some time remaining, so we reflected briefly on the session and agreed to have a second one to ensure all commands had events and all events had commands and to attempt tackling aggregates again.
[1] http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html
[3] https://blog.avanscoperta.it/2020/03/26/remote-eventstorming/
https://www.eventstorming.com/
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.