Storystorming
Explore your domain — by literally watching your language
It’s a clear and peaceful sunday morning in Vienna, not stormy but storming! For some psy reasons I can’t sleep anymore. So? Before my family gets up and wants to have breakfast with me, I write about a really lightweight workshop format I had my fair share of client successes with in the recent months ...
… it is a format to explore and understand user journeys, work procedures and whole business processes by telling stories and by focusing on their domain language. I currently use it in the context of software projects, but it can turn out to be useable way beyond this context.
The aspects of Storystorming, I blog about today are influenced by Stefan Hofer’s and Henning Schwentner’s thoughts about Domain Storytelling, by Alberto Brandolini’s EventStorming and Adam Dymitruk’s Event Modeling, which I had the honor to learn about during Alberto’s Summit 2018 in Bologna. See a picture of this awesome community meetup below. I will forever remember Bologna! Then there are also influences coming from Jeff Patton’s User Story Mapping and — last not least — its style is also a bit induced by my in-depth knowledge of Stephen White’s BPMN, a very powerful, almost almighty process model and notation and an ISO standard (ISO/IEC 19510:2013) by now. But, as much as I adore its beauties, inner values and semantic completeness, it is in my mind — for several soft and fuzzy reasons — not well-suited to simply learn about your processes and, you know, explore your processes’ potentials, together!
What did convince me that Storystorming “deserves” its own blog post? Well, it does have a very unique proposition, in that it allows me to literally, and word by word “watch” and “improve” my (domain! 😛) language. Plus: I know by now what happens in a room after having explained this method … and that this just requires 5 minutes. Imagine you are the lucky software developer: you have one or even several domain experts in a room! Now you have this once-in-a-lifetime :-) opp to understand what they are up to. Now you can ask them all the important questions to understand their work procedures and the domain, right? No, you can’t. You can’t. It doesn’t work like that. But here is what you could do, aside of using the great tools I mentioned above. (All of them have very different traits and merits!)
Explain this method, let people in the room start to work, get yourself an ice lolly, get back, offer your help with the method and ask simple questions. :)
A simple example first, the real life later
“A simple sentence has a subject, a verb and an object, right?”
A few people nod. They remember this from school :-) ... but how can we leverage this knowledge? Well, by forming sentences, we can tell stories! And by rearranging sentences and working on their language, we improve stories.
Ask your domain experts to tell a very specific story of their work life. Start from their happiest, smoothest stories. You need the example? Sure.
Imagine we build a ticketing system for a sports venue and you talk to a cashier. His name is Andrew. You ask: “How does your work look like? What happens?” “Well, for example a customer calls and asks for football tickets?”, Andrew answers. OK. Let’s see, The customer is a subject in this sentence and an actor in our story and goes on a yellow sticky note. The verb we put on a blue sticky and the object on a green one.
“It seems a bit of an effort at first … but you’ll see it’s pretty simple! :-)”
If you are into icons, you can draw icons on your sticky notes, but if you are like me … I am not this kind of guy. :-) I really like to focus on the language. And what a wonderful and simple sentence we have here! But something is still missing. Better: somebody is missing! Our cashier. If the customer is doing something in this story on her own and alone, then we could just leave the sentence as it is shown here, but actually the customer communicates with the cashier. So, in that case I will put the cashier on another yellow sticky note and rearrange the sticky notes a bit.
Voila, we just completed our first full sentence. The customer asks the cashier for football tickets. The customer is the active actor during this first step of a larger collaboration, which is why we see the verb next to his yellow sticky note. The cashier is the passive actor, so the object sits next to him. “But then … what’s next?” “Well, of course I try to find suitable seats in the screen plan of our ticketing system. Then I recommend the available seats to the customer.”
In other words, we have another probably quite active “actor” here: our cashier is interacting with a ticketing system. But because this is very important for me and because the human beings I know really appreciate to distinguish themselves from systems :-), I put the ticketing system on a red sticky note. Then I let Andrew write down to “find suitable seats” in the “screen plan” and “recommend” the “available seats” to the customer. I help a bit in arranging the sticky notes and repeat the three sentences by pointing with my finger at the sticky notes. Andrew forgot to write down the important word “suitable” and I noticed. For the moment I let it go. Because right now it’s much more important to encourage him. And I can physically see that Andrew starts to relax and smile. He is a proud cashier, and he is so for good reasons, because he knows his work and his workplace very well. Before this session with this cryptic software guy, he actually was a little bit anxious. But now he is even prouder about himself, and again for a reason: because he could understand what this software guy is up to in about three minutes, right?
Therefore, at this point I might get out of the room for a minute and head for the first ice lolly. So I encourage Andrew to move on by himself. “But wait, what next … the customer might like the seats — or not.”, he says. “Right, let’s see, you are telling just one story here and for now we just focus on the happiest possible story. But let me show you one more thing … I would like you to make such assumptions about how exactly involved people and systems behave in your story, I mean, what they do, a bit more explicit.”
I write down that I understand the happy case to be that the customer confirms the offered seats. Then I take a lilac sticky note, notice that Andrew looks quite a bit more skeptical again, but pretend not to notice, and just write down what he said: “Customer likes the seats”. Then I say: “Look, in our story the customer likes the seats. Therefore I put this lilac thing here on top of the sentence. We really can just tell one story at a time, right?” Andrew looks happy again and I head for my ice lolly. I do like ice lollys, but actually there is also a bit of “tactics” involved here. I want Andrew to tell the story by himself. In the very best case I can even get him fond of my method. If this happens he will start to work really hard, until he suddenly notices to be hungry or thirsty or to need such an ice lolly, too! :-)
When I get back three minutes later, even though I have been optimistic when I left, I am still positively surprised of what I see. This is how Andrew’s story looks like now. And he smiles and says: “I am done! Am I right?” :-)
“So, you confirm the seats in the ticketing system, which then generates a reservation for you … including a number you can tell the customer … right?”. “Exactly”, Andrew nods. “But why don’t you directly hand out the tickets?”, I ask. “Well, the customer called, don’t you remember?” Andrew laughs. I smile back. I am the stupid guy and I really am. And I need to be. “Of course! You mentioned that. But what about the lilac Seats are available … I thought you were just looking for them a few seconds ago?” “Yes, but it could still be that they are gone by now, which is annoying, of course.” “Ah, ok, you are right. You are really very detailed and specific to think about such a seldom case!” “Seldom? You know … when sales opens, even for less important events, it really happens all the time. We are many cashiers … and the system always proposes the best seats for a category. When you confirm them, they are gone already ... do you think we can improve that? I mean … one can circumvent the problem a bit … I can manually select less ideal seats from the beginning on. But then … all cashiers do it and we get the errors.”
Wow. :-) We just discovered a rather huge issue they have — and quite a bit potential to make them happy with their new system ... how did we get here? By asking ”stupid, obvious” questions. Together, we add three more stickies.
First, we want to remember that this story shows a customer calling by phone. Furthermore, we make a bit more explicit, that the customer requests a specific category, which needs to be available, of course. And then we add the very special pink attention flag to this ugly “seats availability”-thing. We do not decide or discuss yet, what to do about it. We’ll see later. Maybe we find even larger things? It’s “just” a huge operative annoyance for both cashiers and customers, but of course there might be much bigger issues to discover, maybe on a strategic level and with much higher return on investment ... ?
Now, up until this point, I made up this example. No, actually I didn’t make it up. I mean, I “took it” :-) from my friends Stefan and Henning and I adapted it a bit for my needs. I want to thank you for being so helpful to go through these ideas here during the most recent DDD Germany BBQ at Marco Heimeshoff’s place! These are the opportunities to make progress and co-create in a helpful community, so I also want to thank Marco for organising this real thing! 👍
The real things happen in real life
Yes, so true and self-evident :-), the real things happen in real life, so I also want to show you what may happen, when you practically apply this format. I must distort the following picture to a point at which I can’t violate any non-disclosure agreements I have (and most often don’t read thoroughly). We can still discuss very well what is going on here from a bird’s eye view!
Bring in events
First of all, what about all those orange stickies here? Well, I didn’t mention yet, but it makes sense to mix in this important trait of EventStorming: events. I had two little teams in a room, storming together these stories. They are working on different parts of the very same, largely excel-driven business process — and they don’t work together very closely. Therefore, we first (brain)stormed a few major events both teams were aware of, like: at the end of the day, what are we up to together? At the beginning of the day: which events trigger us to do work? What are some major achievements on our way through the day?
(Even though we felt comfortable with these early findings, we later found both start and end events to be wrong, and everybody loved to find this! :-)
Hack the room
The first rough eventstorming phase just required the first few minutes. To warm up even more, we hacked the room, together. As a result we had a very long table and everybody on one side of the table, plus our rough events on orange stickes along a very rough timeline, plus enough coffee and tea and cookies. But we decided to put them far away from the work place. :-)
Sense the day’s comfort zone
The first team worked on “their” stories along the left part of the table, the second on “their” stories along the right part of the table, with really just me “in between” and helping a bit with the method. This seemed to be natural for them, because (as in so many real life business processes) they have a more exploratory phase in the beginning managed by one team and then a more specified phase in the end managed by another team. Did we protect their silos with this setup? Yes, of course. But then I think it was a good decision on this particular day and considering the very early stage of the project. Both teams wanted to show the others what they have and even “competed” in that endavour a little bit. And I felt: in a good way. :-)
Discover the unhappy by exploring the happy
What you see above are basically the stories of how things work out happily for the first team. We are in the process’ exploratory phase, therefore we discovered quite a few lilac actor decisions we assume here and we also discovered orange events by walking through these happy stories: things that can go wrong, things that would interrupt or delay our work and so on …
Take a pic and rearrange
All such decisions or events we discover are potential for more stories. The principle: just take a pic of what you have and rearrange your stickies to tell another very specific, strictly example-oriented story. However, I try not to “overdo” with variations in early phases. On this day, we really just wanted to know what absolutely needs to happen in the process. And then we did a dot voting on the three most important issues we wanted to improve by means of software. It was good enough to explore the happy stories, to make the assumptions visible and capture the problems we discover on our way.
Walk through the story and improve
Make sure you understand your story by walking through it from time to time. In particular, if you have people in the room who don’t own the specific story themselves: walk these people through the foreign parts. Based on their questions, comments and their evidence :-) we get a story straight, improve on the language. We remain on the same page and we learn from each other.
This is the second, much more pre-specified part of the process. Therefore, you notice a lot less behavioral decisions and a lot less problematic events. You can also see that this part is at least a bit supported by software, which is why you see at least a bit collaboration in the middle.
Spot the problems with the data
I love the “green tree” growing out on the left hand side. Can you see it? These are quite a few “objects” for one sentence, right? The reason was that these are important properties of the main “object”. The team wanted to show this — and it could! It’s relevant data and in this part, as we can see, they do not yet have meaningful software support at all. Most of their work at this point and in general is about checking validity of incoming data and completing it — more or less manually, and again with just a bit excel-driven support.
Spot behavioral and structural boundaries
What you may expect when applying the method are emerging boundaries. Obviously, in this regard a lot is happening on the language level not visible in the pics above. But imagine: singling out specific words on separate sticky notes does help to choose them more carefully and to improve them quickly. As a consequence, potential for more behavioral as well as more structural software aspects starts to emerge: on one hand from the language on the blue activity-oriented verb stickies, on the other hand from the language on the green object- stickies. We have seen the potential to leverage (DDD) value objects visually growing out of specific areas as “green trees”. It‘s in my mind however too early to think about (DDD) aggregate boundaries.
Spot context and responsibility boundaries
(DDD) context boundaries emerge from language, but also around parts of changing collaboration patterns in between actors. You can visually spot responsibility and task boundaries emerging around parts of work driven by some actors until the collaboration pattern changes again, or until e.g. time events must be awaited. In the example shown above, we demarcated such parts by means of light yellow sticky notes — right below the actual stories!
Storystorming —my favorite feature?
By focusing on this very fundamental Subject — Verb — Object trait of our language, we enable domain experts to tell their stories in the most natural manner, without requiring them to learn anything specifically apart from five different colors. What’s even better: I can assist with regards to the method, even if I do not get it at all what they are speaking about, and even if I do not get it for a very long time. :-) I can certainly discover subjects, verbs and objects in their language! I can assist them with this simple method, ask the “dumb” questions and get into the listening mode by means of an ice lolly.
Listen to language - Repeat until you speak
The most natural way to learn a language is certainly to listen to the parents, to imitate them and then to speak the language yourself — and rather soon! Little children repeat what they have heard and receive feedback. Gradually, they understand more words, begin to form sentences and later tell their own stories. By asking experts to record and visualise language with a very simple system, one can enable a similar style of learning. Now that I see the words, I will fail fast: “Oh, I understood something different!” By using sticky notes we can easily form stories out of sentences, sentences out of words, dismiss and improve the language, remodel the story — and after just a few stories we already know many of the persons, activities and objects of the domain.
Enjoy the feeling of achievement
On that specific day, we needed four hours to achieve this result. Everybody left the room with the feeling: “wo/man, this time we achieved something”. We sorted out a lot of domain abbreviations and cryptic codes and I myself could actually fast and easily understand what the real experts are up to here. The method enables me to act like a baby learning a language. But as I just said: it only took us four hours instead of the usual two or three years. :-)
One prerequiste for learning of course remains. I believe … we must like it!
A small, but important thing … even when I sound assertive sometimes, it’s a subconcious technique I use to provoke your associations and counter arguments. I never claim to understand, but always try to understand better than before. I share thoughts and feelings, and even when I attempt to “define” things, it’s an invitation: please help me, as a software community, to eventually get this stuff consistent! :-) If you want to keep in touch, you can follow me on Twitter. It’s also the simplest way in case you need to exchange a direct message with me. Please also help me to give proper credit to persons which might have contributed in some way or published something without me realising. It’s not always my strongest side to know why I know.
