Three eventstorming workshops - a report

April 13, 2016 at 7:56 AM - by Freek Lijten - 4 comments

Tags: agile, DDD

Creating groups

Since I got about 18 interested persons I had the luxury of creating groups. For a while I doubted on how to organise those groups but settled on a broad mix of professions in each group. I feel event storming is most succesfull in two situations:

A group that consists of lot of people that are expert on the same narrow field in a business. We're now collecting details. Hopefully friendly fights on how stuff works and should work spontanuously arise.

A group that consists of people that have expertise on fields that each touch eachother. Obviously, missing one link makes sure you end up with two groups of people without a connection. Discussion here should hopefully be more like "that is not what we do" and "we only put information X in location Y because there is no other place!".

Groups for my workshops

Since we went for big picture eventstorming I arranged groups according to the second situation. Each session I removed all chairs from the room and put tables, etc to the edge. I prepared the not-so-infinite-but-still-pretty-big modelling space and gave only the shortest of introductions. Since the thing we have in common as a group is that we all work for Procurios, we were eventstorming ourself. Every process allowed. There are big differences between groups and will discribe all 3 sessions and things I learned below.

Session 1

I was immediately off to a good start. At Procurios, people are pretty much used to stickies on walls so I did not have to help anyone accross the "I am a grown-up important person with very little time, am I really expected to put pink stickies on a wall"-barrier. Within minutes the wall started to get filled. Some people were more hesistant than others but little nudging and correction was required.

Pretty soon a discussion on invoicing emerged. People were clearly of different opinions on some parts of this process. This was great! What was meant to be an exercise in eventstorming actually turned out to be useful on the spot, if only for creating more awareness on issues surrounding this topic. The problem here was that people were reluctant to stop discussing and start writing again. They identified the problem but wanted to create the solution straight away as well.

Lessons learned

1. More space is better, walls fill up very quick :)
2. It is hard to get people back to writing if they are passionate about a problem. Talking is so much easier than writing. I do not feel this is a huge issue since we learned something. Still I also feel we might learn more if I get people back to writing after a while.
3. If people think something is too "fuzzy" to write down on some stickies you're likely to have found yourself a hotspot. The hard part is to convince them of this. Writing allll those stickies is boring to them. Only when they're all on the wall does the effect of "omg this is horrible" truly kick in. If we do not get them there, it will just remain that "fuzzy process"

Session 2

The second session was so different from the first session. It took people more time to start writing and sticking notes to the wall. Also it was more an individual exercise at the start. It took people about 25 minutes before the started collaborating. The result was a lot of small starts on processes that did not get finished or only got actively discussed much later.

I feel this group had needed  a bit more instruction up front. Since the first group started so fast I felt that I had hit the sweet spot of 'just enough explanation' but in retrospect I think this was luck :)

Lessons learned

1. It might be usefull to seek to what people are not writing down. "If I have to write all that down, it will take ages" Good. There is our problem, now start writing :D
2. I had hard time figuring out when to step in and correct some things like making sure that events where written down in past tense. Not too soon certainly but waiting for an hour makes it hard to get people to change what already has become a bad habit. I'm thinking of using pomodoro's next time and use each 5m break as a mini-retrospective.
3. If people have a hard time starting or continuing, it might be useful to simply ask them what annoys them on a weekly basis. That seems to get people going ;)

Event storming, jay!

Session 3

This one had the smallest group of people due to some people being ill. It was also the first session where we experimented with smaller timeboxes. We noticed that we could help and correct people while they were actively event storming but we also lacked a formal retrospectal moment where we could redirect the whole group of people. We can of course shut the process down for a couple of minutes at any time, but since it takes people a while to get started it feels overly interruptive to bother them after only a couple of minutes with the first feedback on the process of event storming itself.

Lessons learned

1. Timeboxes of 25 minutes (a pomodoro!) seem to be working fine. It is long enough for people to get going, but short enough to guide people trough the eventstorming process.
2. At 4 people this was our smallest group yet. It felt like this was the minimum for a session with a lot of different expertises. Less might work fine for the scenario where everyone is an expert in the same field.
3. Someone experienced a sort of 'writers block'. There were so many paths that he was hesistant to start writing at all. What would be the "best" path to start with? After a discussion the group suggested him to start at the end and work back. Simply use the last path you encountered and write it all down.
4. Be as invisible as possible when facilitating. Only ask questions, and give as little solutions as possible. The moment I got involved too much, all other involvement dropped.

Overall

I think I would like to prepare an example (very small, < 10 post-its) of a process that has nothing to do with the current business to give participants an idea of where we're going. I noticed people usually start out really fragmented and only after one or two retrospectives would they start finishing processes and zooming in. In part this may be to the unclear ideas of participants on event storming at the start, so a small example might help.

I think most attendees had some degree of fun and realised the value of this tool for our business. I got to learn a lot more on facilitating so I feel I ticked both boxes in the goals category :) Tickets are apparently a central part in our organisation since that was the one process that got a lot of attention during all three sessions.

What I would love to do next is get developers and designers together and do a design oriented event storming session just to try that out as well. The orange of domain-events only tends to be a bit boring on the eye after all :)

Since I am by no means an expert I would love any tips and tricks or good stories from you all. Leave them in the comments!