Collaborative Process Modelling with EventStorming

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.

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.

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.

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.

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

In our scenario, the grammar could map into…

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

“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.”

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.

“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.

“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.

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.

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

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.

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

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.

Related posts:

This Affiliate Marketing Accelerator Program (AMAP) is an innovative initiative designed to help individuals succeed in the field of affiliate marketing. AMAP provides aspiring affiliate marketers…