Monday, May 19, 2014

Some updates about EventStorming

Hi everybody. After a long silence I finally found some time to start writing again some content for this blog. Well, many things happened in the meanwhile in the EventStorming space, and I finally managed to find some time and discipline to start sharing our findings more effectively.

In the meanwhile, EventStorming found its way through word-of-mouth, twitter and conference workshops. But it’s looking like a web version of Fight Club: getting viral and secret at the same time. Maybe it’s time to make some change.

EventStorming Community/Mailing List

I’ve started a new public community on Google+: it’s called EventStormers. Here’s the link. I’ve chosen Google+ mostly for the look: our content is a lot more visual than other discussion groups, and I felt that Google+ was a good tool for that. I know there are some drawbacks too, but it’s working well, so far.

Some colleagues were already sharing content on the smaller private community called EventStorming Practitioners. Communities rules prevent me from turning the old one into a public one. So, members of the private community, which are ok with the idea of going public, will have to share their stuff again. That includes me too.

Writing some stuff

It’s no secret that I am planning to write something more than a blog post. EventStorming and Model Storming are tricky topics (and yes, I am aware that I haven’t published much about Model Storming and that many people are still confused about the two terms).

Telling the what might be relatively straightforward, but telling the why  and exploring the how can take ages. However, I finally acknowledged to focus on EventStorming for now, and I am working on readable content. Portions of it are actually making their own way to the blog.

But that’s the offer. I am writing about things I care and think that are worth sharing. But - as every blogger knows - I also write pushed by the urgency of a freshly learnt lesson. The drawback is that this is too much self-centred.

So I am asking your help.

If you are curious about EventStorming, please join the community and start asking questions, or maybe ask what you would like to know about EventStorming right here in the blog comments. I’ll do my best to share the answers I know, and find the ones I don’t.

Thanks everybody



Thursday, May 15, 2014

Go personal to boost engagement.

Weird episode during today's EventStorming session. We had a meeting room with a big wall available, that we set up with a plotter paper roll. The room had a big table, that could not be moved away so we simply moved it aside, to provide more space in front of the Modelling Surface.

Unfortunately, it wasn't enough. Some participants showed up a little late, so we waited for them. When they came in, they saw other participants sitting (cause we've been waiting) and immediately grabbed their seats. Hrmpf! :-/

Well, I thought: "This isn't going to last much" and said politely: "You won't need your seat. We'll be standing most of the time, working by the paper roll". What I didn't consider was that many of the participants were ladies, and the answer was: "We don't have the right shoes for that!".

Ouch. Surprise. I've never thought about it. :-(

Add that to the fact that I couldn't adopt my usual I'll-kick-you-in-the-butt strategy that works perfectly with developers, (I am a gentleman, after all), and for the first time having people stand up became harder than usual, resulting in lower-than-average engagement and less observable body language, for a while.

Time for a Plan B

The surprise trick that really worked well was "could you please add Actors close to the corresponding event?" and since "actor" meant "me" for many of the participants, they all stood up and added information to the model, raising engagement at the same time. Wow!

Ok, lessons:

  1. As Jef Claes reminded me, remove seats. I focused on the table and forgot the smaller enemies. Seats were still there, inviting and comfortable
  2. Environment matters a lot. And preparing the meeting is really important. I did a survey on the room before the meeting (something which is hard if I travel to lead a workshop), but I focused on surfaces, and space. Maybe is time to set up a room preparation checklist (next post, maybe). As Sun Tzu said: "Every battle is won before it's ever fought"
  3. personal involvement (actor == me) works pretty well as an engagement booster. I normally go to actors together with Command exploration, but in this case (small timeframe available) it was better to go straight to the actors.
  4. shoes... maybe mention 'bring comfortable shoes' in the invitation.

Tuesday, May 06, 2014

EventStorming: invite the right people

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.