Jakson 271: EventStorming with Paul Rayner täydellinen litterointi

then the customer receives, or maybe it's a shipping label. The customer receives the shipping label and then they put the items in the package with the shipping label and they return it. And then there would be a bunch of events that the merchant would have to take care of. So the merchant would have to receive that package and then probably have to update the system to record that it's been returned. And then, I imagine there would be processing another order, or something like that. A key event in there might be something like sending out the shipping label and the customer receiving the shipping label because that's a point where the responsibility transfers from the merchant, who is preparing the shipping label and dispatching that, to the customer that's actually receiving it and then having to do something. That's just one, I guess, small example of you can use that to divide that story up into what you might think of as chapters where there's different responsibilities and changes in the narrative. Part of that maybe layering in sticky notes that represent who's doing the work. Like who's the actor, whether it's the merchant, or the customer, and then layering in other information, like the systems that are involved in that such as maybe there's email as a system, maybe there's the actual e-commerce platform, a payment gateway, these kinds of things could be reflected and so on, like there's – [overtalk] JESSICA: Probably integration with the shipper. PAUL: Integration with the shipper, right. So potentially, if you're designing this, you would have some kind of event to go out to the shipper to then know to actually pick up the package and that type of thing. And then once the package is actually delivered back to the merchant, then there would be some kind of event letting the merchant know. It's very hard to describe because I'm trying to picture this in my mind, which is an inherently visual thing. It's probably not that interesting to hear me describing something that's usually done on some kind of either mirror board, like some kind of electronic space, or on a piece of butcher's paper, or – [overtalk] DAMIEN: Something with a lot of sticky notes. PAUL: Something with a lot of sticky notes, right. DAMIEN: Which, I believe for our American listeners, sticky notes are the little square pieces of brightly colored paper with self-adhesive strip on the back. PAUL: Yeah. The stickies. DAMIEN: Stickies. [chuckles] I have a question about this process. I've been involved in very similar processes and it sounds incredibly useful. But as you describe it, one of the concerns I have is how do you avoid getting over specific, or over described? Like you can describe systems until you're talking about the particles in the sun, how do you know when to stop? PAUL: So I think there's a couple of things. Number one is at the start of whatever kind of this activity, this EventStorming is laying out what's the goal? What are we trying

to accomplish in terms of the process? With returns, for example, it would be maybe from this event to this event, we're trying to map out what that process looks like and you start with what you might call the happy path. What does it look like when everything goes well? And then you can use pink stickies to represent alternate paths, or things going wrong and capture those. If they're not tied back to this goal, then you can say, “Okay, I think we've got enough level of detail here.” The other thing is time boxing is saying, “Okay, well, we've only got half an hour, or we've only got an hour so let's see how much we can do in that time period,” and then at the end of that, if you still have a lot of questions, then you can – or you feel like, “Oh, we need to dig into some of these areas more.” Then you could schedule a follow up session to dig into that a little bit more. So it's a combination of the people that are participating in this deciding how much level of detail they want to go down to. What I find is it typically is something that as you're going through the activity, you start to see. “Oh, maybe this is too far down in the weeds versus this is the right level.” As a facilitator, I don't typically prescribe that ahead of time, because it's much easier to add sticky notes and then talk about them than it is to have a conversation when there's nothing visualized. I like to visualize it first and lay it out and then it's very easy to say, “Oh, well, this looks like too much detail. So we'll just put a placeholder for that and not worry about out it right now.” It's a little bit of the facilitation technique of having a parking lot where you can say, “Okay, this is a good topic, but maybe we don't need to get down in that right now. Maybe let's refocus back on what it is that we're trying to accomplish.” JESSICA: So there's some regulation that happens naturally during the meeting, during interactions and you can have that regulation in the context of the visual representation, which is the EventStorming, the long row of stickies from one event to the other. PAUL: Right, the timeline that you're building up. So it's a little bit in my mind, I watched last year, I think it was on Netflix. There was a documentary about Pixar and how they do their storyboarding process for their movies and it is exactly that. They storyboard out the movie and iterate over that again and again and again telling that story. What's powerful about that is it's a visual medium so you have someone that is sketching out the main beats of the story and then they're talking it through. Not to say that EventStorming is at that level of rigor, but it has that kind of feel to it of we're laying out these events to tell the story and then we're talking through the story and seeing what we've missed and where we need to add more detail, maybe where we've added too much detail. And then like you said, Jess, there's a certain amount of self-regulation in there in terms of, do we have enough time to go down into this? Is this important right now? JESSICA: And I imagine that when I have questions that go further into detail than we were able to go in the meeting, if I've been in that EventStorming session, I know who to ask. PAUL: That's the idea, yeah. So the pink stickies that we said represent questions, what I like about those is, well, several things. Number one, it democratizes the idea that it's okay to ask questions, which I think is a really powerful technique. I think there's a tendency in meetings for some people to hold back and other people to do all the talking. We've all experienced that. What this tries to do is to democratize that and actually make it not only okay and not only accepted, but encourage that you're expected to ask questions and you're expected to put these sticky notes on here when there's things that you don't understand. JESSICA: Putting the questions on a sticky note, along with the events, the actors, and the things that we do know go on sticky notes, the questions also go on sticky notes. All of these are contributions. PAUL: Exactly. They value contributions and what I love about that is that even people that are new to this process, it's a way for them to ask questions in a way that is kind of friendly to them. I've seen this work really well, for example, with onboarding new team members and also, it encourages the idea that we have different areas of expertise. So in any given process, or any business story, whatever you want to characterize it as, some people are going to know more about some parts of it than others. What typically happens is nobody knows the whole story, but when we work together, we can actually build up an approximation of that whole story and help each other fill in the gaps. So you may have the person that's more on the business, or the product side explaining some terminology. You can capture those explanations on sticky notes as a glossary that you're building up as you go. You can have engineers asking questions about the sequence of events in terms of well, does this one come before that one? And then the other thing that's nice about the questions is it actually as you're going, it's mapping out your ignorance and I see that as a positive thing. JESSICA: The known unknowns. PAUL: Known unknowns. It takes unknown unknowns, which the kind of elephant in the room, and at least gets them up as known unknowns that you can then have a conversation around. Because there's often this situation of a question that somebody's afraid to ask and maybe they're new to the team, or maybe they're just not comfortable asking that type of question. But it gives you actually a map of that ignorance so you can kind of see oh, there's this whole area here that just has a bunch of pink stickies. So that's probably not an area we're ready to work on and we should prioritize. Actually, if this is an area that we need to be working on soon, we

should prioritize getting answers to these questions by maybe we need to do a proof of concept, or some UX work, or maybe some kind of prototyping around this area, or like you said, Jess, maybe the person that knows the answers to these questions is just not in this session right now and so, we need to follow up with them, get whatever answers we need, and then come back and revisit things. JESSICA: So you identify areas of risk. PAUL: Yes. Areas of risk, both from a product perspective and also from a technical perspective as well. DAMIEN: So what does it take to have one of these events, or to facilitate one of these events? How do you know when you're ready and you can do it? PAUL: So I've done EventStorming [chuckles] as a conference activity in a hallway with sticky notes and we say, “Okay, let's as a little bit of an icebreaker here –” I usually you do the story of Cinderella. “Let’s pick the Disney story of Cinderella and we'll just EventStorm this out. Just everyone, here are some orange sticky notes and a Sharpie, just write down some things that you remember happening in that story,” and then everyone writes a few. We post it up on the hallway wall and then we sequence them as a timeline and then we can basically build up that story in about 5, or 10 minutes from scratch. With a business process, it's not that different. It's like, okay, we're going to do returns, or something like that and if people are already familiar with the technique, then just give them a minute, or so to think of some things that they know that would happen in that process. And then they do that individually and then we just post them up on the timeline and then sequence them as a group and it can happen really quickly. And then everything from there is refinement. Iteration and refinement over what you've put up as that initial skeleton. DAMIEN: Do you ever find that a team comes back a week, or a day, or a month later and goes, “Oh, there is this big gap in our narrative because nobody in this room understood the warehouse needed to be reordered in order to send this thing down”? PAUL: Oh, for sure. Sometimes it's big gaps. Sometimes it's a huge cluster of pink sticky notes that represents an area where there's just a lot of risk and unknowns that the team maybe hasn't thought about all that much. Like you said, it could be there’s this third-party thing that it wasn't until everyone got in a room and kind of started to map it out, that they realized that there was this gap in their knowledge. JESSICA: Yeah. Although, you could completely miss it if there's nobody from the warehouse in the room and nobody has any idea that you need to tell the warehouse to expect this return. PAUL: Right and so, part of that is putting a little bit of thought into who would need to be part of this and in a certain way, playing devil's advocate in terms of what don't we know, what haven't we thought of. So it encourages that sense of curiosity with this and it's a little bit different from – Some of the listeners maybe have experienced user story mapping and other techniques like that. Those tend to be focused on understanding a process, but they're very much geared towards okay, how do we then figure out how we're going to code up this feature and how do we slice it up into stories and prioritize that. So it's similar in terms of sticky notes, but the emphasis in EventStorming is more on understanding together, the problem that we're trying to address from a business perspective. JESSICA: Knowledge pulling. PAUL: Yeah. Knowledge pulling, knowledge distillation, those types of idea years, and that kind of mindset. So not just jumping straight to code, but trying to get a little bit of a shared understanding of what all is the thing that we're trying to actually work on here. JESSICA: Eric Evans calls it knowledge crunching. PAUL: Yes, Eric called it knowledge crunching. DAMIEN: I love that phrase, that shared understanding. That's what we, as product teams, are generating is a shared understanding both, captured in our documentation, in our code, and before that, I guess on large sheets of butcher paper. [laughs] PAUL: Well, and it could be a quick exercise of okay, we're going to be working on some new feature and let's just spend 15 minutes just mapping it out to get a sense of, are we on the same page with this? JESSICA: Right, because sometimes it's not even about we think we need to know something, it's do we know enough? Let's find out. PAUL: Right. JESSICA: And is that knowledge shared among us? PAUL: Right, and maybe exposing, like it could be as simple as slightly different terminology, or slightly different understanding of terminology between people that can have a big impact in terms of that. I was teaching a workshop last night where we were talking about this, where somebody had written the event. So there was a repair process that a third-party repair company would handle and then the event that closed that process off, they called case closed. So then the question becomes well, what does case closed mean? Because the word case – [overtalk] JESSICA: [laughs] It’s like what's the definition of done? PAUL: Right, exactly. [laughter] Because that word case didn't show up anywhere earlier in the process. So is this like a new concept? Because the thing that kicks off the process is repair purchase order created and at the end of the process, it's said case closed. So then the question becomes well, is case closed really, is that a new concept that we actually need to implement here? Or is this another way of saying that we are getting a copy of that repair purchase order back that and it's been updated with details about what the repair involved? Or maybe it's something like repair purchase order closed. So it's kind of forcing us to clarify terminology, which may seem a little bit pedantic, but that's what's going to end up in the code. If you can get some of those things

exposed a little earlier before you actually jump to code and get people on the same page and surface any sort of differences in terminology and misunderstandings, I think that can be super helpful for everyone. JESSICA: Yeah. Some people say it's just semantics. Semantics’ meaning, its only meaning, this is only about out what this step actually means because when you put it in the code, the code is crystal clear. It is going to do exactly what it does and whether that clarity matches the shared understanding that we think we have oh, that's the difference between a bug and a working system. DAMIEN: [laughs] That's beautiful. It's only meaning. [laughs] JESSICA: Right? Yeah. But this is what makes programming hard is that pedanticness. The computer is the ultimate pedant. DAMIEN: Pedant. You're going to be pedantic about it. [laughter] PAUL: I see what you did there. [laughter] DAMIEN: And that is the occupation, right? That is what we do is look at and create systems and then make them precise. JESSICA: Yeah. DAMIEN: In a way that actually well, is precise. [laughs] JESSICA: Right, and the power of our human language is that it's not precise, that it allows for ambiguity, and therefore, a much broader range of meaning. But as developers, it's our job to be precise. We have to be precise to the computers. It helps tremendously to be precise with each other. DAMIEN: Yeah, and I think that's actually the power of human cognition is that it's not precise. We are very, very fuzzy machines and anyone who tries to pretend otherwise will be greatly disappointed. Ask me how I know. [laughter] PAUL: Well, and I think what I'm trying to do with something like EventStorming is to embrace the fuzziness, is to say that that's actually an asset and we want to embrace that and expose that fuzziness, that messiness. Because the processes we have and work with are often inherently complex. We are trying to provide some visual representation of that so we can actually get our head around, or our minds around the language complexities, the meanings, and drive in a little bit to that meaning. JESSICA: So when the sticky notes pile on top of each other, that's a feature. PAUL: It is. Going back to that example I was just talking about, let's say, there's a bunch of, like we do the initial part of this for a minute, or so where people are creating sticky notes and let's say, we end up with four, or five sticky notes written by different people on top of each other that end up on the timeline that all say pretty much the same thing with slight variations. JESSICA: Let’s say, case closed, request closed. PAUL: Case closed, repair purchase order closed, repair purchase order updated, repair purchase order sent. So from a meaning perspective, I look at that and I say, “That's gold in terms of information,” because that's showing us that there's a richness here. Firstly, that's a very memorable thing that's happening in the timeline – [overtalk] JESSICA: Oh and it has multiple things. PAUL: That maybe means it's a key event. Right, and then what is the meaning? Are these the same things? Are they different things? Maybe we don't have enough time in that session to dig into that, but if we're going to implement something around that, or work with something around that, then we’re going to at some point need some clarity around the language, the terminology, and what these concepts mean. Also, the sequence as well, because it might be that there's actually multiple events being expressed there that need to be teased apart. DAMIEN: You used this phrase a couple times, “key event,” and since you've used it a couple times, I think it might be key. [laughter] Can you tell us a little bit about what a key event is? What makes something a key event? PAUL: Yeah, the example I like to use is from the Cinderella story. So if you think about the story of Cinderella, one of the things, when people are doing that as an icebreaker, they always end up being multiple copies of the event that usually is something like shoe lost, or slipper lost, or glass slipper lost. There's something about that event that makes it memorable, firstly and then there's something about that event that makes it pivotal in the story. For those that are not familiar with the story [chuckles]—I am because I've EventStormed this thing maybe a hundred times—but there's this part. Another key event is the fairy godmother showing up and doing the magic at the start and she actually describes a business policy. She says, “The magic is going to run out at midnight,” and like all business policies, it's vague [laughter] and it’s unclear as to what it means because – [overtalk] JESSICA: The carriage disappears, the dress disappears, but not the slipper that fell off. PAUL: Exactly. There's this exception that for some bizarre reason, to move the plot forward, the slipper stays. But then the definition of midnight is very hazy because what she's actually describing, in software terms, is a long running process of the clock banging 12 times, which is what midnight means is the time between the first and the twelfth and during that time, the magic is slowly unraveling. JESSICA: So midnight is a duration, not an instant. PAUL: Exactly. Yes, it's a process, not an event. So coming back to the question that Damien asked about key events. That slipper being lost is a key event in that story, I think because it actually is a shift in narrative. Up until that point in the story, it's the story of Cinderella and then after that, once the slipper is lost, it becomes the story of the prince looking for Cinderella. And then at the end, you get the day tomorrow, the stuff that happens with that slipper at the end of the story. Another key event would be like the fairy godmother showing up and doing the magic. DAMIEN: [chuckles] It seems like these are necessary events, right? If the slipper is not lost, if the fairy godmother doesn't

