:quality(90))
Table of Contents
Ever since I started working with clients (that would be 6 years now!), and their evolving businesses, I’ve experienced these uncomfortable moments from time to time. These moments in the process of developing an application, when you’re not sure how to answer a client’s question (and how to deal with the awkward silence that follows). Or when you’re supposed to provide a business validation for a particular feature but, well, you simply can’t come up with one. Those moments sometimes occur at the outset of development but, in most cases, they catch you close to the final release.
Sounds familiar? You who have never had this moment, may you cast the first stone. And don’t get me wrong, of course, I don’t mean that you (or I) don’t have the foggiest idea of how the solutions implemented by us should behave. I’m sure you’re an expert in YOUR field, technical field. But how about the business aspects?
What I mean is that very often we don't discover many edge cases in the process, because we don’t realize how some actions will impact completely separate parts of our app.
We all simply lack some business knowledge. But the good part is that we, developers, are not alone. These questions triggering those silent moments, usually occur to more than one person at the same time. What’s worse — business analysts or even potential customers don’t understand some issues either! And now you will probably say, “Is it a part of my job? Maybe it’s not my responsibility, I should concentrate on the implementation". Well, not exactly.
It’s been such a huge challenge to me until I discovered a method that diametrically smoothed this struggle. I find it the most powerful technique in the developers’ job. But it’s not limited to software development. You can apply it to practically any technical or business domain, especially those that are large, complex, or both. We used it to reevaluate...the HR onboarding process. Interested?
Let me introduce you to the Event Storming technique.
What is Event Storming
Event storming is a very easy technique for discovering how our domain or process works under the hood. It’s based on a collaborative exploration involving both developers and non-technical users in exploring complex business domains. With the help of workshop-style technique, sticky notes and one willing group, you can reveal your business processes more efficiently and enjoyably.
The most important thing—it requires people working on it, as well as experts, to explain everything in the subject of workshops and approach it comprehensively. The key binding rules are:
- Everybody learns from each other,
- Everybody communicates with each other,
- Everybody can speak out if they notice some issues from their perspective,
- Everybody gives their own idea on how to solve problems,
- Everybody knows more or less the same after the workshop.
How Does It Work?
I heard about this technique more or less around a year ago in the presentation delivered by Mariusz Gil named “Discovering unknown domain with Event Storming”. During the conference, I’ve got to know the basics. But basic as it was, it was also very impressive because in less than one hour I realized what I’d been missing for the last 6 years. This inspired me to dig deeper into the subject of Event Storming, so I read this book by A. Brandolini (300 pages in less than one week!).
In a nutshell, it works like this:
- Gather people engaged directly in the process and domain experts in one room. In order to make this workshops effective, you will need at least six to eight people. Invite people who ask the right questions and those who will be able to answer them.
- Put colorful sticky notes on the wall and place “events” from the process on the orange ones and “hot spots”, predicted or presented issues, on red cards.
- Go through the sticky notes and organize them on a timeline. Brainstorm, think, speak out and concentrate on the flow and issues you notice.
- Be sure that no one in the room is left with gaps in mind, uncertainties or questions. All participants must understand everything placed on the wall.
- Identify actors in the process. It might be a person, an external system, an internal process —everything. Don’t limit yourself.
- Concentrate on particular issues and try to go deeper. Try to find improvements or solutions to every event.
- Identify where tangible (like money, users, customers) or intangible (relationship with customer, good user experience) assets exist in the whole system. Don’t focus on profits, remember that losing assets is also important( if not more important)!
- Chose the improvements of the highest importance by ballot.
- Create a chart with your business expert and try to anticipate which opportunities are crucial and at the same time identify the level of complexity.
Event Storming during workshops with Mariusz Gil
It’s a lot, I know. But remember — it’s a very versatile technique and you need to identify which phases are most important in your case and what you expect from these workshops.
I highly recommend you the article where you will find this process outlined step by step in case you’d like to educate yourself. And I will come back to my story.
Event Storming Usage Case
It was time to go on a test drive with real projects. After a few weeks, I’ve got a perfect case. Functionality named “Paid access to the application”. Why was it a perfect case?
We had a few different perspectives:
- User perspective — it’s a very basic action.
- Business person perspective — it’s quite complex, but still, it’s only paying for using the app.
- Developer perspective — it’s complex like hell. There’s no place for cutting corners. Everything needs to be considered and analyzed thoroughly.
Okay, so I had specification for this feature, quite detailed and nice. I forwarded it to my team and we dedicated a few hours to read it, think about it and ask questions. Guess how many questions did we come up with? Three.
Okay, not that bad but I felt that we didn’t discover everything there was to it. I decided to invest one extra hour on double-checking in a simplified* ES technique. What do you think, how many “hot spots”, issues or even simple questions we’ve got after the session? More than twenty. It’s a lot.
We found things that weren’t considered even by the business team. Also, we found a few spots where money could be lost.
For instance, we had information that the account should be temporarily disabled when an issue with the payment for the next month of the app presents itself. Sounds obvious, huh? Nope, I’ve got you! As we were going deeper and deeper through the next edge cases, we realized that users may go vote with their feet, because not only we disabled access to our application, but we also blocked the workflow of their money-making process. They may lose money, customers and a good reputation.
After this experiment, I realized that coding should be an additional part of the event storming session, not the other way around!
*by simplified I mean implementation with two first phases, writing down of hot spots and then talking it over with a with domain expert
Why Use Event Storming
Some time ago, when speaking during the Monterail Academy presentation, I said that the hardest, but at the same time the most important part of our job, is to understand the idea behind every line of code. Indeed. We need to fully understand what we do, why and how it influences the product. We should step into the shoes of the client and user. We need to think about the business goals first, instead of fabricating another feature. And that’s where Event Storming comes to the rescue.
The Event Storming technique provides your business, your project and YOU with the following benefits:
Level of knowledge
By talking about business and technical requirements, participants obtain equally vast knowledge. Each person is focused on the same issues, questions and answers. It’s the easiest way to propagate knowledge when a project starts, when the team needs to be changed or even when a new version of the whole product needs to be addressed. Every participant of the workshops has more or less the same knowledge on the product and current situation. People, very often from distant worlds, communicate and understand different perspectives.
Realizing black holes in ideas
ES is very helpful for a dev team — it’s obvious. But one of the most important benefits of ES is realizing how business processes are defined and considered. In our everyday work we very often realize that some functionalities were well-thought from a technical perspective, but not so much in the business context.
For example, for a business analyst, payments only take place when company receives money from a client and they thought only about this small aspect of reality. They don’t realize that an application needs to respond when the payment is be late or when the payment service breaks down. For that kind of situations ES is the best technique of asking a business team before the whole design or implementation how the process should look like when it’s all rosy, but also in any edge case.
Creativity
There will be a lot of solutions and ideas popping out on how the whole process may work better created in hours instead of weeks.
I see benefits on so many grounds:
- As a developer, you will find out how to hold analytical sessions in order to squeeze the most information from them and how not so scare the client with developers’ strange tools or visuals.
- As a manager, you will find out how to involve a developer in the business angle of the product and make them think about it as their very best project.
- As a client, you will find out how to apply the logical thinking of developers to something more than just implementing solutions and writing code.
Event Storming in... Human Resources
When in the middle of February my colleague designer, Karolina Saniewska, (cause it’s also a perfect tool for designers!) and I took part in the workshops with Mariusz Gil, I had no idea of how badly I’d like to introduce it in my daily work.
But we learned about case studies, facilitating sessions, about how to do it well and spent such an awesome time that the journey with Event Storming couldn’t just finish there.
After the workshops I came back to Monterail and shared knowledge with each and every interested person and we started with event storming internally. The first room for improvement we identified was auditing our HR onboarding process. Yes, it’s possible — it’s not only for the IT domain!
Why the HR onboarding? The HR team had planned the onboarding process for the newcomers at Monterail thoroughly, basing it on their own experiences, best sector's practices and feedback from candidates. But still, their perspective was limited to what they had in their heads and as time passed by, a lot changed in our organization. We grew to +80 people, more roles on various levels of seniority have been introduced and the process needed evaluation.
The team working on the onboarding process included 6 people: two HR specialists, designer, project manager, frontend developer and backend developer. They discussed what information should be in the first welcome email, and which can wait until the first day in the office, what should be the order and duration of individual meetings... and many, many other subjects came up during those creative sessions. Here is a sneak peek into the first phase.
The Event Storming in HR onboarding process at Monterail
That's what Kasia Michalska, our HR specialist says about the ES session and its' results:
"The Event Storming method allowed us to look at the whole process of onboarding from a wider perspective, and from several various points of view. We mapped needs that were previously invisible to us. At the same time, it gave us the opportunity to discuss the onboarding from the practical side. Although it's difficult to indicate all the improvements right now (we're testing them), I already see a vast positive impact on our way of thinking. We are very excited about this initiative and we already listed work areas in which we're going to apply it."
Event Storming in the HR onboarding process at Monterail
:quality(90))