Event Storming from a non-technical domain expert perspective

Michał Ostruszka

18 Mar 2024.7 minutes read

Event Storming from a non-technical domain expert perspective webp image

Some time ago we started a Domain Driven Design initiative at SoftwareMill. Our goal here is to spread the knowledge and our experience with DDD together with multiple complementary tools and techniques we use regularly on clients’ projects.

After some quest for a problem and domain that would be suitable for such a showcase we decided to settle on one of the processes our administration department works with on a daily basis - resource/equipment management in our company. It seemed moderately complex (not too easy and not too complex at the same time so that it can be understood by readers) which made it right fit for the problem at hand.

We started with contacting our colleagues from the administration department, giving them a heads up on the plan we had and once they got on board we set up a first session of Event Storming workshop to kick the project off. You can read more about that in Rafał’s post here.

Once we finished our three-session long workshops we asked our domain experts about their feelings and impressions from the sessions, especially valuable as they were new to the Event Storming technique and all practices around that.

Below you can find a Q&A session with Małgosia and Asia, who work in our administration dept at Softwaremill and were so kind to be our domain experts for the purpose of the project

Check all the articles from the series:

What are your feelings regarding the process and goals (both expected and achieved) after your first ever Event Storming session?

It was a really interesting and refreshing experience. Our job at the administration department is usually quite repetitive so here we had a chance to try something new and from outside of our specialization. Although I knew before more or less what to expect, I didn’t think we’d dive so deep into the details of the process we decided to model. I didn’t think that what seemed obvious and trivial to us working in administration could be actually that complex. This session also allowed us to identify gaps and missing bits in our current process.

It was totally a brand new experience to me as it was my first Event Storming session I’ve ever attended. I was sure that the process we chose was so trivial and simple that we’d be done with it in one session. I couldn’t be further from the truth - it turned out that the process was so complex that we needed a few more sessions to go through and explore it.

How much did you know before attending the session? Did you have to prepare for it somehow?

I didn’t know much about Event Storming workshops. I read a few high-level articles online but I didn’t really know what to expect. The only preparation I did for the session was to refresh my domain vocabulary in English as we work in Polish on a daily basis and that’s it.

Our colleagues who initiated and ran the workshops were kind enough to give us some links to articles presenting the basics of “why and how” of Event Storming and that’s it. I didn’t know anything more before the session.

How did you find the session breakdown and overall facilitation? Did you feel comfortable during the session?

I was feeling comfortable during all the sessions due to the safe and professional space we all created together. Any questions could have been asked and were answered, any ideas could have been raised and considered.

The introduction given by Mateusz at the beginning was invaluable as it clearly described what we’re gonna do step by step, what’s next etc. He was navigating and updating our Miro board so the board was always up to date reflecting our current state of knowledge.

Periodic mood tracking was on point, it allowed us to track the attention level and whenever we’re starting to lose focus short break was called to allow us to take some breath and regain our attention.

I have a feeling that all the sessions were well structured and organized. We were fluently moving between successive stages of the workshop and it was all conducted in a way that there were no issues or difficulties in understanding where we were and what we were going to do next. I was a bit worried about the potentially formal flow of the session but it turned out totally unjustified later on, the workshops went smoothly in a friendly atmosphere. Nonetheless the sessions were exhausting requiring a high level of focus and engagement to get maximum results.

One tiny thing I found particularly useful was the habit of periodic checking of the mood of all the attendees during the session. It may look like a tiny detail but it turned out to be really valuable and allowed us to have breaks when they were really needed.

What were the pleasant surprises of the session for you?

For sure one of these was that the sessions were actually very engaging. I was sure this would be yet another boring workshop, all in all it’s about our work - what could be so adventurous there?

Although long, exhausting and quite demanding, the sessions were really engaging and interesting. I was pleasantly surprised that our colleagues from engineering were genuinely interested in the process and really wanted to get to know and understand it fully.

What were the most important take-aways for you from the session?

Even though we thought we knew the process well, we were able to identify some gaps in there that, while never happening before, could easily pop up in real life. It also showed that there were some areas that were not explicitly stated and sometimes we kept relying on tribal knowledge that was not written anywhere.

As a side effect of the workshops it turned out our processes were potentially missing some steps or flows and required thorough review to make it more complete.

What were the drawbacks or negative findings you had regarding the product/business process and session in general?

Nothing I can think of in relation to the workshops themselves. Note to self: get yourself the proper equipment for such online workshops. The last thing you want during such engaging sessions is your laptop and conference call program lagging to the point you cannot follow the board and you’re getting cut off.

Didn’t spot any drawbacks and also didn’t find any negatives during the session.

Did the session change something in a way you now look at the business process discussed?

As already said, I didn’t expect that the process we were working on was so complex and had so many intricate points and quirks.

After analyzing our process, I wish we had at least a bit of automation there as the session showed that the process is more complex than we expected and would potentially greatly benefit from reducing manual work.

How do you see such close cooperation of stakeholders and IT while building software products? Do you see a value in running such sessions?

Such workshops bring tremendous value when building IT systems for any kind of complicated business problems. For people running these processes on a daily basis they may seem easy and trivial as they know them inside out and are used to them, but deeper analysis shows they are more complex to grasp to people from the outside and not very trivial to model.

I believe that if such sessions are done right they yield way higher chances of getting the right product built than just a set of “product requirements” written in a document.

There is a lot of value in running such sessions. The main objective is for the engineers to discover and understand users’ needs so they can later build the right thing that serves the exact purpose of solving the problem it is expected to solve. There are not gonna be any bells and whistles that customers will pay for (or at least wait for because of development time) and don’t use later. It’s a win-win situation.

Wrapping up

In the Q&A session above, Małgosia and Asia shared their invaluable insights into the capabilities of Event Storming and their feelings on the workshops from a non-technical, first-timer perspective. Their journey through the sessions as domain experts revealed nuances and complexities within seemingly straightforward processes, emphasizing the need for deeper analysis and understanding before diving deep into coding. As they reflect on the benefits of such workshops, it becomes clear that they offer a way to build software solutions that align well with business needs.

If you’re curious about how such Event Storming workshops actually look like and how we work, learn more about our exploration of Domain Driven Design and complementary techniques (like Event Storming) by diving into remaining articles from our series where we show the entire process in details:

Blog Comments powered by Disqus.