Article

Event Storming

October 14, 2020

Author:

Kenny Baas-Schwegler

Event Storming: Increasing Performance Through Continuous Discovery, Learning, and Sharing

The strongest predictors of continuous delivery performance and successful organizational scaling are loosely coupled teams enabled by loosely coupled software architecture. (Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren)
 
To create both, we need to rethink how we continuously discover, learn and share information. EventStorming—a workshop-based method for facilitating collaboration between the different IT disciplines and silos—is a remarkable method that empowers knowledge-sharing to this end.
 

Scaling and handovers

One of the significant performance issues we see when teams and architecture are not loosely coupled is that an increase in the number of teams leads to an exponential increase in handovers. These handovers create queues between the teams, which will decrease your teams’ and your company's IT performance.
ThoughtWorks — the global technology company and advocate of Agile and Lean principles and practices — found that, on average, when a piece of work leaves a team (i.e., it requires the effort of multiple teams) the time needed to complete that work is an order of magnitude longer than without the handover. Even worse, faults may be added to the information since handovers can become corrupted by indirect communication that creates the illusion of knowledge. Many of us have already experienced this phenomenon while playing the
telephone game as a child. The more handovers there are between an idea and the engineering teams, the later the wrong idea will go to production.
“The more handovers there are between an idea and the engineering teams, the later the wrong idea will go to production. “
 

Shared mindset and model

To decrease the number of handovers and increase performance, we need to rethink the way we conduct requirements engineering. In standard requirements engineering, each discipline has its own tool for collecting and visualizing their model.
EventStorming offers a different approach and is easy to learn. In just one hour, you are
contributing and creating a shared mindset and mental model of the problem.
EventStorming uses just enough structure (in the form of colored sticky notes representing certain concepts) so that it is easier to visualize processes.
The main concept of EventStorming revolves around a domain event — something that happens and that is relevant for your business. One example in the theatre business is when a ticket is ordered and when a ticket is purchased. We structure these domain events on a paper roll that represents a timeline and we start telling the story, identifying opportunities and constraints along the way. EventStorming is always useful when you tell a story, and it is a great visual collaboration tool for meetings.
 

Visually collaborative meetings

The inspiration for EventStorming came from David Sibbet’s 2010 book, Visual Meetings: How Graphics, Sticky Notes, and Idea Mapping Can Transform Group Productivity. This book explained that people who work visually have better ideas, make better decisions, and are more committed to producing results. Visual meetings — and especially EventStormings — offer a different approach to the classic meetings held in many organizations. EventStorming was first used in the domain-driven design (DDD) community, where designing shared models for complex business problems required a different approach, especially when microservices started to become popular. Quick feedback loops about domain boundaries were a must for avoiding coupled architecture. Because classic modeling tools failed to discover these boundaries fast enough, a smarter way to design shared models with the business and with users was needed and developed.
 

Bounded context — an essential tool for performance

The most essential pattern in domain-driven design for creating loosely coupled teams and architecture is the bounded context. This central pattern is about consistently and explicitly drawing a demarcation line around a business concept and its language in order to make and keep the boundary explicit and consistent. Inside that bounded context, we collaboratively design a model based on conversations with the business, such conversations becoming the shared language for creating software. A bounded context can be created and delivered by one Agile team that is loosely coupled from other bounded contexts and teams.
However, getting the boundary of the bounded context correct is the most crucial decision when building software. To design boundaries correctly, we use a type of EventStorming called “Big Picture.” Big Picture Event Storming brings all of the people who collectively have all the knowledge of the business together, in one room. Here, they can collectively model the business and design bounded contexts, creating loosely coupled teams and architecture. These teams provide an organization with the flexibility to get (and remain ahead) of the competition.
 

Improving the business as a whole

Big Picture EventStorming is also a powerful tool for sharing knowledge and creating a shared vision of the entire business line. In this shared vision, we can also collectively decide what are the most significant constraints in our business strategy. Improving each part of the system in isolation will never yield the same results as when looking at the system as a whole. We want to improve our efforts where it matters most, where they have the most impact on improving performance. A Big Picture EventStorming is a perfect time to visualize the entire business line.
Today, sustainable market advantage is all about agility — being able to respond to opportunities as they arise. To achieve that, we need to stop thinking in terms of IT and business and start acting as an integrated team. EventStorming helps us do this by breaking down the barriers between IT and business. It enables us to share knowledge about what we do, why we do it, and how we do it. By designing bounded contexts, we can ensure that a single team has the autonomy it needs to independently develop and release software that is aligned with business goals.
The result? No more unnecessary handovers.
About Kenny Baas-Schwegler

A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a socio-technical organisation designer and software architect. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change through using visual collaboration practices, the Cynefin framework and Deep Democracy. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing and building sustainable quality software products.

One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.
 

Share this on: