Event Storming: Build The Right Thing, Right

Savvas Kleanthous at UXDX Europe. Video: https://youtu.be/b_9uba10ZOw

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What this session covers

[00:00:00] 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 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. We're going to be using a 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.

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

The traditional enterprise: silos and long feedback loops

[00:01:39] So first, let's start with the problems. 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 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 problems manifest, and later on, as I mentioned, we're going to be seeing how event storming solves that.

[00:02:20] The first couple of roles that I had as a junior developer were in very traditional enterprise environments. 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 it happened it was through formal channels in written communication. 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.

[00:03:08] And so you can understand that when requirements were to come in, when the project manager maintained that big list of the roadmap for feature deliveries, whenever they requested something, 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 implement the feature, so we went and implemented whatever we needed to implement based on those restrictions of architecture and the requirements. When we finished, we pushed that to the testers, and the testers did their own thing independently. If they found any bugs, then it went back on the cycle.

[00:04:02] So that's quite a 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, in that it results in delays of deliveries. In neither of those two companies was the plan that the project managers did ever accurate, in fact. So not a single release went on time. And even then, the releases 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.

Agile lessons arrive, but the architect stays isolated

[00:04:49] 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 side, so we now started to see the development teams being a bit more cross-functional.

[00:05:51] So that's a better situation, but still we have problems. As most of you have 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 Gantt charts. I don't know how many people have fond memories of Gantt 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 development 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 analysts themselves.

[00:06:53] So 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 for. We have accrual of technical debt, which I forgot to mention earlier. The fact that 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 decisions that are being made are definitely sub-optimal. Not to mention what's the limit of the architect in those companies. That's another discussion and another potential presentation altogether.

Agile won, and brought new problems

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

[00:08:35] Well, it does, but it also kind of introduced different kinds of problems. Not due to Agile itself, so I'm a strong believer in Agile methodologies and Agile principles, in fact. However, the application of those Agile principles, or the interpretation rather of Agile, and the implementation of Agile frameworks, caused the problems that we used to have before to change, but we still have problems.

[00:09:07] So what we're seeing now, the good thing that we're seeing, is that we're finally seeing a breaking of the barrier between the responsibilities. We are now no longer seeing testers as 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.

[00:09:49] But we're also seeing at the same time 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. 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 of any bigger picture planning. So we're not seeing far into the future: what do we need further on? And we're not seeing the breadth of things as well: what other teams are doing, what kind of dependencies exist across those different cross-disciplinary teams and feature-related and journey-related teams. So 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 in, even though a lot of the old problems were solved.

Why event storming

[00:10:49] So we're now in a situation where one asks, why event storming, and does event storming come to actually solve those problems? Event storming fixes all of those problems, maybe not entirely, but it at least contributes very positively to 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 and has that voice.

[00:11:28] Also, 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, without 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.

[00:12:07] Also, a shared understanding. Everybody can understand what problems does our product actually try to address, how things are working in general, and also a visibility on what the other teams are doing. So we're gaining that breadth of information that was lost during that translation from a traditional enterprise to an Agile enterprise, potentially.

What event storming actually is

[00:12:39] So those are the kinds of benefits. But what really is event storming? Event storming is a highly collaborative workshop. When I say highly collaborative, I mean a lot of people working together at the same time to create a model of our system. We're doing that also by focusing on the events. 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, has at different points in time. And we're starting with the events, and from that we're building on top of our understanding and knowledge.

[00:13:22] It's an immensely powerful workshop to run as well. And when I say powerful, I really mean that, because 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.

[00:14:09] What makes it useful is slightly different from the benefits that it exhibits. What makes it useful is that it focuses on those discussions that didn't use to happen. So when we have 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.

[00:15:02] 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 won't even know 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 small changes is actually a very natural way of working in the system.

[00:15:48] Because very often somebody phoned someone, a form was filled, a payment was made, something got shipped. All of these things are things that the subject matter experts know, even if they don't recognize them as events. And recognizing, identifying those changes is 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 understand the whole thing through those domain-specific changes.

[00:16:19] 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 those different approaches. So if we've noticed that something doesn't feel very well, we can throw the stickies on the floor, and then put other stickies on the wall, and just see how that looks and how our subject matter experts feel about that approach.

Why event storming and not another workshop

[00:16:55] So, why event storming specifically and not something else? There are a lot of workshops, there are a lot of tools that we can use. Why event storming and not something else to solve these kinds of problems? I think what makes event storming unique are the first couple of points that I mentioned on this slide. First of all, brainstorming, and secondly, how easy it is to refactor.

[00:17:20] Other workshops tend to focus on getting things accurate and correct. Event storming doesn't really do that. Event storming facilitates brainstorming ideas, trying to see something quickly, see how it looks 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 at how the resulting approach works. If there is a gap there, we have all of the people in the room so that we can discuss and brainstorm on an idea. And usually that results in a very efficient and quick way to come up with a possible solution. Whereas if we had breaks in communication, or at least delays in communication, that could have meant days or even months to come to a solution, or at least something to experiment on.

[00:18:23] The 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 on multiple levels, to exhibit different kinds of benefits and drawbacks. Also, this is one of those workshops where subject matter experts can actively participate. We always had interviews with subject matter experts as one kind of tool to extract the requirements from them. But an event storming session actually puts the subject matter experts in an active role. They no longer just answer questions, they can drive the model that we create, they can drive the brainstorming session.

[00:19:12] And also, as a final point on this, an event storming session breaks down any different kinds of gates in getting to information. By that I mean 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. When I listen 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 aspect of this workshop, that everybody participates directly with everyone else.

Big picture event storming

[00:20:03] So now that we know the whys of event storming and what kinds of benefits they have, it's useful to go to the three major types of event storming. First, and I think the more important one, and it's the one that we're going to be running in the workshop in the next couple of days, is the big picture event storming session.

[00:20:26] A big picture event storming session will look like this, roughly. So again, as I mentioned, 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. 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.

[00:20:59] So that's why generally I strongly suggest that you select a 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 in the building. If you don't have one that is at least 8 to 10 meters long, rent somewhere 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 kind of a drawback for corridors. But on the other hand, it still gives you the breadth of wall space to run. Gardens sometimes. Anyway, from online tools, Miro is a 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. Anyway, moving forward.

[00:22:04] 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 functional departments within the company. So we expect to see something like a story going from the beginning to the end, crossing all those departments, and how things happen from one side to the other, and how the thing progresses.

[00:22:52] And importantly, we have clear visibility here. 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 does the stuff that you do affect your neighbors directly, but also how do 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. It is one of the distinguishing features of 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.

[00:23:48] So who participates in the big picture event storming? 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: it's very common that you will find a small enough number 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, it's that you get buy-in from the higher-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 product as you learn more about the behavior of the system and as you learn more about how your users use the system.

[00:24:44] Subject matter experts are 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.

[00:25:12] 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 of the visibility of how each different team's 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.

[00:25:47] 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 for 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, for example, that is really, really useful.

[00:26:16] As I mentioned before, 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 the 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 what is happening, we tend to put a red sticky there to indicate the hotspot.

[00:26:57] And we probably don't want to discuss implementation of external services, so we hide external services and their behaviors using pink stickies. At the end of the session it's also quite useful to indicate problems and opportunities. 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 quite an easy session to run with a lot of participants.

Process level event storming

[00:27:43] Process level event storming is a zoomed-in version of the big picture with some added moving parts. When I say zoomed-in version: 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 different stickies. We're going to be discussing exactly what they are, but it looks different, is what I'm trying to say.

[00:28:33] 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 those are the boundaries that I'm going to be discussing about.

[00:28:58] 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. 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.

[00:29:27] Who participates in it? The roles of the people that participate are kind of the same, but the number of people participating is certainly smaller. 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 something, the workflow of shipping something else. It really depends on the company, but it's usually much more focused and fewer subject matter experts are going to be participating.

[00:30:05] 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.

[00:30:33] 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 more. We have primarily the introduction of commands and data. 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.

[00:31:08] We also have systems, internal or external. So we're focusing on the workflow. 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 system internally. We abstract that detail behind that big sticky.

[00:31:32] Another important and useful sticky to use is the eventual consistency rule here. This is something that you can basically consider a process manager. So when something happens, then there is an orchestrator that should orchestrate a certain set of actions. 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.

Software design event storming

[00:32:08] 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 as close to the software development, to the implementation, as possible. So this is what you can immediately take and implement.

[00:32:31] And even though it still focuses on events, those events do not necessarily need to be in software. We're talking about events that are describing a certain action. So that can be implemented as a context to a call, as a return value. It really depends, but 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.

[00:33:03] 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 on the team that will be doing the implementation.

[00:33:28] It looks very similar to the process level event storming, with a single addition of the immediate consistency rule. 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. Just to give you an understanding and an example of that, we're talking about rules like a bank account always has to be above zero, or positive. So the balance of an account has to be zero or above. Those are the kinds of rules that will be represented with a yellow sticky, that invariant.

[00:34:10] 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 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 to implementation.

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