When was the last time your executive asked you to slow down your speed or do less work in speed development?
A more probable scenario is that your manager came to your cubicle to say something like, “We’re planning on moving your deadlines up. And there are four new projects we want you to work on.”
Such conversations take place every day at every corporation in the world. That’s because every business on earth would love it if their staff got more things done in shorter time periods. Anyway, squeezing more and more work from workers has its tradeoffs as well as its consequences. And as useful as those old working models are, their technical nature means many domain experts are more or less excluded from this conversation.
Nevertheless, there is a solution: entering an event storming.
Event storming pushes towards a greater understanding and productivity by streamlining the approach and including multiple stakeholders’ levels in the enterprise. With the help of sticky notes and a group and enthusiastic group, you can reveal your business projects more enjoyably and efficiently.
What is event storming?
Event storming is a lean and agile way of getting groups to collaborate on technical domain projects, share and combine thoughts, and learn to work with a shared understanding. Initially created by Alberto Brandolini in 2020, event storming is a workshop-style approach that draws all project stakeholders together (both non-technical users and developers) to delve through complex business domains. It is intended support that accelerates the development process by joining together relevant stakeholders to quickly model the larger business domain and its projects.
How does event storming work?
You run an event storming as a simplified workshop. Everyone participates, and the organizer keeps everyone focused and engaged, guiding progress toward a comprehensive domain model. At this point, the group involved has to walk through the model forwards and backwards to ensure nothing goes uncovered. They add the commands, or even triggers, that cause the events and consider all sources of commands, plus external systems, users, and even time.
The group assigned has to identify the totals that accept commands and achieve events and begin to aggregate together into associated contexts. Above all, key test scenarios, user’s and goals are identified and incorporated into the new model. Lastly, the link between the bounded context is added to develop a context map. The ensuing model is then challenged with code in order to confirm the group learning and verify the model.
While event storming is currently growing in the software development community, it’s pretty indefinite outside of that sub-speciality, which is a shame because only the organizer has to be a domain-driven design practitioner to lead the group toward a complete model. At this point, everyone, including non-technical product holders, can partake in modelling and understanding and modelling the domain.
Event storming is designed to be two things: fun and efficient. By bringing top practitioners into the same space (regardless if that’s virtually or literally), event storming has the advantages of being:
- Fast: The process is meant to cut down the time it takes to create a comprehensive business domain model or software. In other words, what used to take weeks can be accomplished in hours during a single event storming workshop.
- Straightforward: Rather than relying on complex UML, this approach breaks the process down into simple terms where both technical and non-technical stakeholders can comprehend.
- Engaging: One main purpose of event storming is to make everything about modelling practical and enjoyable. It is a hands-on approach to domain modelling that invites each member to interact and participate. Besides being extremely enjoyable, event storming leads to more valuable insights as participants more easily engage in the process and offer their suggestions and know-how.
- Effective: Contrary to what you might have heard, event storming does not mean data modelling. It rather outcomes in a completely behavioural model that can be completely validated and implemented. For top-notch results, teams should combine event storming with application orientated towards domain driven design.
Where to start?
#1 Invite the right people
Unlike a classic modelling process where whether an individual developer or a smaller group worked on mapping out data, objects and behaviour, even storming is strictly orientated on a larger group (at least 7 to eight participants) to workshop the domain model together.
For event storming to be successful, you must bring together the right people to participate. For instance, these people could be those who know the right questions to ask and the ones who have the answer. This group will most likely be a concoction of stakeholders representing UX, business, development, and IT.
#2 Make sure you provide unlimited modelling space
The gist to a proper workshop approach is its simplicity. Its goal is to get on paper (preferably colour-coded sticky notes) each valuable event and process in one large map. To do that, you will need to provide your team with a large enough modelling space that allows them to build while on the process as ideas and questions arise without being hindered in choice by the physical workspace.
By focusing on the task at hand, stakeholders can work out the processes in a fast way without getting bogged down in a complex mapping structure and complicated language.
#3 Explore the business domain
At this stage, the group will explore the business domains together to uncover a more comprehensive process using the three main components of the event storming process: domain events, commands, and aggregates.
Domain events are nothing more than” things that happen” throughout a process or system. These events are important as they trigger reactions; therefore, understanding the causal event can help your team understand how the system operates and why. On the other hand, the commands allow your team to understand the cause and the consequences that triggered an event. This trigger or cause of the event is marked as a command that is father documented in blue sticky notes.