Event Storming. Design a Solution to Your Everyday Project Challenges

Why software development is not just about writing a code and how Event Storming might be of help for your future project?

---

We should have known better… This is what comes to my mind whenever I see a huge gap in a system, which has so many walkarounds built around it to make it work, that a developer needs at least 2 MD to go through that jungle and understand the initial purpose of this whole idea.

I worked for a NY start-up providing financial services, and the entire system was built as an MVP that has never really evolved into a mature system. New features were added as some kind of patches that were stuck to the core and were breaking up other functionalities. After every deployment, we held our breaths till the following day.

We should have known better, I was repeating to myself after every critical issue in Production.

I was managing a project in which after every refinement, a Product Owner slightly changed the requirements. The adjustments, however, were small only from his perspective. Implementing them in a new way was time- and money-consuming, as they were impacting the whole existing structure of the system.

We should have known better, I kept thinking when he was surprised that it would take so long and commented “hey, I just forgot to mention it at the beginning.”

6 hard truths you may learn while managing the project

If you’ve ever had a thought like that, let’s go and reveal 6 hard truths that you’d better understand sooner than later.

1. Software development is not writing a code

Management needs to understand that the code is just a final form of the whole analysis, learning, and decision-making processes that developers need to do before writing down the results.

Software development is not knowing.

Think about every presale or discovery, or even a first stage of the project you were in – there are always blind spots listed as “assumptions” right? So it is not about the code, it is all about understanding the environment that we are gonna work in, and problems that need to be solved.

2. Backlog form provides us with the illusion that a project is just a sum of its parts

The typical Backlog is a queue where every User Story has a priority assigned and is waiting to be picked up. We tend to believe that when every story is closed, the project will be somehow accomplished. Wrong! Where is the room for the activities that do not follow the plan, like performing the workshop to check if our software is really solving the problem it’s supposed to do? It’s like in the ER, if you have a dying patient, are you gonna focus on their broken leg, or will you try to save their life?

3. Business flow does not care about the organization limitations

Imagine a typical organization having x number of departments that do not work together but beside each other. You will find there emerged silos like the one always saying “it is not our problem” and the other one claiming “we are great, in fact…we are the best”. In their infrastructure, there are problems described to newcomers as “this is not working but this is how it works” (sic!). They are always hard to solve, hard to discuss, and hard to visualize, so it is easier to do nothing. And here goes the business flow that simply does not care – it is about making money, not dancing around all those blockers, right?

4. Nobody is an expert in every aspect of their professional area

And that’s ok! But have in mind that when you are trying to get the answers, the experts will only know some part of the problem, and what they know and what they think they know are not the same thing. So, the easiest way to get the answers is to talk to more than one expert at once, or you will get caught in a one-dimensional world.

5. Doing something right at a first shot is always better (and cheaper!)

You may disagree with me on that, but this is why I do not buy the modern “agile” approach so much when it comes to the actual work. It is expensive! It is all great at the beginning when we know that we can do everything and change everything. But then you end up having a very unpleasant conversation with your Customer, and you need to tell them that your team needs x more iterations to accomplish the given goal.

6. Forget about consistency

Let’s say, there is a factory producing lamps with branches all over the world, and all departments including supply, warehouses, sales, or finance need to use the same software to secure an end-to-end flow. Think about the word order and how differently every department will understand it. In terms of supply, this is something they need to order (sub-assemblies) so the warehouse can produce a lamp. Then the sales department can place an order for lamps that Customer has ordered. The finance needs the order to confirm the invoice – so the meaning of this word is not consistent throughout the whole company. The system is not consistent as well. The consistency can be only achieved at the model level (in this example that would be a department) and this level can’t be large. The independent models need to work together.

As the truths, or in other words, problems have been already revealed, we can move to the part when some answers and solutions may be provided by Event Storming!

Event Storming in practice. Find a solution

Event Storming is a modelling technique that is performed in the form of a facilitation workshop, and it helps to:

1. see the system as a whole (but not the consistent whole!)
2. find a problem worth solving
3. gather the best immediately available pieces of information
4. start implementing the solution from the best possible starting points.

We all know facilitation workshops (in fact, you can find the definition in the PMBOK Guide), so why is this technique so different from everything that you might think of when you hear about “facilitation workshop”? Imagine a room with no place to sit, you can only stand. In front of you is a very long paper roll that is stuck to the wall (unlimited modeling space). On a small table, you can find sticky notes (most of them are orange), markers, and maybe a standing flip chart with a legend written on it. Nothing else. You can forget about going through your emails when the discussion gets boring, and you start to realize that this meeting may actually differ from the others. People are gathering – technical experts, business people, and everyone else who is involved in the process and might have some insights into how this looks from their perspective (the best mix of stakeholders). The facilitator says: please, put an orange sticky with a domain event written on it on the wall. This needs to be a relevant verb in the past tense like “order placed”. It is important to have this particular form because we need to focus on the most important steps, which are the essence of the business idea (model the business flow). This is what the result will look like:

The stickies in different colors are added to fully understand the whole flow (external systems, like PayU, to pay for the order, commands – why the domain event is happening? Because a user has decided to proceed with the checkout and placed the order, problems – dark pink ones, where we can see that this shipping amount calculated event is one hot mess, etc.).

In 1-2 days, you can see more or less what is there and what needs to be done. Maybe if not urgent, some part of a time-consuming but not that advanced work, can be delegated to a junior team? Or that you can replace some part of the customization with third-party software as this will be cheaper?

The answers are there, on the wall. The people that gathered were able to model together, and they are ready to work now as this preparation has brought them to the same level of understanding! You know what they say: “5 days of coding will save us 15 minutes of analysis” (Tomasz Nurkiewicz, the translation is mine).

Event Storming is the opportunity to learn together. All in all, we are people trying their best to solve the problem worth solving, beyond the problems that every organization has.

This article is just a quick overview of the Event Storming idea, but nobody is better to give you more details than Alberto Brandolini and in Poland – Mariusz Gil. I honestly recommend reading Introducing Event Storming, even if the book is still “under construction” (and you can decide by yourself how much you want to pay for it) because eventually this might be the solution: merge the people and split the software!