We believe we are one of the very, very, very few companies actually applying this technique in Vietnam. At Silentium Vietnam, we rely on the technique daily; it's not because it is cool (it is actually cool); it is because the technique ticks many items in our checklists.

Once we give it a try, we right off see the value it brings across the board. The first time, we see our engineer so into a workshop (partly because they are benefiting from that without reading tons of documents)

This is the story about how do we get into Eventstorming and stormed it out.

Pre-intro

I myself interview a lot of people carrying a lot of different responsibilities in Product Development. One of the questions I always ask those, "How do you know that you are doing a wrong thing?". And, the reason why I ask the question is rather selfish; I want to learn from their thinking process; By chance, I may acquire a trick or two.

Along the line, I start to ask myself, well, how do you know that you are doing something wrong?

You may have heard about the "Regression test"; that's like when you are plugging an electronic device at home, and popped! a light bulb in the toilet burned due to over-voltage, who can think of that, right? And it is not even something special; it happens all the time in the software development world. The whole Fastly CDN (serving traffic for Twitch, Reddit, and Pinterest) is roughly down for an hour due to a valid configuration from the customer, to tell you how devastating a regression can be.

You may think, well boys, they should be aware of this when implementing the feature, then think about this. People come and go, the team comes and go, the system is not as documented, complexity between systems, etc. The regression about to happen can be in charge of someone in India, while the one who is making change is somewhere in a corner in Singapore.

Such a rant! Regression is one of those things; think further and asking yourself. "Well, can a <name> prevent this from happening?". Fill in whatever title you like; the answer is always going to be "it depends because it is complicated."

Tackle the hard thing

Let's have a deep look into the problem we are talking about and zoom out; we'll see

• Time dependency processes

• Direct user (who's gonna use the system), an indirect user (who'll rely on the direct user to operate)

• Interprocess dependencies where each component cares of a different facet of the same data (think of the report, billing, invoices)

• Multi-users, multi-stakeholders processes (think of approval process)

There are actually quite a few attempts on the topic; we have UML (I barely remember a few of those notations), BPMN (Business Process Model and Notation), which is super rich notations - are all tried to bring people together (as in, business people, product people, engineers, and designers) but, I guess, those attempts were way too much of engineering. The languages and representations are not natural to non-engineers; hence, Eventstorming, the next attempt.

Introduction to Eventstorming

EventStorming is a flexible workshop format for collaborative exploration of complex business domains. It comes in different flavors that can be used in different scenarios: to assess the health of an existing line of business and to discover the most effective areas for improvements; to explore the viability of a new startup business model; to envision new services that maximize positive outcomes to every party involved; to design clean and maintainable Event-Driven software to support evolving businesses rapidly. The adaptive nature of EventStorming allows sophisticated cross-discipline conversation between stakeholders with different backgrounds, delivering a new type of collaboration beyond silo and specialization boundaries.

The definition we copied from the homepage of Eventstorming

That said, there are few straight benefits of Eventstorming

• Flexible, dynamic, everybody should be participated in rather quickly

• Simple, no tricky visual representation

• A lot of collaboration

What may concern you

• Pretty flexible; as such, make sure you align on the understanding before the workshop. A draft run may bring a lot of benefits. Be aware of variations; we are not that different; we'll introduce a slight difference to

• A LOT of stickers; use digital version if you are worried about the environment.

No more talking. Let's get into it

User journey

1. A customer gets into a supermarket

2. The customer selects item and queue up to a counter

3. The cashier at the counter scans all of those selected items

4. The machine displays the total amount

5. The customer pays by cash

6. The cashier receives cash

7. The cashier finishes the transaction and issues the receipt

8. The customer collects all of the items and walks out of the supermarket

Step 1 - List out events

Firstly, we'll use an Orange sticker to represent an events

Here we care mostly about events that may be interested from a system point of view. Things that we want to see somewhere else, things that we use to measure performance, etc. Non-interesting events may be left out to reduce the noises

We do this as a team, try to discover as many events as possible. The concept of the event may not be familiar to everyone, don't worry about that. Just describe the "thing" that we care about in a certain stage, the rewording to past tense. Once we are done, group them and eliminate duplications

We tried to align the timing from left to right; happy cases on top and edge cases are listed vertically. Don't worry about an exhausting list; we can always add one whenever we find one.

Step 2 - Understand the cause.

At this stage, we'll use a Cyan-like color sticker to represent a Command. The main purpose of this is for you to go through the list of events while trying to figure out the timing to understand what caused the event to happen.

We split the group into teams, with each team's focus on a specific timeline. Questions are free to raise, and we dedicate a person or two to answer ad-hoc questions

You'll see right off, not all the events are treated the same. Some events are caused by a command triggered by the end-user, while some others happen to depend on other events

Step 3 - Where and who kickstart those commands

We use a Green sticker to annotate a "Screen," where the user will find the corresponding command. If we have more than one place where people can access the same command, feel free to stack those green stickers.

Find any "User" icon online to mark the one who triggers the command; in this case, that's a cashier. If many types of users can execute the command, we stack them just as those screens

Step 4 - where can we find those changes?

Once you are happy with those triggers, you may wonder, well, those events have happened, and we noted because we care about those. Then where can we see those changes?

We update the green sticker to be "Screen and Read model," read this as, ok, green is where I can access those changes. Our diagram now may look like this

Step 5 - adding rules

None of the processes is just "that" straightforward. There will always be a certain calculation rule here and there, conditions of certain things to happen. We'll address that by using a Purple sticker. Purple is for "Rule." Thinking rule as an if-else condition or some calculation step

As you can see, we figured that we had missed a few screens and events at the scan stage. We did add them here while working on the rules

Step 6 - sub-processes

At the final stage of payment, we see many events that happened but really out of context of the journey. Things like sale reports, inventory updates, statistics, etc., while we can also represent as we have done; In reality, normally those processes are much more complicated than this, to reserve the complexity, we'll simply leave the detail to the Eventstorming of that actual component rather than incorporate that into the journey by using Yellow sticker - "Subprocess."

Now we don't have to worry about events that may process generating, read models of those so on and so forth. We can always use an arrow to link the process to the area where it actually happens.

Step 7 - and beyond that

There are few annotations we don't really cover in this post like

• External - which you'll use to describe communicate with an external system and observing certain events, normally annotated with a Pink sticker

• Question - collaborative question where detail is yet clear to finalize the detail, normally annotated with Red diagonal sticker

Step 8 - where to go from here

Eventstorming actually opens up a lot of opportunities

• From the output, you can review other journeys to see they are all covered

• You can start finalizing User Flow

• You can build a Regression plan to cover some parts caused by odd event chains.

• You can build User Stories and utilize "Rule" to focus on Acceptant criteria of an important area.

The MOST important part of Eventstorming, to us, is

The actual process of shifting stickers and how we work together to clarify system design and business processes. We use this to speed up the Product Development process and have a better understanding of the complexity of the works; We do hope this helps you too.