System mapping for teams

Hi agile community! I’m in holidays, kids are playing cards, the sun is shining, I finished some gardening and made a huge mug of tea… feel like it’s the perfect timing to write a little article and share with agile community.

This one was requested by French and Polish people, so it will be in English 😉

I wanted to talk a little bit about system mapping (more specifically “causal loop diagramming” tool) and how I use it for teams in workshops.

Where does it come from? What’s the point?

I discovered this tool during Agile France 2017, including the excellent conference Arnaud Gervais. I have I encourage you to see his full slideware on slideshare:

And here is the link to his blog post:

After this conference and the practice workshop that followed, I was really convinced of the relevance and power of this tool.

I use it in the early phases of agile coaching, when we need to better understand the current situation to identify levers of continuous improvement or transformation (which can then be used as improvement axis for the agile coaching mission if this one is on a “long-term” contract).

I animated it in workshop mode with these different phases:

System mapping workshop

Draw the map

  • Introduction to the “variable” concept
    • A variable is something that can increase or decrease
    • A variable could be measured
    • Examples : % tests coverage, team mood (it can be subjective ! even if we don’t really do it, we could imagine a survey-based system to measure the team mood, it can increase or decrease, so it’s ok to be a “variable”)
  • Identify the “Big Problem
    • “What is the issue you want to work on today?”
    • Make it a “variable”
    • Write it in a post it and stick it in the middle of a (really) big paperboard
  • Optional : the limits of the system or a problem
    • “What is the team territory, things that you own or can directly act on?”
    • Draw a big circle that represents this “territory” (it should have the Big Problem inside, otherwise it means that the team is trying to solve some else’s problem…)
  • Identify the other variables (all that can increase or decrease)
    • “What are the other variables that you feel could be linked to the Big Problem? It doesn’t have to be a direct link at all, a simple feeling that it could be related is enough.
    • Example: stability of priorities, velocity of the team, coverage of functional tests, motivation of the team, number of code reviews…
    • Optional : if think there is not enough variables on the paperboard, you can revive the creativity by broaden the question to second level
      • “Considering not only the Big Problem but any of the variables identifies so far, what are the variables that you feel could be related to any one of them?”
  • Identify the causal links + or –
    • “Draw oriented arrows to link variables that have a direct link.”
    • You can draw “+” arrows : the more A, the more B
    • Or “-“ arrows : the more A, the less B
    • Advice for an easier map interpretation: if you have the choice, try to draw only “+” arrows. Sometimes it’s easier to rephrase a variable in order to have only “+” arrows.
    • Other animation advices to relaunch creativity
      • When there is a variable with no links: “What influences A?” “What does A influences?”
      • When there is a variable with only outgoing links: “What influences A?”
      • When there is a variable with only ingoing links: “What does A influences?”
  • Delay effects
    • Some causal links have (nearly) immediate effects, others have significant delay. For example, “% team trained in test automation tools” has an effect on “team test automation knowledge”, but we know that it will take time and practice to be really efficient…
    • For links with delay effects, add two small strokes on the arrow

Debriefing / interpretation of the map

  • Identify loops (reinforcing or balancing)
    • Step back from the map
    • “Is there any loop you can see?”
    • Qualify the loops (can be highlighted in different colors)
      • If you have a loop with only “+” links or a peer number of “-“ links, it’s a reinforcing loop. Reinforcing loops can be positive cycles or vicious cycles
      • If you have a loop with an odd number of “-“ links, it’s a balancing loop. Balancing loops maintain system stability… but can also be forces of resistance to change!
  • Be careful of delay effects
    • Are they hiding the solution by providing « anti-symptomatic cures » (short terms « solutions » that enhance the problem)?
  • Identify the levers (internal or external to the system)
    • Focus on reinforcing loops
      • If you have virtuous circles (positive reinforcing loops), what are the variable involve that we have to care about so that this virtuous circle remains active?
      • If you have vicious circles (negative reinforcing loops), is there any variable directly inside the loop or indirectly connected that you could act on to try to evolve to transform it to a virtuous circle?
    • Focus on balancing loops
      • “Does this loop enhance desired stability? Or does it represent a resistance to a desired change?”
    • Focus on bottlenecks
      • Some variables are in the center of a lot of links. They may have a lot of influence on the global system.
      • “How could you act on them to have a positive effect on the global system?”
    • “Considering all this discussion, highlight the variables you want and will act on in order to improve the Big Problem and the global system. These are your levers. »

Arrows, arrows everywhere…

During the workshop, we make a first identification of loops and levers, but it is often quite complicated because the map can look like a big can of worms!

So I developed a technique to do a little more post-workshop analysis.

I use this tool: to model the map. First, the map display is often a bit easier to read than on paperboard (has it can minimise arrows crossing).

Then Kumu has the advantage of offering automatic analysis tools for social networks. Concretely, on a given network (here our map), it will identify

  • Critical points: nodes that are bottlenecks, those that are not nearly everything
    • measure « betweenness » in the tool
  • the main internal levers: the nodes that have the most influence on the overall system
    • measure « closeness » in the tool

So I run this analysis and focus on the system variables that have the highest metrics. Kumu does not automatically detect loops (one day maybe …) but considering only the most influential variables we can focus on the loops involving them as they may be the most influential on the whole system.


Then as a feedback to the team, I can present the results of the further analysis:

  • critical points considering network metrics
  • main levers considering network metrics
  • most influential loops, which tell a story:


  • levers that would act positively on the variables of these loops (and thus which represent as many ideas of improvement action for the team)


Then we can work on actions prioritization with the team according to the target state they are looking for.

It’s a lot of work … is it worth it?

You can use only a small part of this (some causal diagram mapping of a workshop for example). Doing the full exercice is time-consuming… but I think it’s really worth it.

The discussion / sharing part of the vision of the current situation is very powerful.

I always put a lot of caution on the analysis part because it must be understood that if we change even a little the system, the results may be different. But from my experience the identified loops always speak a lot to the teams and allows a systemic lighting on their problems.

It is also a communication tool to activate levers outside the system to explain to a manager for example why the team makes this request and the effect we expects.

On the communication part, there is also this little tool that is nice:

Associated with this other tool: it can allow to create nice gifs (here the influence of the work on the product vision):


But this last tool will be usable only with very simple systems, one can not model the effects delays and one can not save the realization (other than by recording the gif).

To finish some tips:

  • It works well with a problematic (the Big Problem) : be careful to align the participants with the problem
  • Differentiate the two phases: variables and link
  • Challenging the identification of variables: we must be able to appreciate the increase or decrease
  • Encourage positive formulations: poor code quality -> Code quality
  • Do not forget the effects of delays when making the links
  • Allow time for analysis!
  • Prioritize the levers / axes of improvement … because there will be many, I guarantee it !

That’s all folks!

If you wan’t to read a little bit more about system thinking and causal loops diagram, you will find a lot of ressources online 🙂

For example :


Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l’aide de votre compte Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s