Practice Systems Thinking: 2) from Fishbone Diagram to Causal-Loop Diagram

The previous article talked about how to introduce systems thinking in product learning, and this one is about introducing systems thinking in process learning.

In contrast to product learning, practicing systems thinking in retrospectives has been more widely advocated. However, it is rarely sustained in my experience - when introducing system modeling with CLD (Causal-Loop Diagram), it might provoke much enthusiasm in the beginning, but it was seldom picked up regularly, often died out completely after a while. I reflected upon this and supposed that practicing systems thinking was too big a challenge for many organizations, as far as their current reality was concerned. Over time, I realize that RCA (Root Cause Analysis) in the context of PDCA (Plan-Do-Check-Act) could be a stepping stone to systems thinking.

Fishbone Diagram vs. Causal-Loop Diagram

Fishbone Diagram is a common tool for RCA, while CLD is a basic tool in systems thinking.

How does RCA fit into PDCA? In the above A3 report, the left part is the Plan, consisting of the following elements.

1. Theme: summarizes the problem or the improvement topic
2. Background: why does the problem matter?
3. Current condition: describes the current condition for the problem
4. Goal: describes the goal condition for the problem
5. RCA: analyzes the potential causes

Let's elaborate on the fishbone diagram commonly used in RCA.

• Problem statement is the effect, illustrated as the fish head
• There are categories for potential causes, illustrated as those main branches from the spine.
• Potential causes are written underneath the main and further branches, illustrated as layers of fishbones

How does fishbone diagram relate to CLD? The fishbone diagram is also called Ishikawa cause-and-effect diagram, layers of branches indicating causal relationships. Therefore, it has the same causal foundation as in CLD.

Let's look at the other elements in the Plan. Background describes the effect of the problem, why does the problem matter? What are the consequences of the problem? Current condition and Goal define the problem with more clarify and rigor. The problem can be stated as the gap between current condition and goal. Combining all these elements, it becomes akin to CLD.

What are further benefits through the practice of systems thinking with CLD? This reminds me of a LeSS post-course test question. "System modeling (aka CLD) is a tool used to analyze and find the root cause of a pre-defined problem" - this statement is NOT true. The explanation is "...In Systems Thinking we avoid falling in the trap of simple cause-effect thinking and understand there are always many perspective to a systems and many direct and indirect causes of problems." Indeed, by modeling all causes and effects in RCA as variables, and looking for how they interact with each other, it promotes to think of multiple causes, rather than one root cause; as well as think of leverages, rather than absolute causes.

Convert and Expand

Let's use an example to describe how to transition from RCA to systems thinking.

Here is the brief Plan:

1. Theme: adopt UT (Unit Test) practice
2. Background: Why UT? better product quality with fewer defects; higher developer productivity due to less rework
3. Current condition: few people practicing UT in our development organization
4. Goal: all people practicing UT in our development organization
5. RCA: see the following fishbone diagram

• The categories are derived from the influencer model. There are two dimensions - motivation/ability and personal/social/structural, thus, we get six categories as main branches.
• In real practice, the causes under "own bad experience" should be asked further, e.g. why not useful. Skip here for brevity.
• "..." under "others' bad experience" is the same as those under "own bad experience".

The process of converting and expanding fishbone diagram (together with other elements in Plan) to CLD is as following.

1. Derive variables from theme, current condition and goal to describe the problem. In this case, I define the variable "#developers practicing UT" for the problem.

2. Model for consequences. We derive the variables and corresponding links from background. There are two main drives for adopting UT practice - product quality and developer productivity. How does practicing UT lead to them? CLD illustrates more granular causal relationships, as shown in the below diagram.

• UT reduces defects from regression, which increases product quality as well as productivity (due to less rework).
• UT's effect on refactoring thus internal code quality is more subtle, while code quality acts as a key leverage for both productivity and product quality.

3. Model for causes. This is an iterative process. I usually take a group of related causes to convert and expand, exploring their relationships with consequences and with each other. For this example, I shall model the causes in three aspects - motivation, time and ability.

3.1 Motivation - do we have the motivation to practice UT?

• R1-loop is to increase motivation via better perceiving the value. There are actually a few similar loops here, through either higher product quality or higher productivity, while they all increase the "perception for the value of UT" thus the "motivation to practice UT".
• R2-loop is to increase motivation via peer pressure; while R3-loop is to increase motivation via organizational recognition.

3.2 Time - do we have the time to practice UT?

• B1-loop constrains the available time to write UT; while B2-loop constrains the available time to maintain UT.
• R4-loop is to reduce time pressure by having fewer defects. We invest time to do UT, but we save time by having fewer defects, can we have net saving on time?

3.3 Ability - do we have the ability to practice UT?

• "Developer skill on UT" is a key variable to understand the dynamic around ability.
• R5-loop shows often a vicious cycle - no time to learn. In fact, there are two similar ones in the diagram, causing no time to write and maintain UT, respectively.
• Thus, "effectiveness of learning UT" becomes an important leverage. Common tool/process, training/coaching are ways to improve the learning effectiveness.
• R6-loop can become a virtuous cycle to increase the learning effectiveness via peer help. In fact, R2-loop and R6-loop provide social motivation and social ability, respectively.

Do you see the advance in thinking with the expanded CLD? That's the motivation behind moving from RCA to systems thinking.

When do we do all these? We practice systems thinking as part of PDCA - we model during Plan, find leverages to Do, then update the model during Check, and design next leverages to Act. As this is on process learning, the natural fit is Sprint retrospective in Scrum as well as both team and overall retrospectives in LeSS.

If practicing systems thinking in process immediately seems too big a challenge for you, RCA could be a stepping stone. Beginning from RCA, perhaps one day we will be practicing systems thinking without notice.