First, a short history lesson. The phenomenon of Event Storming was first described in 2013. Its discoverer is considered to be Albert Brandolini, an IT specialist who was bored with projects implemented in the old, established way. This weariness led him to further explore the fields of Domain-Driven Design, Lean and Agile Software Development, team management and learning. Brandolini focused on creating a creative ferment that, if tamed, can bring real benefits.
The new teamwork technique was well received by the first target group, i.e. the specialists dealing with Domain Driven Design. The method was quickly noticed and appreciated by the IT industry. In the “Technology Radar” guide prepared by the ThoughtWorks agency, Event Storming was described as a recommended method for collaborative discovery and modeling of processes occurring in complex business domains. It shows how to describe the operation of a particular system using a series of events.
What is important, Event Storming does not only concern software development. Today it is a method used in – often extremely different – areas of business. As befits a real storm, everything happens here more rapidly and quickly. Instant group action makes it possible, often in a few days or even hours, to achieve what traditional modeling techniques require much more time.
Having read all these superlatives, someone may ask what exactly this Event Storming is about – because we have already found out that it is effective. We would like to explain. To fully understand “event storming” we need another, insanely important concept. It’s about a “domain event”, i.e. everything that happens after a particular software is launched. To put it even more simply, these are the actions that a user performs in order to achieve the intended purpose, let’s say navigating the application, clicking on its functions, accepting invitations, adding tags, granting various permissions, etc.
Event Storming is not like working on software in a technical language. Participants of the session are interested in everything that has to happen in order for an already working application to fulfill its purpose.
Event Storming – how is it done?
In accordance with the principle of event storming, a meeting is attended by all the people who know the set of processes to be transferred or combined within the application (this principle applies to both the organizer and the client). The moderator, like a ringleader, keeps the team fully focused, cheering their creativity and stimulating their involvement in the formation of the final work. The result is supposed to be the first, complete model of the domain.
Before the session itself, make sure that each participant has a sufficient (read: large!) number of different colored sticky notes. One color will be used to mark the event, another to mark the action, and yet another to mark the user, the unknown and external systems. The meeting will also not do without a large whiteboard or a roll of plotter paper, which stretched on the wall, will serve as a board for generating events (cards).
Step number one is the – initially chaotic – collection of fiches with events written by the specialists present at the meeting. This leads to the first analysis of the model – it is disassembled, viewed from the front, back, top and bottom. It is important to make sure that no element has been left out.
The idea is to start creating events from the inside, so to speak, answering a series of questions that “encapsulate” the emerging model. Why did the user use the application or enter the website (what had to happen)? What are his next steps within the system? What should happen for him to react in the way desired by the customer. The cards change their position, creating an increasingly clear model.
The next step again involves a combination of expertise and group imagination catalyzed by the facilitator. The team is tasked with inventing, predicting, and then adding commands that will result in specific events. However, this is not the end. For the commands generation to make sense, all their sources must be taken into account, i.e., users, external systems, and even time! It comes to distinguishing aggregates, i.e. arranging events, commands and actors into groups. This creates sets containing all data related to a particular functionality, thanks to which each of the participants, and even an outsider, will be able to understand what the functionality is about. An example of such an aggregate can be the publication of a post on Facebook consisting of a number of domain events, commands and actors whose cooperation leads to the appearance of a given content on the site.
Each of the mentioned elements, i.e. both aggregates and the events, commands and actors that are part of them, helps to create a complete project.
Strength in a group
Event Storming is one of the best examples of the fact that in teamwork lies a truly creative power. Only brainstorming and the resulting bounty of ideas can generate a satisfying number of domain events. The real power of Event Storming is what we might call the “clash of titans”, the clash of creative, expert minds. It’s all about discussion, which will make it easier to implement later. What is important, the “storm of events” is carried out using a free, understandable for all language (ubiquitous language), which makes it easier to imagine the final effect.
For the client, a huge benefit is not only the opportunity to participate in the creation of the project, but also obtaining full project documentation in the form of User Stories and events on the timeline, accurate project pricing and extremely useful technological knowledge. The last element is knowledge, which is a profit in itself leading to other profits.