The first rule of Event Storming, is that you can't just talk about Event Storming (@ziobrando;@citerus_se)


Event Storming is something that needs to be experienced. That said, I'll do my very best to describe my experiences in words, hopefully illustrating its benefit when working in situations that reminds of Business Process Modelling or requirements/business analysis.

Last week, I had the pleasure of joining a one day Event Storming Workshop with the ES father Alberto Brandolini as he was visiting Stockholm. Alberto described ES as a "brain dump" of his - something he had formulated over the years and originally intended as an introduction to Domain Driven Design, but then took a life of its own.

In this particular workshop, the average attendee had little to no experience with Event Storming, other than hearing about it from other conference speakers or seeing its name in a flyby tweet.

Brandolini started us off by placing us in front of a huge whiteboard (about three average whiteboards in length), making an abundance of marker pens and sticky notes available, asking us to do our best to describe the business events that are executed in a typical teaching company (such as the teaching branch of Citerus). He instructed us to mark the direction of time on the board and then get started. We, in turn, started to ask him about the name of this fictional company and to discuss the first events, whereupon he exclaimed something akin to: "That's anti-pattern #1 & #2 - don't ask questions and don't form a committee (i.e. try to agree with each other at this point) - just take a note, write an event in past tense and put it on the board" (e.g. Ticket Sold or Course Attendee Arrived (to the workshop)).

With that little jolt, all of us engaged in creating events and placing them on the board.

Why were we doing this? How was this exercise useful? To collectively learn about the business!
It's not your business knowledge that gets turned into software, it's the developer's ignorance.
 - Alberto to a Domain Expert once upon a time
Also, he pointed out, that by collaborating and putting our own piece of truth on the board, we can focus on important parts of business, rather than finding ourselves getting caught on minute details, such as discussing specific logging strategies.

It's OK to be wrong! Communicate to the Domain Experts early, that they don't have to know everything - it's better to say "I really have no idea", than to make something up on the fly.

Alberto - acting as the facilitator - used a block of different colored stickies to mark hot spots on the timeline, i.e. where discussions arise, where there's stated trouble, or where definitions part. Any emerging discussions where there are strong feelings (e.g. where they might take a while), should swiftly be postponed with a sticky not to interrupt the flow of storming.

At the end of this exercise, if there are not enough hot spots, Alberto explained, the facilitator can ask for issues, but preferably in a one-to-one session, e.g. over coffee. Remember, though - if you ask for problems, you'll receive problems, so leave this exercise for if you need to identify hot spots.

The same technique is used to talk to participants who ... didn't participate for one reason or another, or who seem obviously upset.

At this point, the first part of the meeting was over. We had successfully detailed our business' (high-level) events in a somewhat chronological order. In a company setting, useful discussions could now take place about what's going on - what should be going on and what should change.


In phase 2, we were asked to look at the timeline backwards, assessing if there was anything missing for an event to take place. Alberto playfully backed this exercise on something he watched on TV once, but that made a lot of sense - You cannot lie in reverse: If  we look at things backwards, often-time we can get a sense when something is missing.

Finally, we marked sub-domains with masking tape, e.g. Marketing sub-domain and opted to separate the happy path (normal operation) from the exception paths:



With that, it was time for a break, and that's something I'll bestow upon you as well ;-). In an upcoming post, I'll talk about the post-exercise review and reflection. Good stuff!

Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints