00:58 - Paul’s Superpower: Participating in Scary Things

02:19 - EventStorming

• Optimized For Collaboration


• Visualizing Processes


• Working Together


• Sticky (Post-it) Notes

08:35 - Regulation: Avoiding Overspecifics

• “The Happy Path”


• Timeboxing


• Parking Lot


• Inside Pixar


• Democratization


• Known Unknowns

15:32 - Facilitation and Knowledge Sharing

• Iteration and Refinement


• Knowledge Distillation / Knowledge Crunching


• Clarifying Terminology: Semantics is Meaning


• Embracing & Exposing Fuzziness (Complexities)

24:20 - Key Events

• Narrative Shift


• Domain-Driven Design


• Shift in Metaphor

34:22 - Collaboration & Teamwork

• Perspective


• Mitigating Ambiguity

39:29 - Remote EventStorming and Facilitation

• Miro


• MURAL

47:38 - EventStorming vs Event Sourcing

• Sacrificing Rigor For Collaboration

51:14 - Resources

• The EventStorming Handbook


• Paul’s Upcoming Workshops


• @thepaulrayner

Reflections:

Mandy: Eventstorming and its adjacence to Technical Writing.

Damien: You can do this on a small and iterative scale.

Jess: Shared understanding.

Paul: Being aware of the limitations of ideas you can hold in your head. With visualization, you can hold it in more easily and meaningfully.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

MANDY: Welcome to Episode 271 of Greater Than Code. My name is Mandy Moore and I'm here today with a guest, but returning panelist. I'm happy to see Jessica Kerr.

JESSICA: Thanks, Mandy. It's great to see you. I'm also excited to be here today with Damien Burke!

DAMIEN: And I am excited to be here with both of you and our guest today, Paul Rayner.

Paul Rayner is one of the leading practitioners of EventStorming and domain-driven design. He's the author of The EventStorming Handbook, co-author of Behavior-Driven Development with Cucumber, and the founder and chair of the Explore DDD conference.

Welcome to the show, Paul.

PAUL: Thanks, Damien. Great to be here.

DAMIEN: Great to have you.

And so you know, you are prepared, you are ready for our first and most famous question here on Greater Than Code?

PAUL: I don't know if I'm ready, or prepared, but I can answer it, I think.

[laughter]

DAMIEN: I know you have prepared, so I don’t know if you are prepared.

PAUL: Right.

DAMIEN: Either way, here it comes. [chuckles] What is your superpower and how did you acquire it?

PAUL: Okay. So a couple of weeks ago, there's a lake near my house, and the neighbors organized a polar plunge. They cut a big hole in the ice and everyone lines up and you basically take turns jumping into the water and then swimming to the other side and climbing out the ladder.

So my superpower is participating in a polar plunge and I acquired that by participating with my neighbors. There was barbecue, there was a hot tub, and stuff like that there, too. So it was very, very cool. It's maybe not a superpower, though because there were little kids doing this also. So it's not like it was only me doing it.

JESSICA: I'll argue that your superpower is participating in scary things because you're also on this podcast today!

PAUL: [chuckles] Yeah, there we go.

DAMIEN: Yeah, that is very scary. Nobody had to be fished out of the water? No hospital, hypothermia, any of that?

PAUL: No, there was none of that. It was actually a really good time. I mean, being in Denver, blue skies, it was actually quite a nice day to jump into frozen.

MANDY: So Paul, you're here today to talk about EventStorming. I want to know what your definition of that is, what it is, and why it's a cool topic to be talking about on Greater Than Code.

PAUL: Okay. Well, there's a few things there.

So firstly, what is EventStorming? I've been consulting, working with teams for a long time, coaching them and a big part of what I try and do is to try and bridge the gap between what the engineers, the developers, the technical people are trying to build in terms of the software, and what the actual problem is they're trying to solve.

EventStorming is a technique for just mapping out a process using sticky notes where you're trying to describe the story of what it is that you're building, how that fits into the business process, and use the sticky notes to layer in variety of information and do it in a collaborative kind of way.

So it's really about trying to bridge that communication gap and uncover assumptions that people might have, expose complexity and risk through the process, and with the goal of the software that you write actually being something that solves the real problem that you're trying to solve.

I think it's a good topic for Greater Than Code based on what I understand about the podcast, because it certainly impacts the code that you write, touches on that, and connects with the design. But it's really optimized for collaboration, it's optimized for people with different perspectives being able to work together and approach it as visualizing processes that people create, and then working together to be able to do that.

So there's a lot of techniques out there that are very much optimized from a developer perspective—UML diagrams, flow charts, and things like that. But EventStorming really, it sacrifices some of that rigor to try and draw people in and provide a structured conversation.

I think with the podcast where you're trying to move beyond just the code and dig into the people aspects of this a lot more, I think it really touches on that in a meaningful way.

JESSICA: You mentioned that with a bunch of stickies, a bunch of different people, and their perspectives, EventStorming layers in different kinds of information.

PAUL: Mm hm.

JESSICA: Like what?

PAUL: Yeah. So the way that usually approach it is, let's say, we're modeling, visualizing some kind of process like somebody registering for a certain thing, or even somebody, maybe a more common example, purchasing something online and let's say, that we have the development team that's responsible for implementing how somebody might return a product to a merchant, something like that.

The way it would work is you describe that process as events where each sticky note represents something that happened in the story of returning a product and then you can layer on questions. So if people have questions, use a different colored sticky note for highlighting things that people might be unsure of, what assumptions they might be making, differences in terminology, exposing those types of unknowns and then once you've sort of laid out that timeline, you can then layer in things like key events, what you might call emergent structures. So as you look at that timeline, what might be some events that are more important than others?

JESSICA: Can you make that concrete for me? Give me an example of some events in the return process and then…?

PAUL: Yeah. So let's say, the customer receives a product that they want to return. You could have an event like customer receive product and then an event that is customer reported need for return. And then you would have a shift in actor, like a shift in the person doing the work where maybe the merchant has to then merchant sent return package to customer.

So we're mapping out each one of these as an event in the process and 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