Remote Team Flow EventStorming for Retrospectives

--

An example of a short Team Flow EventStorm (this is not based on any real teams)

Visualise your team’s process and you’ll uncover a higher quantity and higher quality opportunities for improving how you work as a team compared to relying on traditional retrospective formats.

If your team works remotely, you can achieve this by EventStorming your team’s flow using the digital collaboration tool Miro.

I’m currently working with a team at Software Park building event-driven services for a giant European transport company. We tried this approach for the first time as a replacement for our 1-hour retrospective — the results exceeded all expectations.

If you’re looking for remote opportunities to work on challenging projects in complex domains with a great group of people who have strong knowledge of DDD (Domain-Driven Design) and continuously improving, don’t hesitate to get in touch with Software Park.

Notation

The notation we used for our first session is taken mostly from the standard EventStorming toolbox. This notation box was added to the left-hand edge of the Miro board and was always available for us to refer back to during the session.

  • Event (orange) — a step in the process, phrased in the past tense. E.g. Pull Request Created
  • Role (small yellow) — the role in the team responsible for producing the event. E.g. Developer
  • Section Label (large yellow) — the name of a group of events in the process. E.g. Daily Standup
  • Hot Spot (Pink) — a step in the process that is causing pain. E.g. Flaky UI tests
  • Opportunity (Green) — an idea of how the process could be improved. E.g. Try Mob Programming
  • Question (Red-ish) — a question for clarification on a part of the process
  • Duration (Dark green-ish) — shows the amount of time elapsed between two events, typically using a min and max

Workshop Roles

In order for the workshop to be effective in a remote setting, we established the following roles ahead of the workshop:

  • The Storyteller — tells the story of the process.
  • The Facilitator — the person putting events on the wall as the storyteller was speaking. The facilitator was also responsible for asking questions and keeping the session flowing and moving in the right direction.
  • The Interrupter — the person who monitors the text chat and interrupts the story to allow someone from the mob to raise a point.
  • The Mob — everybody else. The mob are allowed to add questions, hot spots, and opportunities to the board at any time, but they can’t add or change events. When the mob wants to speak, they must type in the text chat.

In practice, the roles differed from our plan:

  • it was easier for the facilitator to put the events on the board and just allow the storyteller to tell the story
  • We didn’t need an interrupter, the facilitator was able to bring people in and out of the conversation as needed. And we didn’t need text chat at all.

Our group was six people. But for a variety of reasons there were mainly three people who were speaking. If the full team were present and everybody wanted to contribute simultaneously, I feel the interrupter role would be needed.

Process

Pre-workshop
Prior to the workshop the facilitator set out the board, and shared a wiki page giving a very brief intro to the notation and the process and a link to the Miro board.

Start of Workshop
As attendees joined the session, the board was set up with a sample timeline like the following showing an example of each notation:

Each person had the board displayed on their own screen, while using Microsoft Teams for audio communication.

Defining the Scope
Our initial session was 1 hour, so we weren’t aiming to model the entire flow (which would take days). So we focused on a part of the process we felt was most familiar to everybody.

Working in Timeboxes
After defining the scope, the facilitator set a timer for 10 minutes. The facilitator then began adding events to the board as the Storyteller was speaking. The rest of the team quickly began adding questions, hot spots, and opportunities.

Mini-retrospective
After the first 10 minutes the facilitator asked the group to share their feelings on positives and negatives.

Switching Roles
For the second timebox of 10 minutes we rotated roles and followed the same process.

Discussing the Timeline
After the second session, we began discussing the hot spots and opportunities. At the bottom of the board we created an outcomes box to capture our takeaways from the session which were added as items on our workboard.

The outcomes section from the board (these are fictitious outcomes and names not based on any real examples)

What We Learned

We gained a number of insights into how we work and how we can extract even greater benefits from Remote Team Flow EventStorming in the future.

Team Process Learnings

In a typical retrospective people raise topics at the forefront of their mind. This is very useful. But for teams who want to truly optimise the way they work, having your process visualised in granular steps raises an incredible number of hot spots and opportunities.

We also saw that there was a lack of a clear understanding on parts of the process we all thought we knew. The questions post-its that were popping up everywhere was a visual representation of the lack of shared understanding in the team.

On our board, we had more questions, hot spots, and opportunities than we had events! This was a huge realisation for everybody in the team.

Our board looked something like this with more questions and hot spots than events. We would never have realised the huge number of opportunities for improvement without this visualising them in this way.

One pattern that we observed was the “yeah me too” pattern. One person would mention that a small thing irritates and then everyone else would say “yeah I feel that way too”. Since we all realised our team mates felt this frustration, too, we felt energised to do something about it.

Remote Team Flow EventStorming Learnings

Rather than being inferior to in-person workshops, we learned that the digital version is not inferior — in many ways it’s better:

  • Lines and arrows. On a physical wall we avoid them because we can’t move them. In a digital world we don’t have this constraint! (I’m not sure how much we will use lines and arrows, it’s an open question).
  • Easy to reorganise. On a physical wall it takes a while to move a block of events along so we can squeeze in a new event. In a digital world we can select a whole section of cards and move them all instantly!
  • More Durable. On a physical wall, we can’t leave our EventStorm because other people need the wall space, or things start to fall off the wall. In a digital world we can keep our EventStorm forever and continue to work on it in the future.
  • Living Documentation. We can share our EventStorm with people in other teams or people new to the team. It lives forever and is a great tool for living documentation.

Next Steps

The feeling and the feedback from everyone in the team was positive. Next week we’ll model more of our process, refining our technique as we go along.

I’m exciting by the potential of digital tools and I’m going to be spending a lot of time making all of the techniques I use remote-optimised.

I’m now available for remote consulting and training. Topics I cover including Domain-Driven Design, Architecture, Technical Leadership, Organisation Design, Process Improvement for Self-organising Teams.

--

--

Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)