do magic, you don't have the story of Cinderella. PAUL: Right. These are narrative turns, right? DAMIEN: Yeah. PAUL: These are points of the story shifts and so, key events can sometimes be a narrative shift where it's driving the story forward in a business process. Something like, let's say, you're working on an e-commerce system, like order submitted is a key event because you are adding items to a shopping cart and then at some point, you make a decision to submit the order and then at that point, it transitions from order being a draft thing that is in a state of flux to it actually becomes essentially immutable and gets passed over to fulfilment. So there's a shift in responsibility and actor between these two as well just like between Cinderella and the prince. JESSICA: A shift in who is driving the story forward. PAUL: Right. Yeah. So it's who is driving the story forward. So these key events often function as a shift in actor, a shift in who's driving the story forward, or who has responsibility. They also often indicate a handoff because of that from one group to another in an organization. Something like a sales process that terminates in contract signed. That key event is also the goal of the sales process. The goal is to get to contract signed and then once that happens, there's usually a transition to say, an onboarding group that actually onboards the new customer in the case of a sales process for a new customer, or in e-commerce, it would be the fulfillment part, the warehousing part that Jess was talking about earlier. That's actually responsible for the fulfillment piece, which is they take that order, they create a package, they put all the items in the package, create the shipping label, and ship it out to the customer. JESSICA: And in domain-driven design, you talked about the shift from order being a fluid thing that's changing as people add stuff to their cart to order being immutable. The word order has different meanings for the web site where you're buying stuff and the fulfillment system, there's a shift in that term. PAUL: Right, and that often happens around a key event, or a pivotal event is that there's a shift from one, you might think of it as context, or language over to another. So preorder submission, it’s functioning as a draft order, but what it's actually typically called is a shopping cart and a shopping cart is not the same as an order. It's a great metaphor because there is no physical cart, but we all know what that means as a metaphor. A shopping cart is a completely different metaphor from an order, but we're able to understand that thread of continuity between I have this interactive process of taking items, or products, putting them in the shopping cart, or out again. And then at some point that shopping cart, which is functioning as a draft order, actually it becomes an order that has been submitted and then it gets – [overtalk] DAMIEN: Yeah, the metaphor doesn't really work until that

