May 2022 Archives

Systems Thinking Dojo

dojo.jpg

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.
  2. 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.
  3. 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
    • ...
  2. 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.
  2. 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.
  3. practice light-version system modeling in work

Productivity Focus

It seems that product development organizations care about productivity the most. This is reflected by the common misunderstanding about adopting agile development for higher productivity while agile development is about flexibility and adaptiveness. In this article, we will take a look at why focusing on productivity is often not a good idea, and surprisingly, focusing on others, such as value, quality, speed and flexibility, eventually leads to higher productivity.

There are a few challenges for productivity focus. Firstly, what is the measure of productivity? For knowledge work, it is not as simple as counting the number of items produced in the factory. We have tried the lines of code, the number of features, and so on, produced per time unit. These are useful to some extent, but focusing on them often leads to local and short-term optimization. In order to deliver more features or lines of code, we select only those familiar features or tasks, and we take shortcuts. We may get higher productivity in the local view and short term, while we suffer in the whole and long term.

What are other focuses in product development organizations? Let's look at value, quality, speed and flexibility, as well as how they relate to productivity.

Value vs. Productivity

This is about outcome vs. output. Outcome is the value, while output is the feature. Usually, we define productivity in terms of output. There is a sense of futility when talking about that we should focus more on outcome. Everybody on the development side agrees easily that this is a major problem, but unfortunately they can't do anything about it.

The silo between product/business and development seems the thickest and deepest, however, this is also where change can have the most leverage. We simply develop too much low-value stuff, partly because it is inherently difficult to identify value, partly because that we are not disciplined enough while exploring and validating value. By the way, agile product development is supposed to increase our discipline via short feedback loop. If we can stop developing half of the low-value stuff, we will have more time to develop those high-value ones with higher quality.

Quality vs. Productivity

It is common that development organizations sacrifice quality in order to meet schedule. The productivity seems improving in the short term, however, productivity deteriorates further in the longer term, exactly because of bad quality. How do we respond by then? We sacrifice quality even more. This is perhaps the most ubiquitous vicious cycle in our industry.

We seem always lacking time to produce quality, but always having time to fix quality. While the defects shipped to users impact quality, the defects found then fixed internally impact productivity. Actually, as there is no easy way to directly measure productivity, I usually suggest to take the number of internal defects as one of the proxies for productivity, because it indicates rework. So, instead of sacrificing quality for productivity, we ensure quality for productivity. In my old days as the quality manager, there was tremendous pressure on meeting schedule in our organization, and my favorite comment was "when we focus on schedule, we don't meet schedule (as our quality suffers, then schedule slips further); while when we focus on quality, we meet schedule too".

Speed vs. Productivity

People often mix up these two concepts - speed and productivity. When they say that they want to go faster, they really mean that they want to produce more. The former is the speed in terms of cycle time, and the latter is the productivity in terms of throughput.

The end-to-end cycle time is critical for product development, not only because it decides when the value is delivered to end customers, but also because it decides when we get feedback for adaptation. How can we reduce cycle time, even with the same throughput? By focusing on the high value work and limiting WIP.

efficiency matrix.jpg

In the book "this is lean", it introduces the above efficiency matrix, which distinguishes flow efficiency and resource efficiency. Behind it is customer focus (speed) vs. resource focus (productivity). Interestingly, the strategy advocated in the book is first focusing on flow efficiency. As improving flow efficiency can reduce a lot of superfluous work and waste, it improves resource efficiency too.

Flexibility vs. Productivity

In my experience, flexibility is not something most organizations focus on, even though It is the means to maximize value in uncertain environment, thus the essence of agile development.

Over-specialization in various dimensions is probably the biggest obstacle for flexibility. It is perceived more productive to keep working in specialized areas, however, it is a local optimization, leading to delivering many features with low value - rarely or never used; or even worse, high amount of WIP - partly done features never delivered to users. How do we break down the over-specialization? Via multi-learning. I have described this topic in the series "Number of backlogs and multi-learning". Although multi-learning is aimed for flexibility, the broad knowledge coming out of it also enables more effective collaboration and integration, which helps productivity as well.

The focus on learning s worth further pondering. Don't we need to learn and improve in order to get more productive? Indeed, if our focus on productivity means the focus on learning, then, it is a good idea. We train and coach developers to write clean code and tests, and help them adopt modern engineering practices. However, this is not what most people usually mean when talking about productivity. Upon a bit reflection, it is common that focusing on productivity means to deliver more by adding more pressure and working longer hours, rather than learning and removing impediments.

In summary, if the productivity focus means to help developers learn and improve, go for it! Otherwise, we'd better focus on:

  • value: because only doing high-value work, we have the time needed to do our job properly
  • quality: because producing fewer defects, we have less rework
  • speed: because flowing better, we have less waste
  • flexibility: because expanding knowledge scope, we have more effective collaboration and integration

then, productivity takes care of itself.

About this Archive

This page is an archive of entries from May 2022 listed from newest to oldest.

April 2022 is the previous archive.

June 2022 is the next archive.

Find recent content on the main index or look in the archives to find all content.