Invite the right people
People are the primary ingredient for a successful party. You’ll need good music and drinks too, but if the girls won’t show up, the party will be lame
You’ve been reached by some buzz around EventStorming, you may even have experienced it in some evening event t the local user group. Now you fell like trying the experiment in your own company. But then a question pops up.
Who should be invited?
Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.
When exploring complex business domains (the scope of EventStorming is usually the whole business flow) this implies that a lot of people should be involved, and triggers a lot of warnings. Let's see some.
- They won't be available at the same time.
- The meeting will turn into a waste of time, at least for many of them.
- You'll end up nowhere due to conflicts that may arise.
All these worries are legitimate. But they lead us to do things in a way that doesn't work. The meaningful conversation with the Domain Expert that is at the core of Domain-Driven Design is often not that meaningful.
Should I look for specific roles?
I am somewhat reluctant to map those people to company roles for a couple of reasons: personal attitudes are more important than roles for the workshop to deliver, moreover I’ve seen so many different, somewhat dysfunctional company structures that tying myself to randomly assigned roles is not a wise choice.
So I won’t provide any answer like ‘every developer should attend the workshop’ or ‘only team leaders, business analysts and domain expert should be there’. Instead I’ll suggest to take a different path.
A somewhat zen answer
The best answer that comes to my mind is something that may disappoint you: “Just close your eyes and imagine the perfect meeting, where curious people with the right questions get answered by people who know the answers, or are honest enough to say that the answer is yet to be found”. Now name the people you saw, and invite them.
It’s no different from what you would do for organising a party. The party won’t be perfect if the right people won’t show up. Now, do you invite friends to the party according to their roles or attitudes?
A more cynical answer
If this sounds too mystical, or you feel that the key people won’t show up, you may run the opposite approach: “In a year from now, after the project has been a complete failure, burning a couple of million euros, your company will run a post-mortem meeting. Who do you think is going to be there?” And if they don’t look like interested in your unconventional type of meeting you might present the bargain: join the meeting now instead of the post-mortem, you might save some cash this way.
Conflicts are fine
The most common objection, albeit often implicit, is that if we bring all of those people together we won’t be able to handle the conflicts. This is very likely to happen in a traditional meeting, but remember: this is an EventStorming workshop: no tables, no boredom and an unlimited modelling surface on the wall.
The fact is conflict is there, and probably will be there tomorrow too, and it will probably be one of the most dangerous risk factors in your project, so why waiting?
In GOOS book, Freeman and Pryce introduce the notion of Walking Skeleton like the minimal piece of code that touches all the possible architectural pain point, as soon as possible, because you don’t want discover critical spots too late in the project.
I think this approach is really effective, and I also believe that most of the risk in large scale enterprise projects resides in people, so I'll try to reuse the idea and try to get in touch as soon as possible with the key people that could be the biggest source of risk in my project.
Managing conflicts
In EventStorming we’ll have many people discussing around a model they’ll be building collaboratively. For most of the time they’ll care about the area they’ll know more, and the workshop will achieve interesting speed allowing them to work in parallel (we have an unlimited modelling surface, space to walk, plenty of stickies and working markers, remember?).
You may discover something interesting in the way people group and act in front of the modelling surfaces. Some people will take explicit ownership of given portions of the modelling space (which later you may want to label as subdomains), others would be more reluctant, or dubious, maybe they’re not the real domain experts. Some would try to impose their own view over the system, others would try not to contradict their boss. Help them, provide enough markers and stickies to allow them to publish their view too and to let diverging perspectives emerge.
A place for hotspots
One of the things I love about EventStorming is that it provides a safe place for finger pointing. Given we’re building a modelling artefact, we actually can finger pointing at the stickies. When somebody says “it’s not exactly like that”, that’s the moment to listen to a story: “can you explain us why?”
The interesting thing is that, the physical model makes it easy to trigger the conflict - because you see what’s wrong - but also helps in keeping the conflict at the model level, without turning into a personal issue. As I said, there’s a lot of value in discovering modelling issues and underlying conflicts, the earlier the better.
Solving some conflicts…
Many conflicts may in fact be solved using one of Domain-Driven Design secret weapons: Bounded Contexts. To put it in practice during the workshop, you just need to accept the fact that two diverging opinions by two domain experts may be both right …in their own place. In fact Bounded Contexts are like separate room with their own private model which is perfectly fit to the needs of their corresponding domain expert.
To put it in another way: you won’t solve conflicts by reaching an agreement, or - even worse - a trade-off. You can solve some conflicts just by assuming that the two views are equally valid, and that it would be your job, as a software architect, to find the best way for them to co-exist.
… and get along with some others
Bounded Contexts are great. But they’re not magic. Some conflicts would be resolved by deeper exploration, and that would need time. Time that you probably won’t have during the workshop. Some others, would never be solved (the I-hate-you-damn-bastard-and-I-always-will category, for example).
The best thing to do here is to mark the hotspot - possibly with a vivid coloured signal - advising that this is danger zone, and move on to the best area. This is already really valuable, and nobody is asking us miracles. Endless debating over a single issue might turn the workshop into a boring meeting, so keep the discussion short if there’s no easy way out. Other participants will appreciate it.
In general I am not trying to solve issues or to take decisions during an EventStorming session. My primary concern is to keep the workshop flow going, to have everybody engaged in what we’re building together.
What if we won’t have all the people?
Given a lot of the value resides in observing the interactions between participants, for every key person missing you’ll be losing the value of the interactions between him/her and everybody else. You can do your math, it’s not headcount, it’s counting relationships.
Beware of those folks who promise they’ll join you later. Especially if they are Italians. They’ll miss all the key information: one can not understand a movie from the ending titles, and being there is the most successful ingredient.
Just getting there
However, one might have to acknowledge what’s the real starting point (and I have an easy one: people invite me to run EventStorming sessions in their companies) and get along with that. Every organisation is different.
Sometimes getting the right people on board might be a long process. One may actually get there step by step, so even if I personally prefer to fight for my right to party there might be situation where a temporary trade-off is necessary. Here are some basic tips to get you started.
- Declare experiments: be honest, this might be the first time you run an EventStorming workshop, and even if you attended one, being on the facilitator side might be totally a different job.
- Manage risk: what is the worst thing that can happen during a meeting? It’s probably wasting time… oh, you’ve never wasted time in your company (sarcasm).
- Timebox: every open ended meeting might bloat. Keep it under control key people won’t be available for the whole day. Keep a visible agenda, or a timer. Just try to use participants’ time in the most effective way.
- Look at people’s faces: bored people tend to look bored. Just ask them why they’re not finding interest. And take some corrective action.
- It’s not a trap: some people will look like they shouldn’t really be there. Let them go if they don’t feel like. I normally try to take mobile phones and the like away to have full attention, at least for a limited amount of time, but some roles have different degrees of machine slavery.
- Take breaks: engagement is good, but drains you energies a lot. You don’t want to be in low fuel status. Take a break, maybe every 45 minutes, and enjoy it.
- Retrospect: whatever the outcome is, just find some time to highlight achievements and problems of the meeting, to be sure next one will be even better.
In some organisations, key stakeholders won’t be available at the same time, or won’t free their time for just another meeting. It’s fine. You haven’t achieved anything yet.
Let your first EventStorming build some reputation in order to be attractive for key domain experts, in the next session.
