Systems Thinking Dojo

I have been organizing and facilitating the sessions of "practicing systems thinking together" for a while. The purpose is to improve the capability of practicing systems thinking together. Over time, I find it become akin to coding dojo.

"A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun and to engage in Deliberate Practice in order to improve their skills."

The dojo is solely for practice, which distinguishes itself from real performance. However, we often mix practice and performance in our domain of product development. Unfortunately, with the big pressure on from the real work, it is hard for us to focus on improving the skills. Therefore, the same could apply on systems thinking, thus systems thinking dojo.

System Modeling Dojo

In fact, the more precise name would be "system modeling dojo", as we only practice system modeling in a group. There are two aspects in "practicing systems thinking together".

1. systems thinking: system modeling with CLD (Causal Loop Diagram)
2. practice together: balance advocacy and inquiry while modeling in a group

How is it organized now? The below is the current process.

1. Before the session

• Find a topic: I solicit topics from the community - any challenges in the domain of product development that someone would like to explore with systems thinking. Over time, I maintain a list of topics and owners, and simply take the next one for the next session.
• Prepare the topic: I spend 0.5h to prepare with the topic owner, mainly formulating the topic to explore. Then agree on the time, currently having one 1.5h session every other week, evening time, online.
• Open the session: publish the session with the topic and time, open for free registration, limited for 10 people, so that everybody can potentially participate.
• Create a group: a couple of days before the session, I create a WeChat group to share the logistics - links to online meeting and virtual whiteboard, and the participants may have any pre-discussion if they want.

1. During the session

• Start with one thought: the topic owner starts by describing the problem and explaining one piece of thought for that problem. Model it with variables, links and loops.
• Invite everybody to participate: inquire for other's thought, and advocate for a different thought. There is one rule: all comments need to be connected to the model. When inquiring, point out the relevant variables, links and loops; when advocating, add or change the relevant variables, links and loops.
• closing: spend 5-10 minutes to freely comment about the experience.

1. After the session

• Further discussion in the group, but usually not much:-)
• If some people would like to continue, just suggest a follow-up or same topic and I add it into the list for scheduling, together with other topics.

This seems like deliberate practice, but there are some important differences. There are three elements in deliberate practice - specific, repeatable and feedback. We don't yet dissect system modeling into specific routines that can be practiced and improved alone. We currently practice different topics in each session, even though it is possible to repeat the same topic, the repeatability is not embedded in the design. The feedback in every session is causal and not connected to specific learning goals. We could improve in all these areas.

System Modeling Kata

Here is the definition of Kata in Wikipedia.

"Kata is a Japanese word meaning 'form'. It refers to a detailed choreographed pattern of martial arts movements made to be practiced alone."

When applying this concept into other disciplines than martial arts, kata seems having evolved into two distinctive but related things. One is the piece of routine that supports the development of certain skills; the other is the exercise that is created to practice the piece of routine. Improvement kata mostly refers to the former, while code kata mostly refers to the latter.

So, system modeling kata is:

1. the routine that we model with:

• identify a variable with proper name
• clarify the meaning of variables via metrification
• seek inward and outward links for a variable
• model a problem as the gap between current reality and goal
• identify a loop with proper name
• model a solution with balancing loop
• model a limit with balancing loop
• model a vicious cycle (deterioration) with reinforcing loop
• model a virtuous cycle (growth) with reinforcing loop
• recognize systems archetypes
• make interventions based on the leverages in archetypes
• make an inquiry by pointing out the relevant part of the model
• make an advocacy by updating the relevant part of the model
• ...

1. the content that we model for:

• topics: the below are sample topics from the past sessions.
• move towards trunk-based development
• measure and improve requirement quality
• adopt unit test practice
• continuous integration in large scale
• structure teams for both product development and project implementation work
• scenarios: the below is a sample scenario from my early systems thinking workshop.
• We move towards cross-functional team by first moving part of testing into Scrum team, while the rest still in separate testing team. In the first few sprints, we see that there are still bugs in the Done items delivered by Scrum team, while separate testing team will still catch some bugs introduced by Scrum team. People view it as proof of independent testing team?s effectiveness, thus, want to launch even more of it. We flounder in moving further towards cross-functional team.
• experiments: there are 600 experiments from the first two LeSS books. As "experiments are at the heart of LeSS; reasoning is at the heart of experiments", they are great katas. Via system modeling, we can learn deeply about the reasoning behind those experiments. This in turn improves our capability of modeling together.

Practice In Organizations

Systems thinking is an essential discipline in LeSS and learning organizations. In order to adopt it sustainably, I see three pieces that we can weave them together for the maximum effectiveness.

1. practice system modeling in dojo

• We look for existing events to stack dojos on top, e.g. various CoPs, brown-bag lunches, etc.

1. practice system modeling in work

• We do system modeling in a portion of experiments, including both product experiments (i.e. features) and process experiments (i.e. improvement actions). For product experiments, we do it during PBR and sprint review; for process experiments, we do it during team and overall retrospective.

1. practice light-version system modeling in work

• We practice impact mapping and root cause analysis on product and process, respectively. They are the light versions of system modeling, and act as the stepping stones towards system modeling. Refer to "from Impact Map to Causal-Loop Diagram" and "from Fishbone Diagram to Causal-Loop Diagram" for more details.