29
.
04
.
2024
10
.
10
.
2022
Visuality
Event Storming

Our journey to Event Storming

Michał Łęcicki
Ruby Developer

As you may have noticed, or not, for some time we are talking a lot about Event Storming. This workshop technique amazed us at the first sight and we successfully incorporated it into our work standards. But it was a bumpy ride. Let me tell you the whole story.

Before...

Since the very beginning of Visuality, we have shared many values described by Alberto Brandolini. One of them is the beauty of personal contact. Whenever we start a new project, we try to meet our client and the project team in person. We travel to their office or invite them to our mansion. This is a great occasion to see how communication works and gain more information about the project or product. We organize a workshop meeting. We ask many questions and clients describe the most important parts of their business. Such meeting includes also developers who can get details about technicalities.

Event Storming people

Unfortunately, we've always felt that those sessions are not enough. First, at the beginning of the relationship with the new client, we simply don't know their business. Thus, we don't know what we don't know. A bunch of right questions won't be asked. Second, people from the client side tell us only what they know or think. We don't have a chance to see their business from different perspectives. Typically, after such workshops, we know only the surface of a client's product. It's very visible in first sprints - developers feel often lost and lots of effort is put into describing tickets in a detailed way.

A change was needed

We started improving the process of gathering information. In the beginning, our CTO, Mariusz, introduced a more workshop-like style to the meetings. Using a whiteboard for drawing or designing things came naturally. But it wasn't enough.

Event Storming Mariusz thinking

At this moment Event Storming enters the scene. The method was mentioned in many courses, always in a very positive light. So we decided to try it out. We read about it, discussed it, made notes, and eventually performed a few internal ES sessions. It was a blast. So we prepared to use it in production, with real clients.

…and now

The technique created by Alberto Brandolini belongs to a different league when it comes to the amount of gathered knowledge. What is Big Picture Event Storming?

  • gather key people in one room: managers, developers, representatives from different departments
  • visualize all business processes on sticky notes and put them on the wall
  • debate about all uncertainties and make events ordered
  • profit.

I don't want to describe how exactly the Event Storming session looks like (you can read about it here or watch it here). Instead, I want to focus on how we use it and what profits we see.

New formula

Again, we try to meet the client in person and organize a workshop (although it's also possible to make it remotely). We invite more people - not only managers but also developers, QA, and people from other departments. We spend one or two days on Big Picture Event Storming, which is led by one of our consultants. This is no "one more meeting". We gather in one room and use tons of sticky notes. And we have lots of conversations and arguments. Eventually, we gain a deep understanding of the business and its most problematic places.

Event Storming board cards

The biggest benefits:

  • no preparation is needed from the client's side. Just one room (or online tool), colorful sticky notes, a blank wall, and key people. That's it and we can start.
  • huge exchange of information. I can't compare it to any other workshop (or non-workshop) technique. Potentially, each discussion about problematic sticky notes reveals new information about the system. Or, provides the background behind the debated problem.
  • a common understanding of the business domain. It's more than knowledge about certain features or bugs. It's learning which are vital parts of the business and what is the unique value of the company. Without it, developers could introduce correct code that won't reflect the business domain. With it - they can build software that is 100% tailored to business needs.
  • flexibility. Each ES starts with a certain goal, but how you achieve it is up to the participants. Workshops have proposed flow, but it isn't mandatory. So Event Storming can evolve into drawing diagrams or context mapping sessions. Or even writing pseudo-code solutions.
  • spreading the culture of openness. Event Storming efficiency is based on the number of questions and answers exchanged between people. Simply put: workshops need straight communication. If you are not afraid to ask evident questions to your CTO during ES, you will not hesitate to do it later too.

Few challenges

There are some things you need to be aware of when doing Event Storming:

  • Find the right person to lead the workshop session. While participants don't need to know anything about Event Storming, a competent leader is a must-have. The skilled moderator needs to have a plan for every workshop. He or she needs to know how to interact with attendees. And of course - how to facilitate the whole process to make all discussions productive.
  • Be ready for talking. Stereotypical software developers want to just sit in front of their computers and hit fancy keyboards. ES forces them to step out of their comfort zone and talk to real people. And talk a lot, sometimes about difficult topics. So you can imagine it's not easy for everyone.
  • Prejudices. From our experience, we can tell that people from IT don't trust workshop techniques much. Everyone (at least once in their life) experienced a boring, time-wasting workshop. That's why kicking off the Event Storming session is very important.

To sum up

Considering all mentioned factors, Visuality uses Event Storming whenever possible. Initially, we schedule an ES workshop with our new clients. But we also do workshops for long-running projects. Or, we even do workshops for already finished projects ( aka retrospective Event Storming). In all cases, we see that the time and effort spent on Event Storming are worth it.

Michał Łęcicki
Ruby Developer

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Recap of Friendly.rb 2024 conference

Insights and Inspiration from Friendly.rb: A Ruby Conference Recap

02
.
10
.
2024
Kaja Witek
Conferences
Ruby on Rails

Covering indexes - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby on Rails
Postgresql
Backend
Ula Sołogub - SQL Injection in Ruby on Rails

The Deadly Sins in RoR security - SQL Injection

14
.
11
.
2023
Urszula Sołogub
Backend
Ruby on Rails
Software
Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

14
.
11
.
2023
Michał Łęcicki
Hotwire
Ruby on Rails
Software
Tutorial

Freelancers vs Software house

02
.
10
.
2024
Michał Krochecki
Visuality
Business

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial