EventStorming Team Cognitive Load Application

Mar 3

Event Storming can help a lot to align and discover a domain. I will use this technique to share how I’m thinking of the domain and, with some luck, discover things that I wasn’t aware of with your help 😄

If you are unfamiliar with Event Storming, you can find plenty of articles and books discussing it online. Here is a 2 min introduction video.

You can check the Event Storming legend at the end of the article.

This post is part of the Team Cognitive Load series. Check this out for more context.

The big picture

I started modeling how I used the team cognitive load assessment from Team Topologies to continuously know the different teams’ cognitive load to make informed decisions.

The critical part of the process was when the team members answered the survey, I collected the information and presented the results to the team.

I modeled it through three events:

Survey Answered. A team member answers the cognitive load assessment survey.
Cognitive Load Assessed. The deadline to answer the survey is reached, and we calculate the cognitive load per team.
Cognitive Load Reviewed. The cognitive load results are reviewed among the teams.

If you ask me to summarize the purpose of the Team Cognitive Load Application, I will respond that it’s about automating those three domain events.

The messy part before `Survey Answered`

Of course, more was needed to run the assessment among teams.

Who belongs to which team?
- Team Member Added to Team Event.
- Maintaining a relationship in the spreadsheet between Team Members and Teams.
How is the survey actually started?
- Survey Started Event
- Me creating a new Google Form with the Cognitive Load Survey.
Who notifies that there is a cognitive load survey?
- Survey Communicated Event
- Me sending a Slack message or an email to notify people that we have the Cognitive Load Survey running (multiple times per week…)

The messy part after `Cognitive Load Reviewed`

Several things happen after reviewing the results with the team. The main one was how we interpreted and acted on the results.

Did the impact of the previous actions on the teams’ cognitive load somehow?
Is the platform team actually reducing stream-aligned teams’ cognitive load?
What next action can we take to improve teams’ cognitive load?

Those questions can be seen as two main events.

Action Added Event. When we want to improve the cognitive load in some area, we decide to define an actionable action that should be visible in the next cognitive load assessment.
- Example: Add a Platform Team to reduce the operational cognitive load of Stream-Aligned Teams.
Action Impact Reviewed Event. After the cognitive load assessment, we reviewed whether the actions we expected to impact positively actually made an impact. So, either we mark it as done, as it needs more effort, or as it is not impacting and, therefore, it can be discarded.
- Example: Adding a Platform Team did not impact reducing the operational cognitive load on teams, but we saw an improvement in the testing experience.

DDDing Team Cognitive Load Domain app

I didn’t decide what’s core and what is supportive, but a first iteration can look like this.

I doubt whether Survey Answered event belongs to the supportive subdomain or the core domain. 💬 What do you think?

Next steps

I will start coding the application based on that modeling and share those learnings while doing it. I also have been able to chat with some folks to do a user interview to learn more about their pains.