Event Storming: Build The Right Thing, Right

Hello, and welcome to my talk. My name is Savvas Kleanthous,** **and today I'm going to be speaking about Event Storming, Building the right thing. In this presentation, I'm not going to be—I'm not trying to teach you how to run an event storming session nor how to participate and what to do during an event storming session. For that purpose, I'm going to be running a workshop in the next couple of days with some of my colleagues. And we're going to be using big picture event storming session to actually teach the participants how that works exactly, so that then they can run their own event storming sessions in their companies, if you're interested join that session for that reason.

In this session, what we’re going to be doing is that we're going to be presenting some of the issues that existed in different companies during that implementation process and product building process. And then, we'll see how event storming session comes and addresses most of those problems quite nicely. After that, we're going to be seeing the three different types—the three major types of event storming sessions and what problems do they address and how do they roughly look like? So ideally, at the end of the session, you will know why would you need to run an event storming session and which type of event storming session would you need to run to solve the different types of problems that you may be experiencing.

So first, let's start with the problems. So, I'm going to be doing this through taking some examples from my career, in different companies that I worked for. And it's quite a coincidence that—I mean, they happened in chronological order. I expect that not all of these problems are going to be experienced by each and every one of you. Some people may know of a particular problem more than others, but regardless, we're going to be seeing how those manifest problems. And later on, as I mentioned, we're going to be seeing how event storming solve that.

The first couple of roles that I had as a junior developer were in very traditional enterprise environments. So, in this environment, everybody basically was in a separate team based on function. And the communication across those teams was next to non-existent, and when that—when it happened, it was through formal channels in written communication. Now, just to give you an idea, we had a project manager who had their own office, separately to everybody else. Architects, their own office, separate to everyone else. Business analysts, separate from the development team. Software developers, separate from testers, which were separate from designers, which were separate from UI, we even had that distinction.

And so, you can understand that when requirements were to come in, when the project manager maintained that big list of the roadmap or for feature deliveries, whenever they requested something that was in—they pushed it to the architects, the architects did their own things. And they also pushed it to the business analyst who did their own requirements, and they were the only ones speaking with actual subject matter experts at those companies. And then, architectural diagrams plus requirements were then pushed to the software development team. The software development team needed to do—to implement the feature, so we went and implement whatever we needed to implement based on those restrictions of architecture and the requirements. When we finish, we push that to the testers, and the testers did their own thing independently. If they found any bugs, then it went back on the cycle.

So, that’s a quite long feedback loop and a slow one as well. And sometimes it had to go back to the architects and business analysts as well, accordingly, but not that rarely, in fact. So, as you can understand, that's quite a problematic situation where that it results in delays of deliveries, or, I mean, neither of those two companies did the plan that the project managers did ever, was in fact accurate. So, not a single release went on time. And even then, the release had problems in them. The users were unhappy. And even with the delays, we still had to do quite a lot of overtime to finish within a reasonable amount of time.

Now, fast-forward a couple of positions, and I'm now in a different company. The company realized that that old way of doing things was not really healthy, so they just changed it slightly. So, we're now seeing some lessons from the Agile community being adopted by larger companies. And we're now starting to see some breakdown of those barriers that existed between the different teams and responsibilities. So, the business analysts now communicated regularly with the software development teams. The tester was now a role that was inside of the development team. So, there was no long feedback loop. There was still a feedback loop of sorts, but at least it was much shorter now. And generally, there was no distinction between UI and server site, so we now started to see the development teams being a bit more cross-functional. So, that's a better situation, but still we have problems. So as you have—as most of you’ve probably guessed by the picture that I used, I'm going to be speaking about how isolated the architect was here, and also the project manager.

So again, the project manager maintained their own roadmaps, this time using gun charts. I don't know how many people are—have fond memories of gun charts, I'm not one of those people. And again, the architects were in their own offices, separately to the development team. Again, project manager requested stuff, architects doing their own stuff independently of the development team. And those got pushed to the product teams, developer teams. And the business analyst, again, was the only one kind of speaking with the subject matter experts. Again, the developer was not allowed to speak to subject matter experts directly. All of that communication had to go through the business analyst, but at least we had close communication with the analyst themselves.

So, the situations, that's quite an improvement, to be honest. However, it still has exactly the same kinds of problems, just less pronounced. So, we still have delays in delivering features. We still have missed opportunities. We have customers not being satisfied because the features that got implemented were not exactly the ones that they asked. We have accrual of technical debt, which I forgot to mention earlier. So, the fact that the technical—the architect is not informed and is not aware of the situation in code, actually causes the accrual of technical debt. Because the software development team can actually implement an architecture, regardless of what the architecture looks like. But in doing so, some of the lower level, lower level decisions that are being made are definitely sub-optimal. Not to mention about what's the limit of the architect in those companies. That's another discussion and another potential presentation altogether.

So, fast-forward a couple of positions, still. And we're now in a situation where Agile finally won. So, the Agile finally won meaning that at least in startups, we're seeing the overwhelming majority of them adopting Agile as kind of—I think that every startup is doing. So, you will be really hard-pressed to find any company not doing Agile at that point in time. And one would say that finally, I mean, Agile is supposed to fix most of these problems that I have been describing so far, right?

Well, it does, but it also kind of introduced different kinds of problems. So, not due to Agile itself, so I'm a strong believer in Agile methodologies and Agile principles, in fact. But, however, the application of those Agile principles or the interpretation rather, of Agile, and implementation of Agile frameworks, caused the problems that we used to have before to change, but still have problems. So, what we're seeing now is—so the good thing that we're seeing is that we're finally seeing a breaking of the barrier between the responsibilities. So, we are now no longer seeing testers are separate. We have testing in the team. We have UI and server side again in the team. We have business analysts existing in the teams, or even not existing at all. So, the non-existent part is a little bit of a weird situation. I don't know whether that is a benefit or a drawback, but it does start to happen. And the communication with subject matter experts being more direct is somewhat of a benefit. So, that's a little up for discussion. But we're also seeing at the same time—also, the architects being part of the development team as well or at least very close to it.

But at the same time, we're seeing some negatives. So, as a knee-jerk reaction to what existed before, we're seeing now a rejection of any kind of upfront planning. And at the same time, we're seeing the rejection or any bigger picture planning. So, we're not seeing far into the future. So, what do we need further on? And we're not seeing the breadth of things as well. So, what other teams are doing? What kind of dependencies exists across those different cross-disciplinary teams and feature related and journey related teams? So that again, it causes the same kinds of problems. Again, delays, missed opportunities, again, accrual of technical debt due to different reasons than before, and so on and so forth. Again, not a very nice situation to be, even though a lot of the old problems were solved.

So, we're now in a situation where one asks, “Why event storming, and event storming comes to actually solve those problems?” So, event storming fixes all of those problems, maybe not entirely, but it at least contributes very positively into fixing those problems. So, we're seeing no more silos of communication. In event storming, everybody participates and everyone has a voice. And that means that we are also seeing the reduction or disappearance entirely of feedback loops, because of that single session where everybody participates in and has that voice. Also, we're seeing that different, at least from different types of event storming, we're seeing that there is clarity about what's going on. The architect can see and understand how the code works and what the situation in code is, not having to spend multiple months in software development. And that can be achieved by a software design event storming. The product owner can understand how things are functioning, and they can see opportunities in software and in different models and different approaches that we can take. And this can be seen in big picture or process level event storming, and so on and so forth. Also, a shared understanding. Everybody can understand what problems does a product—does our product actually try to address, how things are working in general, and also a visibility on what the other things are doing. So, we're gaining that breadth of information that was lost during that translation from enterprise to—well, from a traditional enterprise to an Agile enterprise, potentially.

So, those are the kinds of benefits. But what really is event storming? So, event storming is a highly collaborative workshop. That means that when I say highly collaborative, I mean, a lot of people working together at the same time to create a model of office system. So, we're doing that also by focusing on the events. So, all types of event storming sessions start from the events that the system, or at least the scope of the system that we're focusing on at different points in time. And we're starting by the events, and from that we're building on top of our understanding and knowledge. It's an immensely powerful workshop to run as well. And when I say powerful, I really mean that because—I mean, I have run a lot of event storming sessions, especially in the past three or four years. And I have never once seen an event storming session not being successful. It may be less successful than other times, but it was always successful. At least some benefits were gained at all times. And I'm still talking about the same team, roughly, and the same participants in the same company. So, running it more than once is highly recommended in fact, then iterating and incorporating the lessons that you learn as you develop your product.

What makes it useful? It’s slightly different than the benefits that they exhibit. What makes it useful is that it focuses on those discussions, in those types of—well, the discussions that didn't used to happen. So, when we are having subject matter experts trying to collaborate with us, the software development teams are next to them. They are going to be speaking to the subject matter experts, trying to understand why these subject matter experts suggest something or trying to document something in a specific way. We are seeing the language that the subject matter experts use being made visible and not having to go through layers of interpretation. So, those discussions are an important factor of why an event storming session is successful. Also, focusing on the events that exist in a system is actually a very natural way of doing things. Now, the subject matter experts don't keep a record of the events explicitly, they won't have a list of—so, we have event number one, and event number one is called like this or event number two, and it's called like that. They don't—they won't know even, when you ask them what an event is. However, what happens during the event storming session is that people start to understand that there are certain things that happen that cause changes in the system. And that way of thinking about those pieces of those small changes is actually a very natural way of working in the system. Because very often, and that used to happen, is that somebody phoned someone, a form was filled, a payment was made, something got shipped. So, all of these things are things that the subject matter experts know, even if they don't recognize them as event. And recognizing, identifying those changes, it's actually quite important, and as I mentioned, quite a natural way of understanding a system. And we're starting with the bigger picture, and we're able to like understand the whole thing through those domain-specific changes. Another thing that makes it quite useful is that event storming sessions are very easy to refactor and change and to experiment to see different types of approaches, and to be able to evaluate those different approaches and discuss, again, those different approaches. So, if we've noticed that something is doesn't feel very well, we can throw the stickies on the floor. And then, put another—put other stickies on the wall, and just see how that looks like and how our subject matter experts feel for that approach.

So, why event storming specifically and not something else? I mean, there are a lot of workshops, there are a lot of tools that we can use, why event storming and not something else is solving this kind of problems? So, I think what makes event storming unique are the first couple of points that I mentioned on this slide. So first of all, brainstorming, and secondly, how easy it is to refactor. Other workshops tend to focus on getting things accurate and correct. Event storming doesn't really do that. So, event storming facilitates brainstorming ideas. So, trying to like see something quickly, see how it looks like and from a holistic point of view, and then being able to discuss and assess it. And if it doesn't feel good, to change it, refactor it, and then look how the resulting approach works. If something—if there is a gap there, we have all of the people in the room so that we can discuss and brainstorm on idea. And usually that results in a very efficient and quick way to come up with a possible solution. Where if we had breaks in communication, or at least delays in communication, that would—could have mean days or even months to come to a solution, or at least something to experiment on. The one other benefit of event storming that most other workshops also don't exhibit is that event storming can work on multiple levels, and it's designed in fact to work in multiple levels. And it's designed to work on multiple levels to have to exhibit different kinds of benefits and drawbacks. Also, this is one of those workshops where subject matter experts can actively participate. So, we always had interviews with subject matter experts as one kind of tool to extract the requirements from them. But event storming session actually puts the subject matter experts on an active role. So, they no longer just answer questions, they can drive the model that we create, they can drive the brainstorming session. And also, as a final point to this is that event storming session breaks down any different kinds of gates in getting to formation. By that, I mean that—so, it’s the situation with the business analysts that we used to have. We had to speak to the business analyst in order for the business analyst to speak to the subject matter expert, and get us the requirements back. And that gated communication could result in different interpretations. So, when I listened to the subject matter expert, I may understand something different than the business analyst may understand when speaking with a subject matter expert. And that is another quite important or aspect of this workshop, that everybody participates directly with everyone else.

So, now that we know why of—the Why's of the event storming and what kinds of benefits they have, it's useful to go to the field major parts of brainstorming. First, and I think more important one, and it’s the one that we're going to be running on the workshop in the next couple of days is the big picture event storming session. Big picture event storming session will look like this, roughly. So again, as I mentioned, we might—we focus on the events, which are the orange stickies in this case. And so, you will expect to see something that approximates a map of connected events. So quite probably, what you will have is going to be vastly more chaotic than this. And that is a good thing as well, as you will see if you participate in this session in the next couple of days. So, that's why generally I strongly suggest that you select the tool that has an unbounded canvas in order for you to use this. If you're doing it physically, select the longest, biggest possible wall that you have on the building. If you don't have one that is at least 8 to 10 meters long, rent somewhere that you can—that does have this kind of length of walls. Corridors, funnily enough, work okay for this purpose. Even though there isn't a lot of space to go back and see the bigger picture, which is a kind of a drawback for corridors. But on the other hand, it still gives you the breadth of a wall space to run. Gardens, sometimes—anyway, from online tools, Miro is one good one. It allows you to zoom out, you can see the whole picture. You can zoom in, and then it expands as people put stickies on the Miro board. So, that’s a really good tool, Miro, I very strongly suggest that you use it. By the way, if you are not doing that—anyway, moving forward.

So, big picture event storming is an exploration of the problem space primarily. Again, as I mentioned before, the focus of big picture event storming is on discussions. We expect to see a lot of subject matter experts speaking about their own area of expertise. And what we also expect to see is that there are clusters of these kinds of departments, like functional departments within the company. So, we expect to see also that there is like, something—like a story going from beginning to the end a crossing those whole departments, and how data move—how things happen from one side to the other, and how the thing progress. And importantly, we have a clear visibility here. So, it doesn't matter what position you're in, you're going to be having a very clear picture of how things work holistically and as a whole. And how do stuff that you do affect your neighbors directly, but also how things you do affect the whole thing. So, that shared understanding of how things are working and how things should be working and what is the kind of behavior of your system, is something extremely powerful, which again I mentioned is key, is one of the distinguishing features of event storming—big picture event storming. Now, important to notice here, and I've noticed that I've put that on this slide, is that this single event storming addresses almost everything, all of the problems that I mentioned in the beginning.

So, who participates in the big picture event storming? Now, ideally, everybody, and I’m not exaggerating here. If you can get every single person working on a product in the same room to do a big picture event storming, absolutely do this. I mentioned the founders of companies, so it's very common that you will find a small enough numbers of people in startups, in which case you will be able to reach the founders. Now, having them participate in a big picture event storming has amazing benefits. If for no other reason, is that you get buying from the high ups in the company to actually continue on this workshop, and redo this workshop to continue getting the benefits of updating your understanding of the big—of the product as you learn more about the behavior of the system and as you learn more about how your users use the system. Subject matter experts also equally important to participate, obviously. You want to get as many subject matter experts in the big picture event storming session. They can drive the implementation, and they will own—sorry, not the implementation. They will drive the model, the creation of the model on the wall, and they will probably own sections of that big picture modeling session. So, you will see them standing in different places. And this happens naturally, by the way. We want analysts because we want to have those discussions happening, and our analysts are trained to discover edge cases and speak about and understand how certain things are happening. And they will know how to drive some of those discussions. We want the product teams there because the visibility of how each different teams deliverables affect the other team's deliverables. They will be able to understand why they're building what they're building. They're going to be seeing what features are needed next for that bigger picture to work. We want users, ideally, because obviously the product is built for them. So, their feedback and contribution in this session is quite useful. Not everybody can get users in for a session like that. And these sessions tend to run at least four a day, so it's not always easy. But if you can get users, if the users are internal to the legal entity that you are working, for example, that is really, really useful.

As I mentioned before, a primary—the primary thing that we're using in big picture event storming is events, those are the orange stickies. So, we're going to start with the events in the beginning. And for the majority of the big picture event storming session, we're going to be only having events on a board. When we're noticing that there is a cluster of events, when we're noticing that a lot of discussions are happening between subject matter experts and people, or whenever we have heated discussions in different positions, when we cannot understand as facilitators when something is happening, we tend to put a red sticky there to indicate the hotspot. And we probably don't want to discuss implementation of external services, so we used to hide external surfaces and their behaviors using pink stickies. At the end of the session, it's also quite useful to indicate problems and opportunities. So, that's another way where we can get input and shorten those feedback loops from people that may not normally drive the implementation. So, problems are things that we need to address, opportunities are things that we can consider to make things better. So, not a lot of things to learn and that's why this is a quite an easy session to run with a lot of participants.

Process level event storming. Process level event storming is a zoomed in version of the big picture with some added moving parts. When I say zoomed in version is that—in big picture event storming, we want the biggest picture that we can get for the product hence the name. In process level event storming, we’re taking a single process that is one part of that big picture that we created before. So it's a natural thing to happen to first do a big picture event storming, and then follow up with a process level event storming to model a particular internal workflow. As you can see here, we have a different stickies, we're going to be discussing exactly what they are. But it looks different is what I'm trying to say.

So, again, it's a collaborative workshop. It's just that this time, instead of trying to model the end-to-end of a system or the problem space that we have, we’re now zooming in moving closer to the solution space and trying to model a particular process, a process that has a clear start and a clear end. So, that's the boundaries that I'm going to be discussing about. Now as a comment, this is usually, but not always, the right level to stop and then try to implement to get feedback or more meaningful feedback than the feedback that we usually get during the session. And by that, I mean, it's usually enough. We have enough information for the development team to take, maybe potentially do some analysis on it and start implementing to get answers.

Who participates in it? The roles of the people that participate in are kind of the same, but it's not the number of people participating is certainly smaller. So, usually this is because the workflow doesn't span more than one or two teams of software developers. It's probably focused. So, we are rather speaking about the workflow of taking a payment, the workflow of purchasing some things, the workflow of shipping something else. So, it really depends on the company, but it's usually much more focused and fewer subject matter experts are going to be participating. So, we still have subject matter experts. We still have product owners. We still have designers, testers, business analysts, developers. All of the roles are there, it's just that teams that are not participating in that process level event storming may not be there. I mean, if you can have some of them. The difference in perspective, I found that it actually helps in creating a good process level event storming, but it's not always necessary.

The legend, as you've noticed by the sample that I posted in the beginning, is different. So, while before we focused on events, and we had hotspots before as well, we still have events, we still have hotspots, but now we have like more. We have primarily the introduction of commands and data, which is all the commands are the blue stickies, data and view models are the green stickies. And we put them down so that we know what kind of data is required during those processes and workflows, so that we know that we need to at least have this set of data before something else happens, and so on. We also have systems, internal or external. So, we're focusing on the workflow. So, if at some point in the workflow we need to send an email for something else to happen, we don't want to also model the email internal—the email system internally. We abstract that detail behind that big sticky. Another important and useful sticky to use is the eventual consistency role here. So, this is something that basically, well, you can consider a process manager. So when something happens, and then there is an orchestrator that should orchestrate the certain set of actions. So, this happens, and then you need to do this thing, you need to do that other thing, you need to do that other thing in response to that. If something happens, then you kind of go in and do it. For example, that will be an eventual consistency rule that we can document using a purple sticky.

The final type of event storming session that I’m going to be discussing today—there are other ones as well that I won't discuss today—is the software design event storming. Now, this is the lowest level of event storming that I am at least aware of, and it's the level that is closer to the software development to the implementation as possible. So, this is what you can immediately take and implement. And even though it still focuses on events, those events do not necessarily need to be in software. I mean it's—we're talking about events that are describing a certain action. So that will—can be implemented as a context to a call as a return value. It really depends, but we expect—we do expect to see those events existing in software in some way, either as a set of data, or as I mentioned, like a context or return values. The same people that participate in the process level event storming will participate in the software design level of event storming.

So again, subject matter experts, product owners, UX designers, testers, everyone in the team will participate. Again, we probably are more focused to the team that we'll be implementing or that will be doing the implementation. It looks very similar to the process level event storming with a single addition of the immediate consistency rule. So, these are very important. These are stuff that have to always be true. And so, we can take that rule, and then implement it in software according to the patterns that we're using at that point in time. So, just to give you an understanding and an example of that, we're talking about rules, like a park count has always had to be above zero or positive. So, the balance of an account has to be zero or above. So, those are kinds of rules that will be represented with a yellow sticky, that invariant. And a final comment that I wanted to make is that I found it very useful and it's quite common to go from a process level event storming session, like we finished with that, feel comfortable with that, and then we're starting to introduce invariants to that artifact and, and take it directly to the software design and modeling session. And that gives us good enough results to actually go and implement it, and it's quite accurate and close implementation.

Finally, if you are doing event storming—sorry, events sourcing as a persistence pattern for your entities, event storming sessions are something that you definitely want to look—to start adopting, and especially in the software design level of event storming. And that's it. Thank you very much for attending. All of the slides of this presentation is on my public report. And if you are interested on this subject, please feel free to follow me on Twitter. I regularly post information about this subject. Thank you very much.