Event Storming: my rookie mistakes

This week, I was happy to be asked by the teams to organize a second Event Storming session after our first successful experience last week (details posted in my previous post here)

Motivated but still a rookie in that field, I asked my mate Radwane (radwane_h) to help me to co-animate this new session. Indeed, we planned to experience more advanced event storming concepts like Commands, Actors, Aggregates etc. and I was happy to leverage on his Event Storming experience for such journey.

This session didn't went as I expected and I thought it could be helpful -for any new Event Storming organizer- to share here few lessons learned.

"Where is our wall?!?"

It started with a first difficulty: the audience was not prepared at all to face another empty wall... Indeed, since we don't have any war-room for the project (but the ability to use nice meeting rooms here and there), I had to trash the previous tablecloth after our first session. This seemed logical to me. After all, and as I repeated many times to the audience the week before: "Event storming is not about producing a new model/deliverable. It's mostly a live brainstorming to efficiently distill business flow among various actors, to identify key concepts & get rid of ambiguities." (all of this being useful to impact our code & other official artifacts in a second step).

Yeah, this sound logical to me. Indeed, most of the posts on Event Storming you can find on the internet advocate for restarting from scratch every time. It allows you to master the flow, but also to let the door open for better approaches (the first "solution" being not always the best option). This may require more effort during the first round(s), but this is a way to prepare our mental models to save time later.

As a consequence I intended this friday to make us zoom on a central part we identified the week before, involving 2 bounded contexts and few ambiguities in between (at least in my mind ;-). But facing the hostility of some of the actors (harms crossed, frowned eyebrows): I didn't succeed to motivate them to rework on the same topic without our previous wall with stickies on it as a support. One said to me: "If we don't start with the previous wall. We are loosing our time here!". Of course I had the pictures of the previous wall on my phone, but I was afraid to turn it into a lonely exercise if I had to transcript them to the wall (with potential disengagement of the audience).

Even now, I'm deeply convinced that it would have take us less than 10 or 15 minutes to put back all the stickies for this subpart of our business flow and I still blame myself for not having convinced all of them to do it.

But the audience was not ready for such reboot. 

It was like if I made them loosing their precious time (I think our Event Storming session came after few days of other different workshops without precise goals or obvious results; thus the impatience and the fidgets).

Anyway. Facing the astonishment of 12 people in front of me (and an empty wall ;-), I finally asked them which topic they wanted to choose for the hour and a half to come. After few seconds of awkward silence and minutes of collective hesitation... we picked a topic that we didn't studied at all during the first round. Something that I will refer here as the "Onboarding" (I can't say more here for non-disclosure reasons). That was interesting, but as we event stormed I detected an overall disengagement from the audience (around 12 people). Excepting 2 very active contributors, the rest of the audience was stood up too far from the wall with stickies, behind a table that can't be moved. They were trying to contribute to the debate but were somehow helpless and disengaged more and more.

I realized -too late- that we picked a topic with almost no domain expert for it in the room... Sad Panda.

In those conditions, the benevolent help of my friend Radwane was a kind of waste (I was sorry for him). He helped me and the audience, but that was still an Event Storming without domain experts in the room... (for this topic I mean).

The only positive outcome here was that we all realized we knew almost nothing about this "Onboarding" process (important pre-requisite for the rest of the project). We also identified some domain experts to be interviewed on the business-side, and found other stakeholders related to this process that we put on yellow stickies (handful for the months to come).

half of our wall: we discovered few things anyway

Nonetheless, I was truly disappointed having detected annoyance from some domain experts. I felt that I've lost an opportunity to make us work on the core topic for the weeks to come.

I would wrap this debriefing by few observations I've made to myself last friday:

1. Even if I'm not able to get back with the gigantic tablecloth of the previous session, I'll bring some prints of the pictures I took on my phone. This will allow us to quickly and collectively reboot our session even with people reluctant to redo the whole thing from scratch (it's sometimes hard to think out of the 'efficiency' box)
   
2. Before starting to Event Storm with 12 people, I think I'll check first if we have at least one domain expert in the room for this topic... ;-)

Hope this help.

Event storming: Domain distillation under steroids

Last friday, I organized an event storming session at work (one of the major investment bank in France). It was my first time as an organizer and I must admit that I've been truly impressed by the efficiency of this way to distill a domain.

Created by Alberto BRANDOLINI, Event storming is a fast way to explore a business domain or problem with many people in the room -including non-IT stakeholders. In a nutshell: you put every domain experts in the same room with few ITs and you make them describing what happen or must happen in their Business. To do so, you make everyone naming and positioning domain events (stickies here) on a large time-line-oriented-paper on the wall.

"What do you mean by 'Domain Event'?" is probably the first question you'll face as an event storming organizer. To quote Mathias VERRAES (another DDD expert and event storming practitioner), a domain event is

"Something that has happened in the past that is of interest to the business"

We are NOT talking about IT details here, like applications, databases or any button click... (unless its part of your core domain like for Google or other ad-resellers). That's why I stated at the very beginning of our session: "Let's forbid us to speak IT or technical things for the couple of hours to come. Business only!".

"It's developer's understanding, not your knowledge that becomes software!"

"What will be the outcome of our session?" is another legitimate question from the audience when it's the first time. In our case, the objectives were:

1.  To share a common understanding of core business concepts and what to do within our project.
   
   The project I'm talking about is an ambitious greenfield IS reconstruction for an entire business line. The fact that we have to deal with all functions -front to back- is a real challenge. Indeed, there are many bounded contexts and teams involved in our case. Everyone coming from various functional and technical backgrounds. As a Domain-Driven-Design (DDD) practitioner, I was recently worried by the fact that we were talking a lot about technical data formats (mediums/vehicules) or ambiguous concepts during workshops, and less about the core business concepts in stake. Fortunately we have lots of expertise here, tons of talented BAs & IT specialists. But to quote Alberto when he faces recalcitrant domain experts: "It's developer's understanding, not your knowledge that becomes software". In other words: it was time for non-domain-experts like me of few other developers to catch-up with the others.
   
   
2. To Fight vagueness and to clarify various ambiguous concepts faced during our previous workshops. The outcome here would be to initiate a 'lexicon' for our project, taking care about the scope of the definitions (by indicating the bounded context to which a definition applies for instance).
   
   For non DDD practitioners: a Bounded Context is a context within which a model applies (e.g.: marketing, negotiation, settlement, etc.).  Although it is important for a model & language to be consistent within a given context, we can perfectly have the same word indicating completely different concepts - or most likely - different perspectives on the same core concept depending on the context or usage we are talking about. Working without those contexts in mind could be really misleading. Moreover, sharing the language of our business (a per bounded context exercise) is also the starting point to have what we call in DDD an Ubiquitous Language (i.e.: to always rely on the language of the business -including within our code). As benefits, we avoid misunderstanding and "translation" issues, but we are also able to have efficient discussions with the business all along.

By the way, I forgot to tell you that there were no people from the business within our event storming. We were 11 people in the room including tons of domain experts in various contexts; profiles such as Business Analysts (mainly), domain-expert-IT-managers, and some developers/tech leads & a use-case-driven architect ;-)

Modus operandi

First thing's first: the preparation. Discovered in 2013 during a DDD meetup in Paris with Mathias VERRAS, I've since read and watch lot of things about event storming. Nonetheless, the fact that I was quite noob in this field made me asked tons of questions before our real session at work. And I'd like here to thank my friend Tomasz JASKULA (co-organizer of the Paris DDD meetup) but also Mathias, Alberto and Emilien PECOUL for their time and availability when I asked questions on Twitter few hours before my session.

Our event storming was schedule between 2PM and 4PM this Friday. In term of logistic I finally decided to go to the mall aside at lunch, in order to buy a roll of garden tablecloth to make what Alberto calls the "unlimited modeling space" on the wall.

Yes, Roberto warn me few hours before on Twitter: "make sure that location, stickies availability and space aren't constraining the discussion." So I also came with a bag full of working markers and tons of stickies.

source: Event Storming recipes (A.BRANDOLINI)

Before pinning my tablecloth on the wall, I moved out all the chairs in a dead-end corner of the room so that:

• people remain active during the workshop
  
  and
• to be able to observe the body language of all the attendees (much more complicated when they are seated as stated by Alberto).

Indeed. Like when we are playing poker (I confess ;-), it's very important to observe low signals, body languages and tells that betray possible disagreements among people (whether it's due to introversion or political agendas). As said earlier on the phone by Tomasz, "one of the objective of event storming is to identify possible disagreements on how we understand our domain". Either to settle them on the fly, or to park them for after (during another session for instance).

