When implementing digitalization projects, one of the key success factors is a comprehensive and shared understanding of the processes to be transformed. Without this common ground, misunderstandings and resulting errors will run through the entire project. Methods like Event Storming, which serve exactly to create this understanding – as simply and quickly as possible – are on everyone's lips. Read about what is behind Event Storming, the experience knowis as a company has made using this method and the advantages it offers to project management within the digital transformation of the financial industry.
Understanding a workflow does not sound like a major challenge. After all, everyone knows the process, right? However, during the detailed analysis even of simply structured processes, many questions arise: Why is an email actually being sent at this point? What is the effect of this step? Who specifically is responsible for this? Only when the procedures and motivations are really understood, is it possible to recognize inconsistencies or stumbling blocks, eliminate them and digitalize the process effectively.
It gets particularly tricky at the point when the functional requirements are to be translated into solutions that can be implemented by the developers. Ultimately, they will develop the software as they understand the specification. Lost in Translation - misunderstandings are inevitable! Dissatisfied customers and stakeholders, frustrated developers and a lot of wasted budget and wasted time are the result. The goal of rapid time-to-market is a long way off.
Many service providers in the IT industry are eager to find methods that enable them to avoid this problem, and work out a comprehensive common understanding from the beginning. As a software company that deals with the complex processes of large financial institutions on a daily basis, we are always on the lookout for new and better approaches. Event Storming is one of them.
What is Event Storming?
In short, Event Storming is a communicative method in which participants from different areas work together to explore and visualize the knowledge and understanding of a particular, clearly defined field of knowledge (a domain). The starting points are the so-called Domain Events.
What do I need for Event Storming?
A room with no seating, participants from different departments, a broad strip of paper on the wall and a whole lot of colorful Post-its – unfamiliar terrain for workshop participants! Each color and size of the sticky note has a specific meaning. This is determined in advance in a kind of legend, which serves as a point of reference. But that is it with the formalities. Lengthy lectures or set guidelines are definitely not welcome here. This means that every opinion is heard and valued, but also that communication and active participation are required. The first time a workshop is designed according to this method, it can certainly lead to challenges. Not least for this reason, it is extremely important to assign a moderator to step in when needed. He or she does not direct 'from above', but guides when necessary and helps to ensure that the group does not get bogged down too early in the subject-related details.
How does Event Storming work?
The starting points of an Event Storming are the so-called Domain Events. These are events within the domain that the experts consider relevant. For example, if we are in the domain 'Budget', Domain Events could be 'Budget Prepared', 'Budget Checked', and 'Budget Settled'.
These events are written on Post-its of the same color and arranged chronologically on a timeline. The inventor of the Event Storming method, the Italian developer Alberto Brandolini, uses the color orange. It is assumed that these events have already taken place when the group poses questions as to their causes – thus, the events become the basis of the discussion. Based on our example of the domain event 'Budget Settled', one question could be: "What happened to allow the budget to be settled?" Participants contribute their knowledge and start exchanging views: the spark for transfer of know-how, learning processes and aha moments.
Afterwards, potential problems or ambiguities within the process are identified and marked with sticky notes in a different color. This points out a special feature of Event Storming: the method is problem-focused. Many other techniques use a reverse approach, as they proceed from the needs of users or stakeholders. The disadvantage of these approaches is that new solutions and ideas might never come to light.
At an Event Storming workshop, a big picture of the domain is created first. In the next step, this basis is supplemented with particulars, analogous to the concept of Domain-Driven Design (DDD). DDD is a method for modeling complex software with a focus on functional contexts. For this visualization, differently colored Post-its are used, for instance, for categories such as
- event triggers (what triggers the event, for example time or system),
- users (who are the protagonists) or
- read models (data needed to make a decision).
The scheme developed collectively during Event Storming thus becomes the starting point for design and implementation according to DDD.
Experiences with Event Storming at knowis
At knowis, employees continuously develop their methodological skills and are always on the lookout for new and promising approaches. Our business analyst Vanessa Vouilléme has been involved with Event Storming for some time and has already conducted her own workshops. She talks about how she came into contact with the method and shares her impressions and experiences.
Vanessa, how did you hear about Event Storming?
The head of my team, Michael Rehfisch, attended a seminar with the inventor of the method, Alberto Brandolini, in Italy. He then provided us with documents for opinion forming and implementation. As a team, we decided to try out the method.
Why did you think that this method would fit well at knowis?
The relation of the method to our company philosophy and our approach to projects immediately appealed to me: the active participation of the stakeholders and the consideration of their problems, the focus on specific domains analogous to DDD as well as the parallels with agile software development (here we already use Scrum) and agile project management. With Event Storming, you can be thoroughly agile because even the 'first step' for process representation can be mapped in this way.
How did the first Event Storming workshop go?
Our trial balloon was a workshop for a suitable internal project at knowis. Here too, the typical situation described above already existed: stakeholders from different areas of responsibility, cross-divisional functional requirements, 'translation problems' between domain experts and developers. I was surprised how well the method worked with some preparation, after we had overcome some initial challenges and, for example, the moderator had identified with his role. We were able to capture risks, problems and opportunities at a very early stage and there was a lot of aha moments among the participants.
Conclusion
Is it overrated brainstorming or the future of domain modeling? Event Storming is increasingly gaining in popularity. One reason for this is current developments in IT, such as the trend towards microservices. These architectural patterns force everyone involved to get to know their domains in depth, otherwise communication between modular services with small, specific tasks will hardly be possible. The motto is think through and understand rather than develop hastily. Whether the method will prevail in the longer term or if it is only a temporary hype remains to be seen.
One possible hurdle, in our experience, is that the more people participate, the more difficult it becomes to coordinate the workshop. For this reason, there is a strong focus on the moderator, who is responsible for continuously drawing attention back to the essentials and preventing digressing discussions.
However, the advantages, especially from the customer's point of view, cannot be dismissed. Through the open improvement process and the involvement of the right stakeholders, a high degree of transparency, creativity and understanding is achieved. Intuitively, everyone can get involved without having to worry about formalities, in contrast to notations such as Business Process Model and Notation (BPMN) or Unified Modeling Language (UML). This supports the effective and collaborative modeling of complex business processes. By using paper, pen and Post-its, processes are visualized directly; no computers or special tools are required for the implementation of an Event Storming workshop.
Our conclusion: Event Storming is, fundamentally, a sensible method for agile projects, but requires a certain amount of practice in order to use it purposefully.
Image Sources: Teaser: Flamingo Images - 687920250 - iStock; Infographic: knowis AG