transition. You have a shopping cart and then you click purchase and now what? [laughs] You're not going to the register and ringing it up, that doesn't make any sense. [chuckles] The metaphor kind of has to end there. JESSICA: You’re not leaving the cart in the corral in the parking lot. [laughter] PAUL: Well, I think what they're trying to do is when you think about going through the purchase process at a store, you take your items up in the shopping cart and then at that point, you transition into a financial transaction that has to occur that then if you were at a big box electronic store, or something, eventually, you would make the payment. You would submit payment. That would be the key events and that payment is accepted and then you receive a receipt, which is kind of the in-person version of a record of your order that you've made because you have to bring the receipt back. DAMIEN: It sort of works if the thing you're putting in the shopping cart are those little cards. When they don't want to put things on the shelf, they have a card, you pick it up, and you take it to register. They ring it up, they give you a receipt, and hopefully, the thing shows up in the mail someday, or someone goes to the warehouse and goes gets it. PAUL: We've all done that. [chuckles] Sometimes it shows up. Sometimes it doesn't. JESSICA: That's an interesting point that at key events, there can be a shift in metaphor. PAUL: Yes. Often, there is. So for example, I mentioned earlier, a sales process ending in a contract and then once the contract is signed, the team – let's say, you're signing on a new customer, for a SaaS service, or something like that. Once they've signed the contract, the conversation isn't really about the contract anymore. It's about what do we need to do to onboard this customer. Up until that point, the emphasis is maybe on payment, legal disclosures, and things like that. But then the focus shifts after the contract is signed to more of an operational focus of how do we get the data in, how do we set up their accounts correctly, that type of thing. JESSICA: The contract is an input to that process. PAUL: Yes. JESSICA: Whereas, it was the output, the big goal of the sales process. PAUL: Yes, exactly. So these key events also function from a systems perspective, when you think about moving this to code that event then becomes almost like a message potentially. Could be implemented as say, a message that's being passed from the sales system through to the onboarding system, or something like that. So it functions as the integration point between those two, where the language has to be translated from one context to another. JESSICA: And it's an integration point we can define carefully so that makes it a strong boundary and a good place to divide the system. DAMIEN: Nice. PAUL: Right. So that's where it starts to connect to some of the things that people really care about these days in terms of system decomposition and things like that. Because you can start thinking about based on a process view of this, based on a behavior view of this, if we treat these key events as potential emergent boundaries in a process, like we've been describing, that we discover through mapping out the process, then that can give us some clues as to hmm maybe these boundaries don't exist in the system right now, but they could. These could be places where we start to tease things apart. JESSICA: Right. Where you start breaking out separate services and then when you get down to the user story level, the user stories expect a consistent language within themselves. You're not going to go from cart to return purchase in a case. PAUL: [laughs] Right. JESSICA: In a single user story. User stories are smaller scope and work within a single language. PAUL: Right and so, I think the connection there in my mind is user stories have to be written in some kind of language, within some language context and mapping out the process can help you understand where you are in that context and then also understand, like if you think about a process that maybe has a sales part of the process and then an onboarding part, it'll often be the case that there's different development teams that are focusing on different parts of that process. So it provides a way of them seeing what their integration point is and what might need to happen across that integration point. If they were to either integrate to different systems, or if they're trying to tease apart an existing system. To use Michael Feathers’ term, what might be a “scene” that we could put in here that would allow us to start teasing these things apart. And doing it with the knowledge of the product people that are part of the visualization, too is that this isn't something typically that engineers do exclusively from a technical perspective. The idea with EventStorming is you are also bringing in other perspectives like product, business, stakeholders, and anyone that might have more of that business perspective in terms of what the goals of the process are and what the steps are in the process. MID-ROLL: And now a quick word from our sponsor. I hear people say the VPNs have a reputation for slowing down your internet speed, but not with NordVPN, because it's the fastest VPN in the world. I don't have to sacrifice internet speed for better security. With NordVPN, my internet traffic is routed through a secure encrypted tunnel, which protects my data and privacy. I can also have it on up to six devices like my laptop, phone, TV, iPad—all my devices are protected. Grab your exclusive NordVPN deal by going to nordvpn.com/gtc, or use the code GTC to get a huge discount on your NordVPN plan plus one additional month for free. Plus, a bonus gift! It's completely risk-free with Nord’s 30-day money back guarantee. JESSICA: As a developer, it's so important to understand what those goals are, because that lets us make good decisions when

we're down in the weeds and getting super precise. PAUL: Right, I think so. I think often, I see teams that are implementing stories, but not really understanding the why behind that in terms of maybe they get here's the functionality on delivering and how that fits into the system. But like I talked about before, when you're driving a process towards a key event, that becomes the goal of that subprocess. So the question then becomes how does the functionality that I'm going to implement that's described in this user story actually move people towards that goal and maybe there's a better way of implementing it to actually get them there. DAMIEN: Yeah, it's always important to keep that in mind, because there's always going to be ambiguity until you have a running system, or ran system, honestly. JESSICA: Yeah! DAMIEN: There's always going to be ambiguity, which it is our job as people writing code to manage and we need to know. Nobody's going to tell us exactly what's going to happen because that's our job. PAUL: Right. JESSICA: It's like if the developer had a user story that Cinderella’s slipper fell off, but they do didn't realize that the goal of that was that the prince picked it up, then they might be like, “Oh, slipper broke. That's fine.” PAUL: Yeah. JESSICA: It’s off the foot. Check the box. PAUL: Let's create a glass slipper factory implementer object [laughter] so that we can just create more of those. JESSICA: Oh, yeah. What, you wanted a method slip off in one piece? You didn't say that. I've created crush! PAUL: Right. [laughter] Yeah. So I think sometimes there's this potential to get lost in the weeds of the everyday development work that is happening and I like to tie it back to what is the actual story that we're supporting. And then sometimes what people think of as exception cases, like an example might be going back to that merchant return example is what if they issue the shipper label, but the buyer never receives it. We may say, “Well, that's never going to happen,” or “That's unlikely.” But visualizing that case, you may say, “That's actually a strong possibility. How do we handle that case and bake that into the design so that it actually reflects what we're trying to do?” JESSICA: And then you make an event that just triggers two weeks later that says, “Check whether customer received label.” PAUL: Yes, exactly. One thing you can do as well is like – so that's one possibility of solving it. The idea what EventStorming can let you do is say, “Well, that's one way of doing it. Are there any other options in terms of how we could handle this, let's visualize.” With any exception case, or something, you could say, “Well, let's try solving this a few different ways. Just quickly come up with some different ideas and then we can pull the best of those ideas into that.” So the idea when you're modeling is to say, “Okay, well, there's probably more than one way to address this. So maybe let's get a few ideas

