The real power of eventstorming is how it focuses on outcomes, not activities.
Why is this powerful?
It gives you options. That is according to Dan North at his recent talk at DDD eXchange in London with Skill Matter.
I know there is a lot of interest in eventstorming right now. It is of particular relevance to you if you are using DDD, CQRS and Event Sourcing. So I’ve written up my notes from Dan’s talk here. I hope you find them useful.
It is a specialised type of workshop. It makes use of magic-whiteboard paper, sticky notes of varying colour to denote events, actors and puzzles. Eventstorming uncovers what a business does to achieve a goal. This allows you to model it and build the right software. You could call it an advanced form of requirements gathering.
Uncover the hidden processes and events in your business
To illustrate how EventStorming would work Dan illustrated it by showing a staged EventStorm for how he put his talk together. It worked so I’m going to shamelessly rip it off his idea here – all for your benefit. So here’s an example EventStorm for how I wrote this article.
1. Start with an end goal:
I want to leave my readers knowledgeable about EventStorming and hopefully keen to try it 😉
2. What is the start point/trigger:
SkillsMatter asked me to do I write up of their DDD eXchange conference. (Yellow sticky denoting an actor or an external agent acting on my system or a command)
All that remains to do is to fill in the gap. How do I resolve these two end points?
3. Fill in the gaps with the events which need to happen to achieve the end goal:
And that’s it. The basics of EventStorming – done 🙂
EventStorming focuses on what happened to achieve a goal or outcome. Important to note this is not what should happen or how it happens. Getting this overview highlights and ambiguities and gives you real insight into the business – quickly. This creates options about how that thing could happen.
I’m sure you have all experienced someone telling you how to build the software they are commissioning from you.
But there is more to this story…
We already know that making the implicit, explicit, in code, can be a good thing. It is something to aim for. It also happens to be a good thing at a team level.
It’s always surprising how people, who often sit in open plan offices, don’t know how their part of the jigsaw fits into the rest of the business process. They often feel like they do, but EventStorming reveals the gaps (and often fills them in). In fact, according to Dan, EventStorming is one the few workshop techniques which leaves everyone in the know. This benefit alone is valuable for any team.
It helps in other areas too including:
To get EventStorming to work you need the key business people involved. That’s everyone involved the process/app/thing you are building (including decision makers).
You will also need plenty of wall space which you should cover in magic whiteboard paper. Plenty of sticky notes of varying colours and colour pens.
The different colour stickies have meanings. They are (this is not an exhaustive list):
Orange – This represents the things which have happened. The events.
Yellow – An external agent, actor or system which provide input and/or commands
Pink – Uncertainty or arguments or disagreements
For a fuller explanation of the kit, room setup or colour meanings, Dan suggests getting hold off Alberto’s book.
The bit which makes EventStorming work so well is how it’s structured. You start with the end in mind. Draw a box on the right of the wall with your desired outcome. This is the “until everyone lived happily ever after” part. Then on the left, you draw up a box with the start state.
—–Start State———————————————————————————-End State—–
Your job, with everyone else in the room, is to fill in the gaps with all the things which happen to make the outcome possible.
Dan gave the example of how Alberto (the inventor of EventStorming) asked him to speak at DDD eXchange. In this case, Alberto was the actor issuing a command – a yellow sticky.
If there are any questions/issues/puzzles you capture them on pink stickies.
It can also be useful to capture what things look like. I.e. read models on separate colour stickies. Often how things look is different from how they work.
Note that vertical space has no specific meaning other than indicating that certain actions can happen in parallel – i.e. they are stacked up at one specific time.
It’s also worth mentioning Dan’s suggestion to start a little in on the left and a little in on the right. This is because it’s not uncommon to discover the start is not where you thought it was. Or that the end is not the end at all.
After a time you will begin to notice clumps of events. These can be an early indication of aggregates.
That is the basics of EventStorming. Dan Highly recommended getting Alberto’s book for a more in-depth explanation.
In the next section, I will highlight some key factors to bear in mind when EventStorming business processes, legacy applications and greenfield projects.
In his first example, Dan illustrated his experience storing a business process with a client. In this case, it was a new work request process. It could have several outcomes
We are going to do it – it’s funded
We defer it
We are not going to do it.
This client had invested in capturing the process in a flow chart of all the different decisions. Flow charts are brilliant descriptions of things that don’t happen. The reality is people don’t follow flow charts they do human stuff. Stuff like finding shortcuts, understandings with people, and batch processing tasks up etc.
Dan described EventStorming as like a little outboard motor. It will take a few goes to get it going but once it does it really kicks off. To unlock the process give good examples.
Interesting Observations to Call/Look Out for
The individuals in the room are not necessarily going to know the whole process. Just seeing how and where people congregate on the timeline provides useful insight.
Managers are likely to have more of an overview. And you will often see them going up and down the line and triggering useful conversations about the order of certain events.They start asking questions about whether this always happens or sometimes happens. When this happens you need to grab a pink post it and capture it.
The reason this is such a high signal process is because you have a lot of things going on in parallel. Using physical space and seeing different groups of people are using parts of the wall at the same time tells a story. It triggers discussions.
But is can get a bit heated…
Which is ok. Those heated discussions can often reveal a lot of information. But keep the pink sticky at and to capture and smooth over the conversation.
Next stage – Ask this key question.
Which of these events have to happen? And which happen to happen?
This is a powerful part of the process. It can end up streamlining the actual business processes. You end up with just the core events and some of the puzzles may disappear.
This process is similar to a pull-based system. What has to happen to pull the end result into existence.
Call out at the end how everybody now knows what everybody knows. It is an amazing tool clearing ambiguity.
This is a story of a false start. But one which needed to happen to clear the air.
If you find the process all too easy – get suspicious. People have differing opinions. So when it goes up a little too easy it could indicate something’s amiss. EventSTORMING is often lively and energised.
Dan illustrated this with this story from direct experience at a client site.
The client had invested in a very expensive process mapping tool and in a person whose job it was to know how to use this tool. They printed the process on very expensive process mapping paper.
It turned out they had been primed. And ended up creating what was essentially what they already had.
In other words, the first attempt was a way to clear out the cobwebs. It was like a proverbial clearing of the throat.
Far from being a waste of time, this process was necessary to get out of their system. They had been told what the system does. They were unable to separate what the system does from this is how it works.
The second attempt revealed the real process and was an insightful exercise.
If you are faced with this it is important to let it run. Let the group get it out of there system otherwise, you will be fighting against the grain for the whole session.
The key thing about a new application is it is likely to have multiple outcomes. It is also likely to have far more pink post-its. And that’s ok.
The reality is that a new project at the opening stages is like guided guessing. As such there are going to be many uncertainties. It’s an opportunity to learn more.
Part of what brings this process to life is it is a highly visual, visceral representation of what faces the team.
Of Course, a wall full of pink stickies maybe leaves you wondering where to go next. But what this tells you is your next tranche of work is going to be discovery work. Knowledge crunching.
The pink areas of the wall give you a guided itinerary of places to research next. You can then focus your efforts on solving specific problems. And it makes it easier to divide up the research work.
It can be helpful at this stage to build up persona’s representing users within the system. Use this opportunity to go ask the stakeholders to help you fill in the blanks.
As a team, you now have a shared vision.
You need lots of stationary. If you think you have enough – get some more.
2. Research has shown people are more creative and less restricted when you create the illusion of plenty. It liberates people’s minds . Along a similar vein have lots of pens. But not just any pens, get colour pens as they encourage people to be more creative.
3. Be prepared to break up arguments.
4. Be prepared to let arguments run – often where the richest modelling happens.
5. Use a visible Pomodoro timer – If you have a visible timer running in sets of 25 mins with defined 5 min breaks you are much more likely keep people engaged. If I see 7 mins remaining on a clock, I don’t mind waiting before dealing with that important call.
6. Be a time cop – enforce the timekeeping
7. Agree explicit ground rules.
This is the person who thinks “You can’t do anything useful with post-it notes”. Let it roll or politely ask them to hold back open criticism. The disruption often comes from people who are isolated or feel threatened by the process. It often comes from a position of fear. As the session progresses and people start asking for their input these people are often drawn in.
These are the people who go quite in these types of meeting. It’s on you to notice these people. Have you got to their bit yet? They may be deeply introvert. Or they may not want to lose face in front of the boss or bosses boss.
Just use a pink sticky to smooth over the arguments these people inevitably cause.
You know the kind of person I’m talking about. They want to do the pens or want to facilitate. Try to guide them back into the process. They are most useful when contributing and not being distracted by the process.
If you are lucky enough to the natural facilitator. Let them do it.
The person who has to have the last word. Again let them have it. Dan’s suggestion – pick your battles!
It such a simple process and often is seen as super helpful. So it’s no surprise that people often pick it up and run with it. Nurture it. Encourage it.
EventStorming sessions are being run at more and more places by more and more people. And although it originated to help developers understand and model software. It seems clear to me that it has a place more broadly in companies.
The best way to know how effective it is – is to run a session. If you do, please let me know how it went!
Download this FREE accompanying ebooklet today:
I'm a professional software engineer of near on 15 years. Lucky enough to work for a small but rapidly growing company in London called Redington. They have given me the technical freedom to learn some cutting edge technologies like CQRS and Event Sourcing. Now I'm sharing what I learn here.