Once the room ready, people started to join me. It took me less than 8 minutes to explain the rules and the objective of this event storming to the eleven attendees before we put our first stickies on the wall.

There are many kind of stickies and possible approaches for an event storming (I let you read the "Event stormers" google plus group or Alberto and Mathias' blogs for further information). But this friday, we focused on "Domain Events" only (not the Commands, the Aggregates or the Actors). Thus, we almost only use "orange" stickies with past-tense sentence on it (e.g.: "Price Requested", "Order Executed", etc.).

source: Event Storming recipes (A.BRANDOLINI)

After one hour and a half, we wrapped up our session by identifying all the core concept of our domains (reading what we wrote on our stickies to do so), and started to collectively gave definitions for few of them on the left side of the tablecloth.

Takeaways from this first experience

• Used to Reactive Programming or CQRS architectures since various years from now I am pretty comfortable with the notion of event ;-) But I was pretty impressed that everybody followed the "Use past-tense sentence" rule (on Domain Events stickies). It sounded really a natural way for everybody to tell our business story.
• It seemed important to clarify from the beginning that we weren't here to produce another new official model/artifact for the project but to interact instead. Indeed, we were here to be on the same page and to collectively explore ambiguous part of our Domain. I had the feeling that it helped some of us to relax and not to fall into model perfectionism.
• It was hard for some of the attendees to avoid talking about IT things, applications, existing systems (even from Business Analysts). Nonetheless, we collectively succeeded to stick to our initial objective ("Business only!")
• Disagreements about some core concepts (e.g.: trade done vs. order executed) were quickly resolved with the support of all participants in the room able to add views and precisions (including naive questions from the non-experts). Visually also, with the support of other related Domain Events all around.
• It's been hard for some of us to realize that things that are currently done by existing IT systems correspond to real (Business) Domain Events (e.g.: the trading portfolio routing/attribution)
• Some people (4/11) started to take back some chairs and to sit. I hesitated to ask them to stand up like the others but after few minutes of observation, I realized that they were still actively contributing, answering to questions from the others. At the end of the day, I had the feeling that they needed somehow this background position to be able to see the big picture on the wall.
• We had few sub-groups during the session (distilling a subpart of the wall in parallel during few minutes here and there), but almost everyone actively followed the overall business story. Before the session, I feared some kind of post-it contention on the wall with 11 people (and disengagement as consequence) but nothing like that happened. Event Storming is really a fluent way of working together. It's amazing the efficient bandwidth we had to discuss and get in-sync with multiple people.
  
  
• As stated by Emilien PECOUL on Twitter, it is important to let people do their things and to not constrain them too much: "Let paralell discussion emerged". Nonetheless, I found interesting to make few "attention call to everyone" when we had to decide an important point or to answer a key question.
• To quote Alberto BRANDOLINI: "it is KEY that location, stickies availability and space aren't constraining the discussion". After this first Event Storming session at work, I can't agree more. The space or lack of space is really impacting the discussion. BTW during the session, I had to pin another piece of paper on the right while everyone was busy on my left, dangerously close to the end of the tablecloth ;-)
• Fortunately, I'd read Mathias' "Facilitating Event Storming" blog post before organizing this session: "Know when to step back. Don’t do the modelling, guide the modelling. Ask questions". It allowed me not to intervene too much in the modelling as the organizer of this Event Storming session. In a nutshell, I just tried to ask questions, to rephrase or to identify blur zones or implicits concepts.
• As for any other workshop, it was crucial to ensure a benevolent atmosphere so that everyone feels comfortable and willing to contribute in public. We joked here and there during this 2 hours sessions, but it was really a positive co-construction mindset.
• I waited almost one hour before suggesting the group to trace bounded contexts on the wall (between the stickies). In my opinion: if done too early, there is a risk to constrain the space and thus, the discussion.

To conclude on this first Event Storming experience at work, I would say that I've been truly impressed by the efficiency of this dispositive.

I would recommend it for any business domain exploration

For this first experience at work we focused only on the Domain Events (i.e. the "Orange" stickies). It probably eased the ramp-up for everyone in the room. But I'm very keen now to retry an Event Storming with the other tools such as querying the Domain Events causality (i.e. identifying Commands, People or External Systems), but also by identifying clearly the Aggregates involved (Stickies with other colors).

But as I said on Twitter just after this session:

Stickies are just a pretext for high bandwidth discussions & ultra efficient domain distillation.

And for that, Event Storming is an awesome tool.