on the table and then pick the best out of these.” JESSICA: Or address it at multiple levels. PAUL: Yes. JESSICA: A fallback for the entire process is customer contact support again. PAUL: Right, and that may be the simple answer in that kind of case. What we're trying to do, though is to visualize that case as an option and then talk about it, have a structured conversation around it, say, “Well, how would we handle that?” Which I think from a product management perspective is a key thing to do is to engage the engineers in saying, “Well, what are some different ways that we could handle this and solve this?” If you have people that are doing responsibility primarily for testing in that, then having them weigh in on, well, how would we test this? What kind of test cases might we need to handle for this? So it's getting – [overtalk] JESSICA: How will we know it worked? PAUL: Different perspectives and opinions on the table earlier rather than later. JESSICA: And it's cheap. It's cheap, people. It's a couple hours and a lot of post-its. You can even buy the generic post-its. We went to Office Depot yesterday, it's $10 for 5 little Post-it pads, [laughter] or 25 Office Depot brand post-it pads. They don't have to stay on the wall very long; the cheap ones will work. PAUL: [laughs] So those all work and then it depends if you have shares in 3M, I guess, with you. [laughter] Or Office Depot, depending which road you want to go down. [laughter] JESSICA: Or if you really care about that shade of pale purple, which I do. PAUL: Right. I mean, what's been fascinating to me is in the last 2 years with switching to remote work and that is so much of, 95% of the EventStorming I do these days is on a collaborative whiteboard tool like Miro, or MURAL, which I don't know why those two product names are almost exactly the same. But then it's even cheaper because you can sign up for a free account, invite a few people, and then just start adding sticky notes to some virtual whiteboard and do it from home. There's a bunch of things that you can do on tool like that with copy pasting, moving groups of sticky notes around, rearranging things, and ordering things much – [overtalk] JESSICA: And you never run out of wall. PAUL: Yeah. The idea with the butcher’s paper in a physical workshop, in-person workshop is you're trying to create a sense of unending modeling space that you can use. That you get for free when you use online collaborative whiteboarding tool. It’s just there out of – [overtalk] JESSICA: And you can zoom in. PAUL: And you zoom in and out. Yeah. There's a – [overtalk] JESSICA: Stickies on your stickies on your stickies. [laughter] I'm not necessarily recommending that, but you can do it. PAUL: Right. The group I was working with last night, they'd actually gone to town using Miro emojis. They had something bad happen in the project and they've got the horror emoji [laughter] and then they've got all kinds of and then copy pasting images off the internet for things. JESSICA: Nice. PAUL: So yeah, can make it even more fun. JESSICA: Okay. So it's less physical, but in a lot of ways it can be more expressive, PAUL: I think so. More expressive and just as engaging and it can break down the geographical barriers. I've done sessions where we've had people simultaneously spread in multiple occasions across the US and Europe in the same session, all participating in real-time. If you're doing it remote, I like to keep it short. So maybe we do like a 2-hour session with a 10- or 15-minute break in the middle, because you're trying to manage people's energy and keep them focused and it's hard to do that when you just keep going. MANDY: I kind of want to talk a little bit about facilitation and how you facilitate these kind of workshops and what you do, engage people and keep them interested. PAUL: Yeah. So I think that it depends a little bit on the level of detail we're working at. If it's at the level of a few team members trying to figure out a feature, then it can be very informal. Not a lot of facilitation required. Let's just write down what the goal is and then go through the process of brainstorming a few stickies, laying it out, and then sequencing it as a timeline, adding questions. It doesn't require a lot of facilitation hand. I think the key thing is just making sure that people are writing down their questions and that it's time boxed. So quitting while people are still interested and then [laughter] at the end, before you finish, having a little bit of a conversation around what might the next steps be. Like what did we learn? You could do a couple of minutes retrospective, add a sticky note for something you learned in this session, and then what do you see as our next steps and then move on from there with whatever action items come out of that. So that one doesn't require, I think a lot of facilitation and people can get up and running with that pretty quickly. I also facilitate workshops that are a lot more involved where it's at the other end of the spectrum, where it's a big picture workshop where we're mapping out maybe an entire value stream for an organization. We may have a dozen, 20 people involved in a session like that representing different departments, different organizational silos and in that case, it requires a lot more planning, a lot more thinking through what the goal of the workshop is, who would you need to invite? Because there's a lot more detail involved and a lot more people involved, that could be four, or five multi-hour sessions spread over multiple days to be able to map out an entire value stream from soup to nuts. And then usually the goal of something like that is some kind of system modernization effort, or maybe spinning up a new project, or decomposing a legacy system, or even understanding what a legacy system does, or process improvement that will result inevitably in some software development in certain

