Lately, when you’re attending a software development or an Agile conference, there is a chance that you will hear about something new that catches more and more attention — Event Storming. Very likely you’ve even seen some pictures of people sticking a huge number of orange post-it notes on a wall. Well, if you heard about it, I would love to share some news with you!
Last week I had an absolute pleasure to be a part of the first Event Storming Summit in Bologna. We spent three days in workshops, sessions, and conversations of which some lasted till very late-night hours.
Alberto Brandolini, creator of Event Storming, and his team at Avanscoperta invited terrific people to share their experience and to work on the future of ES: Paul Rayner, Mathias Verraes, Jacobo Romei, Marco Heimeshoff, Kenny Baas, Mariusz Gil, Marijn Huizendveld, Adam Dymitruk, Matteo Cavucci, Emanuela Damiani, Stefan Priebsch, Bruno Boucard, Maxime Sanglan-Charlier, Cedric Pontet, Hoang Chan Huynh, Alexey Zimarev, Gabriel Lana, Martin Schimak, Konstantin Mikhailov, Konstantin Kudryashov and myself. Working with such a team is a truly inspiring and mind-blowing occasion during which one’s brain can explode with new ideas any minute.
Event Storming has its roots directly in the Domain-Driven Design. If you’re new to the DDD approach, key to understand is that it aims to design and help to implement software as a model of a real-world system or process, which continuously evolves. This approach is often used when working on long-lasting, large and complex systems. Important to add is that while using DDD, your team is meant to work closely with domain experts. These are the people who have knowledge about the modeled process and can explain to the others how the real-world system works. They often have a non-IT background, however they’re specialists in their fields. And what’s important to notice, is that’s where all the problems often have their source. We need to communicate and discuss complicated scenarios, which often requires complex and specific terminology, between technical and non-technical teams. Worth mentioning — our project goals or motivations in a project often will also be different, which is perfectly natural. The language we use will also differ (how many times did you hear a different name for the same thing in your process?). Not going into technical details — that’s precisely where Event Storming greatly helps us — coming as an invaluable tool for knowledge extraction and sharing, scoping projects and quickly identifying their risks.
We had great conversations diving into some of the DDD concepts in connection to Event Storming. Big thanks to Mathias, Alexey, Paul, Marco, Kenny, Cedric, Martin, Konstantin, Stefan and Mariusz for sharing their thoughts and experience (sorry if I missed anyone!). However, we could see that it has evolved from its roots and is being used in many different areas around software development by various teams.
Alberto mentions multiple ways of using it. Examples are: kicking off a project or modeling software implementation using DDD or CQRS-ES style, using it for value-stream mapping, or working on UX, but also — using it as a base for a retrospective. We shared our stories around using it for documentation, scoping, design, testing and more. So, I genuinely believe it can become something more significant. With Alberto, we discussed using it as an Evolutionary Accelerator for companies of any kind, which are willing to work on improving their processes. It can become a base tool for business self-understanding, where any company or a team can look at itself from a different perspective, start to measure own processes, identify problems and opportunities easier and make decisions on running experiments and implement the right solutions. So as such, it enables a base for conscious evolution in a very lightweight way.
Single-flow Event Storming
We also shared some out of the box ways of approaching Event Storming. Adam described his own version — one of the most interesting ones from my perspective. We coined a name for it: Single-flow Event Storming. Adam promised to share his idea and thoughts about it on a blog post, so please stay tuned and watch him on his Twitter. It’s an exciting approach not only to the tool itself, but also how to run the session, and what are its outcomes — because it optimizes for rapid time to market of new software functionalities and features.
Event Storming as a glue connecting multiple tools to create unique user experience
From my perspective another very interesting idea was one presented by Hoang Huynh, who uses it together with design tools like: Mental Model, Personas, Customer / User Journeys, Experience Mapping, Lean Value Tree (or Lean Business Canvas), User Story Mapping and Service Blueprint (however, you can use C4 models instead). Event Storming becomes a tool gluing these all together and ensuring common understanding and a shared vision to work smoothly on user experience in any product. Thanks also to Emanuela, Matteo and Jacopo for sharing their thoughts and experience as well!
Hoang’s idea brings to my mind many familiar concepts of the approach we’ve been working on together with Mariusz, where Event Storming as a tool is being used to smooth communication between different roles in software projects: product management, Q&A, design, architects, development, and so forth. However, it is very beneficial also for non-IT team members (like sales, marketing, production, supply chain, finance and so on) — which is truly vital in the modern company. We believe it enables a data-driven business self-understanding and therefore continuous improvement: creating a room for new feedback loops, measurement of the right things but most importantly — asking the right questions to find the right problem to solve. In such environment IT team becomes a consulting centre of expertise. Our role in such environment is to to connect dots to provide the right solutions to the business. I wrote about putting it into practice in my other story „Transformation towards a Data-driven Company”, so I would love to hear your feedback!
Furthermore, I’d like to thank Konstantin for the discussion we had exchanging some great ideas about using Event Storming for data projects, including machine learning and automatisation of processes. Something that is very close to my heart for some time now. It’s a very new area to explore, so please stay tuned — it looks very promising! Thanks Jacopo for your eagerness to help shaping up the concept!
The last, but possibly the most passionate (and emotional!) involving the whole group, was the discussion about the future of Event Storming. We used Event Storming as a tool to work on these topics, so it can only prove it works :). There were many topics covered — from how to evolve the methodology, how to raise awareness around it, to how to ensure it will stay what it indeed is in its heart — a very lightweight, and a very open tool for everyone to pick up and use. There were some conversations about writing a book covering some best practices and example use cases coming out as well, and sharing success stories and ideas on eventstorming.com. This way we want to ensure quick and easy introduction into the methodology so you can try it yourself.
Ps. Thanks for pictures to everyone!