Paul Rayner, author of The EventStorming Handbook, brings 36 years of engineering experience, starting with software for Australian mining companies, to the problem of understanding a domain well enough to build for it. He explains why domain knowledge is tacit, invisible, and scattered across silos, then demonstrates event storming step by step: chaotic exploration on a timeline of sticky notes, hotspots for pain points and unknowns, a shared glossary, pivotal events and handoffs, swim lanes, and the people and systems involved in each step. Using a Cinderella warm-up and time-lapse footage of real teams, he shows how the method produces an integrated view of a process and ends with the opportunities the team wants to pursue next.

My background is on the engineering side of things. I've been in software now for 36 years. I'm starting to feel old. My first experience of software development was working for a company in Australia where we would do software for mining companies. Because of that, a lot of my job actually involved flying out to mine sites and spending time with open cut mines, coal mines, gold mines, spending time with geotechnical engineers and geologists, just trying to understand how they did what they did. I remember one particular experience, I grew up in West Australia, which is kind of like the San Diego of Australia geographically and climate wise.

I got on a plane, flew to Adelaide, which is in the middle, and then got on a tiny little 10 seater plane and went on a two hour flight out to the middle of nowhere in South Australia and spent two weeks with a senior geotechnical engineer trying to just unpack his brain of how do you do what you do and how could the software support you in that? Developing a geotechnical module so that we could display, for example, the kind of situation where if you imagine an open-cut coal mine, there are certain weaknesses in the coalface that if you expose them can be not only very costly, but very dangerous because you could expose a weakness that causes a slide and you could kill people. So he did a lot of work modeling that, visualizing that, understanding that. He gave me books to read on geotechnical engineering. I hardly understood anything, but I was able to understand enough to write some software, get some feedback from him, and we were able to build up a geotechnical module for the software we were working on.

I think there's been a recurring theme yesterday and today about the importance of people that are building the software, spending time with the subject matter experts that actually understand the software, and that's across all industries that that's something we really need to be doing more of, especially where we're supporting processes that are not particularly well understood or are complicated. And so that's been kind of my background to all of this. I want to just start with a quote here. I'm not sure if you're familiar with Fred Brooks. If you've used the phrase, there's no silver bullet in software development, you're quoting Fred Brooks. If you've read The Mythical Man-Month, that's Fred Brooks' seminal work, along with his article, No Silver Bullet. He has another book that maybe wasn't as widely read called The Design of Design, and he says, "One of the most striking 20th century developments in the design disciplines, especially in software, is the progressive divorce of the designer from both the implementer and the user," and he talks about the consequences of that.

When we're solving complex, complicated problems, wouldn't it be great to have better methods for actually understanding what it is that we're trying to do? And that's been part of my goal and my career is to try to find better ways as a technical person to engage and understand the world of the people whose problems I'm trying to solve, to let the business domain, the GovTech domain, whatever it is, drive the design of the software instead of the other way around. What we find ourselves in is a situation in a lot of organizations where we are trying to understand this space that we're in, where we've got knowledge within an organization, like knowledge of a business process or something like that, and we're trying to understand that. Part of the difficulty with that knowledge is if we think about what are some of the challenges of that knowledge is a lot of that knowledge is tacit.

So philosopher Michael Polanyi talked about tacit knowledge. It's the knowledge that people have about how they do what they do that they couldn't even explain to you how they do what they do. We need some way to extract that out of people's minds, right? So that's the first challenge with this knowledge is it's tacit. Another related to that is it's also usually invisible.

That knowledge is not only embedded in people's minds and in the way that they go about their work, but it's also embedded in the software as well, whatever systems they're already using that we're trying to understand and integrate with. Whether we're doing greenfield development or brownfield development, we're still integrating with systems, both human and technical. Another thing about this knowledge is it's often fragmented. There was a quote yesterday, "The future is here, but it's not evenly distributed." Knowledge is here, but it's tacit, invisible, and fragmented. It's not evenly distributed either throughout people in organization. If you pick any given business process that you're trying to understand or write software for, there's no one person in organization that knows that entire process. Or to Steve's point, there's no one person that knows the entire value stream. Everyone knows just this little part of it. These are the kinds of challenges, so we need some kind of approach, some kinds of techniques that can help us overcome some of these challenges with the knowledge distribution, and there's no perfect technique. The other thing I want to mention that is kind of related to this and builds on this is at the organizational level, often this knowledge is siloed, right? So if you have a value stream like Steve was talking about, you might have. If you're building a process that is going to support various groups of people, then some people are going to be working more on the backend configuration side of that process. Some people are going to be working on setting up the policies in that system. Some people are going to be implementing operationally those policies and actually doing the bulk of the work, which is usually at scale. And then you're going to have people that are looking at analytics and observability and reports to figure out is the process doing what it should do?

And often those are different silos within an organization. They don't talk to each other. The vast majority of business processes that I've developed software for did not. It wasn't like a group of people got in a room like in Hamilton. There wasn't the room where it happened, where they made these decisions. The process evolved over time and adapted itself to the needs of the people. And so we come in as a software team trying to figure out how does this process work and we're trying to understand that. So as I mentioned, I've been looking for techniques to help deal with this and there are a lot of techniques. Bryon mentioned a number this morning, value stream mapping is one of them, especially in terms of understanding the flow of value through a system. What I'm looking for is some kind of approach that would allow me to get technical people and non-technical people in a room and map out a process using what James Surowiecki calls the wisdom of the crowd, right?

I want to take all those diverse perspectives and be able to produce some kind of integrated view where everyone's perspective is respected, but it's an integrated view that we could actually use to build software. So the technique that I've become very fond of is called event storming, which Bryon already mentioned this morning. And you can think of it as like a software focused sibling to value stream mapping. The idea with event storming is that we map out a process using events where every sticky note that we use is an event that represents something that happened in that process. If you've ever seen how a company, an organization like Pixar does the way they storyboard out their movies, it's a little bit like that is tell the story of the process, tell the story of the process using events. The way that we do this is by asking each person, just think of this process, think of this business process and whatever you can remember that happens in this process, just take a few minutes and write that on the sticky notes as if you were telling the story.

Then what we'll do is we'll put all those up and arrange them in a timeline on a wall where we've got all these sticky notes and there's going to be duplicates, there's going to be some mess, but the initial thing is to do this, what we might call chaotic exploration to get everyone's perspective up on the wall and then we can figure out how to reconcile all of these into a story because we're very good. We're wired to tell stories. We're wired to tell stories and being able to map out a process like this is a way of being able to do that. We would end up with something that looks like this on the wall and it could be done virtually as well. I've done a lot of this virtually.

All right. So here's an example of an event storm. Can anyone guess what story? This is not a business process, but based on what you're seeing up there, first person to call it out, you don't win a prize, but what is this the story of? Cinderella. Cinderella, thank you. I'll often use this exercise as a warmup for people to expose them to event storming. I'll just think of the story as Cinderella and what are some things that happen? This is just the first part of the story, but just do this as a warmup. I'll often say it's a fairy story, so what's the last event in the story? Most people know it's they lived happily ever after. Then I usually make some kind of joke about, wouldn't it be great if all our software projects and processes ended the same way? Then it starts with the once upon a time.

There's all kinds of funny things people have put here. But this would be the first pass at mapping it out. And then from there, we do a second pass where we clean it up. So here's an actual team doing the Cinderella exercise. This was in June.

And I'm just explaining, here's how it works. We've got once upon a time at one end and on the left and happily ever after on the right. And then I give them a few minutes to write down their business process. What are the events in your business process that you want to map? Give them a few moments to do that. And they start mapping out their process. And we very quickly go from nothing up on the wall to an actual fun, collaborative way of being able to do this. And then we do a second pass where we actually start tidying it up. We look for duplicates. We talk about the differences in language. Some people are calling a certain event one thing and some people are calling it something else. Well, when you have a diverse group of people, that's really important because people have differences in language. They have differences in understanding of this process. And so being able to talk that through can be really, really significant. So this is the warmup, this is the chaotic exploration. You can see that it's still a little messy down at the front of the process, but the back of the process is stabilized somewhat. And over the course of the workshop, the group are able to start converging on what is our actual understanding of this process and how does it work together using just events. So this is what we'll be doing in the workshop tomorrow, but you can see that we can very quickly go from nothing on a wall or nothing on a collaborative whiteboard online to allowing people to express their own events and being able to show that across here. Now, it's not just orange stickies. What we use also as well, there's a color grammar for this.

So we use pink stickies or red stickies to indicate what we might call hotspots, like pain points in the process. So it could also be what's an assumption that we're making or what's something we don't know. So many projects are either hamstrung by analysis paralysis on the one hand, or the other extreme is just, we don't know what the answer is, but we're just going to come up with something anyway of just let's just move forward instead of taking the time to actually understand something and be able to dig into that with the person that might know the answers. So the pink stickies function a little bit. If you've done any facilitation, the hotspots function like a parking lot that is embedded in the process where you've got unanswered questions. And so it points to what are possible next steps? What are areas where we maybe don't have the insights we're looking for?

The other thing you'll notice up here is we've got another sticky note color. We're using blue sticky notes to represent a glossary that we're building up. So as acronyms, and I know GovTech has very few acronyms, so this is not going to be something you probably use, but if there are acronyms, if there are terms, if there are things in the domain that need to be understood, then there's a sticky note color for that so that we can agree on this terminology.

Now, one of the things that tends to happen in this type of process, and rather than sort of give you a theoretical talk about event storming, I'm really trying to show you more by example with the idea that you could go back to your office and experiment with this technique just with events. The next thing that we can do is in terms of telling the story of the process is when we have a timeline of events like this, and maybe we have some hotspots on here, and the hotspots, like I said, are really powerful because it allows us to be able to see where are the areas that maybe we don't understand as well or where are kind of the problem areas. So if you have a timeline that kind of looks like this, you already know without even knowing the timeline that there's certain areas that maybe we're not as confident about how the process works.

So another thing that we can then do is we can start to look at that process and say, where are what we might call the more important events, the pivotal events in this process? So one of the things that I often say is where are the handoffs in this process from one group to another? Because it's usually the handoffs from one group to another where the problems happen. Where does the story change? So what we actually do is we mark those on here.

So we indicate which of the events are the pivotal events in this process. And from there, then we start having conversations around, okay, so now we've got these pivotal events in the process where there are potentially handoffs. All events are important, but some are more important than others. Some are more pivotal than others. Then I mentioned we're looking for handoffs, we're looking for changes in the story, changes in actor, that type of thing, is we can start to actually label these different parts of the story now. So we can say, okay, well this first part here, this is where we do this activity and that's what the business calls it. And then we've got this part here and this part here and this part here. So we're building up emergent structure for the process and we're letting the people in the room define that. And we might say, well, when we get down to here, what we actually have is a couple of parallel paths going on. And so the group can actually map that out as well and say, okay, so we've got some parallel paths. We've got maybe alternatives going on here in our flow. And what this allows us to do is to start making sense of what usually feels like a bit of a big mess because the real world is messy.

So you can see this is what the group is doing now. So you can see they're using very cheap painters tape from Home Depot and they're mapping out the pivotal events. So identify a pivotal event, peel it off the wall, put the tape in, go from there. And then also where is the branches in the flow that becomes the swim lanes, the horizontal sections. So what you can do is take this business complexity that I said is invisible and tacit and siloed, get the right people in the room and be able to actually build up a shared understanding with shared language. And not only that, but identify where are the things that we're unsure of, what are the things that we need to do further investigation on and be able to do this sense making exercise. Now I'm showing here a large group of people doing this, but for an as is kind of process, but you could also do this for a small group, like four or five people.

You could have a team that wants to just map out what they're doing in the next couple of months. Kent Beck yesterday talked about features and futures. So you can think of this as a way of stepping back from what we're doing and doing some sense making when there feels like there's fog and a lack of clarity about what the team needs to do going forward and create more futures for yourself.

Now, the next thing we want to layer on is we want what you might call the sociotechnical landscape. That's just a fancy way of saying how are people involved in this process and what software systems are involved in this process? Because after all, this is a software design, software modeling process to help a team understand what to build. So what we have here is we're using little yellow sticky notes to indicate people doing things and the group is mapping that out. And then they're writing the names of systems, APIs, third party systems, SaaS solutions that are involved in this process, maybe pass like platforms that are involved and mapping those out as well across here. This allows the team to have not only a good understanding of who is the process serving, who's involved in this process, who's actually driving it from a people perspective, but have conversations about what are their goals, what are their motivations, what are the friction points for them, how do they interact with each other?

And then what integrations do we need to do? Where are areas of this process where there's a lot of legacy stuff that we have to take account of and being able to talk that through. So the other thing we're doing here is once we've mapped this out, there's a lot of other things that I could talk about in terms of event storming, but we then have people in the room take turns of walking through and telling the story because usually when you're building this, you're focused on just your area maybe that you understand. So we actually have people in this workshop format go through and what I usually do is I say, "I'm going to lead this off because nobody knows less about this process than me as the facilitator. And I'm just going to read the sticky notes and we'll use this as a way of sanity checking the process. But also this is where massive learning happens as everyone sees how all the pieces tie together." So you can see we're just walking through telling the story, reading the sticky notes, we're fixing things as we go to really be able to set the team up for success, to understand what are we building? Why are we building it? Who are we trying to serve? And then the pink stickies become what are the next steps coming out of this? Do we need to do some lower level visualization? Do we need to dig into certain areas that maybe aren't well understood? Or are there not a lot of questions? And so let's move to implementation. What's fascinating to me is I've taken photographs of event storming timelines and I've put them into agents like Claude Code and so on. And agents have a really good understanding of event storming apparently. We talk a lot about the importance of context engineering and feeding your context with rich information. So being able to imagine when you're implementing the software, being able to give your agent a glossary, a contextual glossary, a map of the process, the swim lanes and all that, knowing that it's not perfect, but it's a way of being able to help everyone understand what's going on. So it's really about this shared view.

So you can see here a few people talking about just one part of the process. I've showed you a lot of time lapses to try to give you a sense of what this might feel like with a group. But in terms of the actual workshop, what it does is it engenders these kind of deep conversations about what is the sequence of these events? What are the actual dependencies? Because by the time we get to software development and actually coding up the features, if we don't understand the process, then there's a good chance that we'll actually not hit the mark in terms of what we're trying to deliver.

There's a variety of formats for this. So this one where we do a large group, one of the things that I like to end with is asking people to say, okay, where do we want to go next with this? So what we do here is I'm asking everyone, map out the opportunities. Where do you see the ways that this process could be improved? So this is focusing on an as is process, but being able to identify where are the areas where we should actually invest effort in further discovery? Where are we ready to go and do some development work, that type of thing. So basically figuring out the next steps for this.

And this is a quote from somebody that took event storming. I ran a workshop at their organization, at Heather's organization, and she ran with that and ran many, many workshops within her organization. So when software development teams started getting stuck around certain things or starting to feel like they didn't really understand what they were working on and had that clarity, then Heather would say, "Okay, I'm going to teach you how to do this technique." It says in a day what might have taken weeks, but I've done these types of sessions with a team in an hour, 90 minutes. Virtually, I've had people from all over the world do this. So I'm really trying to just give you a sense of what this feels like, how it can help. I'm going to be around for the rest of today and I'll be running the workshop tomorrow.

So we'd love to have you involved in that. And I just really appreciate your time and your interest and I hope you enjoy the rest of the conference. So thank you.