places. I did a workshop like that, I think last August and out of that, we identified a major bottleneck in the process that everyone in the workshop, I think it was just a bunch of pink stickies in one area that it got called the hot mess. [laughter] It was one area and what was happening was there were several major business concerns that were all coupled together in this system. They actually ended up spinning up a development team to focus on teasing apart the hot mess to figure out how do we decompose that down? JESSICA: Yes. PAUL: As far as I know, that effort was still ongoing as of December. I'm assuming that's still running because it was prioritized as we need to be able to decompose this part of this system to be able to grow and scale to where we want to get to. JESSICA: Yeah. That's a major business risk that they’ve got. They at least got clarity about where it is. PAUL: Right. Yeah, and what we did from there is I coached the developers through that process over several months. So we actually EventStormed it out at a much lower level. Once we figured out what the hot mess was, let's map it out and then they combined that with some flow charting and a bunch of other more engineering, kind of oriented visualization techniques, state machines, things like that to try and get a handle on what was going on. DAMIEN: We'll get UML in there eventually, right? PAUL: Eventually. [laughter] You can't do software development without some kind of state machine, sequence diagram. JESSICA: And it’s approximating UML. You can't do it. You can't do it. [laughter] You will either use it, or you will derive a pigeon form of it. PAUL: Right. Well, I still use it for state diagrams and sequence diagrams when I'm down at that technical level. What I find is that there's a certain level of rigor that UML requires for a sequence diagram, or something like that that seems to get in the way of collaboration. So EventStorming sacrifices some of that rigor to be able to draw in everyone and have a low bar of entry to having people participate. DAMIEN: That's a huge insight. Why do you think that is? Is it the inability to hold that much information at a high level of rigor, or just people not used to working at that sort of precision and rigor? PAUL: I think that when I'm working with people that are not hands-on coders, they are in the everyday, like say, product managers, or stakeholders, to use those terms. They're in the everyday details of how the business process works and they tend to think of that process more as a series of steps that they're going through in a very specific kind of way. Like, I'm shipping a certain product, or supporting the shipping. or returning of certain types of products, those kinds of things. Whereas, as developers, we tend to think of it more in terms of the abstractions of the system and what we're trying to implement in the code. So the idea of being able to tell the story of a process in terms

