Collaborative Process Modelling with EventStorming

I am writing this one after seeing the excellent summary of Pablo Pernot, about the workshop we had with Olaf Lewitz in Ale 2022 Toulouse last week. It started like a good old friends’ reunion and felt a little like that, but we touched so many things that a summary is probably necessary on my side also.

The EventStorming formats

EventStorming is a family of workshops, based on collective storytelling with sticky notes on a large modeling surface (usually a paper roll).

• Big Picture is the largest scale flavor: it can involve quite a few people (25–30 are the typical numbers) and leads you to explore an entire business line and to end. Iteratively lets the participants visualize the storylines within their organization with Events, adding People and Systems, visualizing emerging hotspotsand boundaries, then providing a very detailed background for more value-added layers like Problem & Opportunities, or Value Discovery.
• Process Modelling introduces more rigor in the modeling, enforcing a specific grammar as part of a Collaborative Games approach, but without entering the software design arena, thus allowing both exploration and design of processes in their more generic interpretation.
• Software Design is the format that connects the dots between the events and possible software implementation, adding new elements to the grammar like Aggregates and Bounded Contexts, to allow more precision in the discussion without leaving aside business and usability concerns.

The format we chose in Toulouse was the Process Modelling, the most suitable for a tricky process like recruiting and onboarding, for a digital, possibly distributed company.

Rules of the game

The main evolution of the process modeling format has been embracing the Collaborative Games approach. It’s not a facilitated workshop, but instead a team challenge, under the condition that our team has all the necessary perspectives.

However, every game has rules, and here are the 4 rules for process modeling.

1. Every path should be completed — it should end with one or more events leading to a stable state. In the context of recruiting, they could be something like Contract Signed, but also Contract Registered. For the onboarding part, we might expect an Onboarding process completed summarizing the many Account Created and Laptop provided events.
2. Grammar must be respected — more about the grammar below, but the structure of the flow is constrained. And there’s a strong reason for that.
3. Stakeholders should be reasonably happy — meaning that we’ll explore different perspectives and different axis for visualizing value created and destroyed at any moment in the flow.
4. Every HotSpot should be addressed — dissent could be made visible, but we should try to find a possible solution for as many issues as possible.

The collaborative game approach also means that you can have some suggestions about how to play the game, but the actual strategy is your choice and depends a lot on the type of people in your team and their collaboration dynamics.

In this specific workshop, we decided to start exploring only with orange Events to then start enforcing the grammar after the team started agreeing on a basic sequence. But that’s one of the different ways to kick it off. Sometimes I just start from the beginning, or from the terminal event.

The Process Modelling Grammar

Here is a sketch of the process modeling grammar. We should be able to read it left to right more or less in this way:

Given the information available in a read model, a user decides to perform a command on a given system, that would usually result in an event. Some people could react to this event according to a given policy: “Whenever this happens, we have to do that”, but there may be automatic policies in place. Wherever necessary, a read model will provide the necessary information to support the decision.

The process modeling grammar, in the flattened version.

This is the recurring pattern, that will repeat until we hit a terminal state.

In our scenario, the grammar could map into…

A portion of the flow instantiated with the initial steps, and some spontaneous hot spots.

A tool to ask tough questions

A mandatory grammar is the structure needed to force your modeling team to ask themselves some tough questions.

• A Policy contains the decision about how to react to a specific event. It’s captured by the keyword whenever but works perfectly when challenged by the words always and immediately.

“Our interview policy is to schedule a call with the candidate ASAP”

“Do you always schedule a call?”

“No, some candidates are discarded immediately…”

“Looks like a missing First selection policy to me. Do you schedule the call immediately?”

“No, submissions tend to arrive on the weekend, but we’ll do the screening and the call scheduling from the first available working day, it usually takes 2 working days on average”

“That’s great! Maybe we can add this information to the automatic welcome message, so we can avoid calls from the impatient ones.”

Asking tough questions forced us to be a little more explicit with the screening policy (now happening only on working days) but also to have one more read model, to avoid fake promises on the welcome e-mail

Policies are important because they’re the ones that change more often. If you’re in discovery mode, this is where people won’t tell the whole truth at the first attempt. But highlighting the policies correctly could make you discover the real behaviour of your organization, and also allow for more decoupled and better designed software if you’re moving towards implementation.

• A Read Model holds the information necessary to make a decision, and the tough step to look into can be the screening policy.

“What are you looking at when screening candidates?”

“I take a look at their LinkedIn profile, even if they didn’t provide a link for it. But a major factor is also the number of typos in the application”

“Do you check other social media?”

“Can I answer sincerely?”

You get the point. Read models are another tool to open Pandora’s box, especially in a sensible area like recruiting. There are privacy concerns, equality, and a legitimate need for risk mitigation.

• a Person is a human being responsible for a given decision. It becomes more interesting when some actions are depending on the person.

“So who does the screening?”

“It used to be HR, then we discovered that we were filtering out some wrong candidates. There was this famous developer that left the old job and had dinner with our boss, who suggested submitting their application. It was discarded at screening, cause it was empty and did not mention the sponsor. Now our check lead is double-checking the discarded list, just in case.”

“How do you spot superstars?”

“Luckily, they get signaled to HR, which has a sort of list of recommended names. They can skip the annoying first steps of the recruiting process, and potentially go straight to negotiating the contract details.

One more extra policy, for the superstars: fast-track scheduling.

In general, there’ll be a lot of moving around, adding details, and rewriting. Reading things aloud will trigger the need for more clarity and precision.

Defining scope

A common question has to do with defining the scope of a specific workshop. My take is simple:

I don’t trust any scope defined outside of my workshop.

A perfectly designed process that doesn’t fit the surroundings is a massive waste compared with the hassle of writing a dozen extra stickies just to be sure that we properly framed the context.

#protip: the context is never set perfectly in advance. The workshop is necessary exactly to challenge the boundaries that were imagined upfront.

Two modeling flavors

One of the key moments of the workshop has been recognizing the need for two complementary modeling styles:

• a fuzzy modeling style dealing with uncertainties, and many possible alternative orders for things happening, suitable for design and negotiation processes, for example.
• a more mechanical modeling style, for the procedural portion of the flow.

In our scenario, the recruiting and contract negotiation had some steps, but every conversation could be a possible violation of the default sequence: salary could be discussed at any moment, or a wrong comment could make both sides decide to quit the discussion. After the contract is signed, we expect the onboarding process to run as smoothly as possible, providing a welcome pack, credentials, and a working desk if we are still in the office.

Technical people tend to be more effective in the mechanical, downstream side without recognizing the need for a different style — sometimes a checklist is all the process we need — in the more open-ended part.

Belated thanks

I really enjoyed the workshop — working with Pablo Pernot and Olaf Lewitz doesn’t feel like working — and I loved the entire Ale 2022 edition (Kudos to all the organizers, special mention for Rachel DuBois and Anne Gabrillagues)

Want to know more?

If you’re curious about EventStorming, then Eventstorming.com could be the place to visit. I provide training and consulting services through my company Avanscoperta (here is the link to the next edition of the EventStorming Masterclass, which appears to be sold out).