Remote Event Storming: Distributed Teams. Same Headspace.

Why are you building an event storming app?

We get this question a lot and, as entrepreneurs, Robert and I ask ourselves this question every day.

We’re building it because we have seen the power of event storming at work with every one of our clients and in a Meetup that we ran. Event storming is one of those disarmingly simple ideas that have a huge impact far beyond business requirements and modelling. Yes, you can use it for that but to fully embrace event storming permanently alters (in a good way) the way that you think about, talk about and build the products that are the essence of your business.

As with most ideas, you could do without it and continue to build your product and run your teams as you always have. The downside is that you would have the same limitations, downsides and issues that you’re likely having now: product development and modelling takes too long, doesn’t give you the kind of flexible and extensible roadmap that you need and probably doesn’t give you much insight into how to make the product better or even why you’re building it in the first place.

What is Event Storming?

By now you may be asking, “What is event storming?” If you don’t know then read this primer. If you do, then you’ll know that event storming is an amazing process that brings teams together, gives them a collective understanding of what they’re building, why they’re building it and essentially, how to build it – without specifying the technical implementation. The approach reduces the likelihood that team members will be resentful and sabotage the process (the dungeonmasters), reduces the likelihood that silos will form and gives you fresh perspective on what you’re offering your customers and why it’s valuable to them.

“Ok, but I still don’t know why you’re building an app”, you may be saying. Those of you who know what event storming is will also know that Alberto Brandolini envisioned it and exclusively practices event storming in such a way that all of the relevant stakeholders are in the same room. It’s a hands-on, in-person exercise. The thing is, there are lots of teams that have subject matter experts in different cities or countries. Our goal is to allow those people to participate, contribute and most importantly, be in the same headspace as those who are physically in the room.

Our approach has been to allow remote participants to be able to add commands, events and documents in real-time to a shared digital event storming board.

The other thing that we’ve seen in our event stormings has been that the exercise itself is treated as a one or two day exercise. Once it’s done, the sticky notes are wrapped up on the sheet of white modelling paper and it gets thrown in a corner somewhere. Yes, people take photos of the streams and the service boundaries but that doesn’t make it easy to keep the event storming alive for the team, nor does it allow team participants to make changes as new insights arise – especially for those who aren’t in the main office, but even for those who are.

Regardless of whether team members are remote or not, StoryStream makes available a shareable, editable digital canvas which acts as “living documentation” for business intent, implementation and project planning.

It makes it easy for team members to review, to include in their requirements documents and reports. It keeps the event storming “alive” for the various teams. It can also serve as the basis for the product architecture, QA testing and onboarding new team members in order to get them up to speed.

We’ve used a precursor of StoryStream in on-site event stormings with clients a couple of other useful ways.

One of our colleagues facilitated the event storming while another acted as the recorder of the event storming as it was unfolding. This was helpful in a couple of ways. First, many if not all of the participants at most client sites have never event stormed before. The recorder (an experienced event stormer) acted not only as recorder but also interpreter of what the participants were saying and was able to help them arrive at key insights.

The other capability that we have and which we hope to automate sufficiently to include in future versions of StoryStream is to create an event sourced API directly from the digital artefact.

The Event Storming -> API builder has been incredibly useful for clients because they immediately have an API to review, test and help them determine whether what they event stormed is what they actually intended.

As event storming grows as a discipline, we feel that StoryStream can play a part in increasing its adoption, helping companies gain new perspectives on their offerings, align their teams, enhance communication and ensure that teams and companies are more effective.

Coming soon: If you want to try an early version and see for yourself how it works and provide feedback we’ll invite you to join our growing list of “early access/beta” users.