of the events that happen is a very natural thing, I find for people from a business perspective to do because that's how they tend to think about it. Whereas, I think as programmers, we're often taught not so much to think about behavior as a sequence of things happening, but more as the structure we've been taught to design in terms of structures and relationships rather than flow. JESSICA: Yet that's changing with event sourcing. PAUL: I think so. EventStorming and event sourcing become a very natural complement for each other and even event-driven architecture, or any event-driven messaging, whatever it happens to be. The gap between modeling using EventStorming and then designing some kind of event-driven distributed system, or even not distributed, but still event-driven is much more natural than trying to do something like an entity relationship diagram and they'd get from that to some kind of meaningful understanding of what's the story of how these functions and features are going to work. JESSICA: On the topic of sacrificing rigor for collaboration, I think you have to sacrifice rigor to work across content texts because you will find contradictions between them. The language does have different meaning before and after the order is submitted and you have to allow for that in the collaboration. It's not that you're not going to have the rigor. It's more that you're postponing it, you're scoping it as separately. This meeting is about the higher level and you need completeness over consistency. DAMIEN: Yeah. I feel like almost you have to sacrifice rigor to be effective in most roles and in that way, sacrifice is even the wrong word. Most of the things that we do as human beings do not allow for the sort of rigor of the things that we do as software engineers and things that computers do. JESSICA: Yeah. DAMIEN: And it's just, the world doesn't work that way. PAUL: Right. Well, and it's the focus in EventStorming on exploration, discovery, and urgent ideas versus rigor is more about not so much exploring and discovery, but about converging on certain things. So when someone says pedant and the other person says pedant, or vice versa, that tends to shut down the conversation because now you are trying to converge on some agreed upon term versus saying, “Well, let's explore a bunch of different ways this could be expressed and temporarily defer trying converge on.” JESSICA: Later in Slack, we’ll vote. PAUL: Yes. JESSICA: Okay. So standardize later. PAUL: Yes. Standardize, converge later, and for now, let's kind of hold that at arm’s length so that we can uncover and discover different perspectives on this in terms of how the story works and then add regulator when we go to code and then you may discover things in code where there are implicit concepts that you then need to take back to the modeling to try and figure out well, how do we express this? Coming up with some kind of term in the code and being able to go from there. JESSICA: Right. Some sort of potential return because it hasn't happened yet. PAUL: Exactly. So maybe it's a potential, maybe it's some other kind of potential return, like pending return, maybe we don't call it a return at all. JESSICA: Or disliked item because we could – or unsatisfactory item because we could intercept that and try to like, “Hey, how about we send you the screws that we're missing?” PAUL: Right. Yeah, maybe the answer is not a return at all. JESSICA: Yeah. PAUL: But maybe the case is that the customer says they want to return it, but you actually find a way to get them to buy more stuff by sending them something else that they would be happy with. So the idea is we're trying to promote discovery thinking when we are talking about how to understand certain problems and how to solve them rather than closing off options too soon. MANDY: So, Paul, I know you do give these workshops. Is there anything? Where can people find you? How can people learn more? How can people hire you to facilitate a workshop and get in touch with you? PAUL: Okay. Well, in terms of resources, Damien had mentioned at the beginning, I have an eBook up on Leanpub, The EventStorming Handbook, so if people are interested in learning more, they can get that. And then I do workshop facilitation and training through my company, Virtual Genius. They can go to virtualgenius.com and look at what training is available. It's all online these days, so they can participate from anywhere. We have some public workshops coming up in the coming months. And then they can find me, I'm @ThePaulRayner on Twitter, just to differentiate me from all the indefinite articles that are out there. [laughter] MANDY: Sounds good. Well, let's head into reflections. I can start. I just was thinking while we were talking about this episode, about how closely this ties into my background in professional writing, technical writing to be exact, and just how you have this process to lay out exactly what steps need to be taken and to differentiate when people say the same things and thinking about, “Well, they're saying the same things, but the words matter,” and to get pedantic, that can be a good thing, especially when you are writing technical documents and how-tos. I remember still, my first job being a technical writer and looking at people in a machine shop who it was like, first, you do this, then you do this, then you do this and to me, I was like, “This is so boring.” But it makes sense and it matters. So this has been a really good way for me to think about it as a newbie just likening it to technical writing. JESSICA: Yeah. Technical writing has to tell that story. DAMIEN: I'm going to be reflecting on this has been such a great conversation and I feel like I have a lot of familiarity with at least a very similar process. I brought up all my fears that come from them, which is like, what if we don't have the right person in the room? What if there's something we didn't discover? And you said something about how you can do this in 5 minutes and how you can do this in 15 minutes and I realized, “Oh, this process doesn't have to be the 6-hour things that I've participated in and facilitated in. It can also be done more smaller and more iteratively and I can bring this sort of same process and thought process into more of the daily work.” So that's super helpful for me. JESSICA: I want to reflect on a phrase that Paul said and then Damien emphasized, which is shared understanding. It's what we're trying to get to in EventStorming across teams and across functions. I think it's also like what we're constantly trying to get to as humans. We value shared understanding so much because we're trapped in our heads and my experience in my head is never going to be the same as your experience in your head. But at some point, we share the same physical world. So if we can get that visual representation, if we can be talking together about something in that visual world, we can pass ideas back and forth more meaningfully. We can achieve this shared understanding. We can build something together. And that feels so good. I think that that constant building of shared understanding is a lot of what it means to be human and I get really excited when I get to do that at work. PAUL: I think I would just add to that as well is being human, I'm very much aware of limitations in terms of how many ideas I can hold in my head at any one time. I know the times where I've been in the experience that many describe where someone's giving me a list of steps to follow and things like that, inevitably I'm like, “Well, I remember like the first two, maybe three,” and then everything after that is kind of Charlie Brown. What, what, why? [laughter] I don't remember anything they said from that point on. But when I can visualize something, then I can take it in one go. I can see it and we're building it together. So for me, it's a little bit of a mind hack in terms of getting over the limitations of how many things I can keep in my mind at one time. Also, like you said, Jess, getting those things out of my mind and out of other people's minds into a shared space where we can actually collaborate on them together, I think that's really important to be able to do that in a meaningful way. MANDY: Well, thank you so much for coming on the show today, Paul. We really enjoyed this discussion. And if you, as listeners, would like to continue this conversation, please head over to Patreon.com/greaterthancode. We have a Slack channel. You can pledge and donate to sponsor us as little as a dollar and you can come in, hang out, talk with us about these episodes. If not, give me a DM on Twitter and let me know, and I'll let you in anyway because [laughter] that’s what we do here at Greater Than Code. PAUL: Because Mandy’s awesome. MANDY: [laughs] Thank you, Paul. With that, thank you everyone for listening and we’ll see you again next week.