Kanban and Tragedy of the Commons

After Limits to Success and Shifting the Burden, we now come to Tragedy of the Commons.

I live in the seaside town of Brighton in the UK. On the rare weekends when we have hot weather it is popular to go down to the beach. Everyone gets in their cars and drives into Brighton expecting a quiet, relaxing day on the coast. What they actually get is a noisy, crowded area full of lots of other people who have had the same idea. This is an example of the “Tragedy of the Commons” archetype. The beach (and the roads to it), are the commons – a shared resource. Individually, each person expects to gain some pleasure from the beach. However, when too many people visit, nobody gets any pleasure from the beach, because it has limited capacity and quickly becomes over-crowded.


Individually, A and B’s activity give themselves separate net gains so that they each benefit through a reinforcing loop. However, their activities combine to create a total activity which, after some delay, eventually consumes a common resource beyond its limit. At that point, A and B’s activity begins to reduce those separate net gains through a balancing loop.

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

Often, a Tragedy of the Commons occurs as a result of Shifting the Burden to the commons. By setting up the system to deal with the Shifting of the Burden, the likelihood of the Tragedy of the Commons can be reduced.

Similarly, the commons becoming overloaded is a specific case of Limits to Success, and setting explicit limits for the commons will avoid this. Further, creating a buffer before the commons will ensure that there is always work when the capacity is available. In Theory of Constraints terms, this is exploiting the constraint.


A kanban system also helps with a Tragedy of the Commons by helping visualize the total activity, so that everyone is aware of the demand on the limited resource. Further, each party can limit their own activity to avoid the total activity becoming too great. Swim-lanes are one approach to visualising this.


Finally, Classes of Service can then ensure that the limited resource is being used effectively for the most appropriate work. Swim-lanes, or colour-coding, can create clarity of which work is more important, based on its Cost of Delay. This clarity can also help keep an appropriate balance of different types of work in order to manage the risk of the commons unnecessarily delaying urgent work.


What other examples of Tragedy of the Commons have you experienced, and what other techniques have you used to visualise them?

Kanban and Shifting the Burden

Following on from a look at the Limits to Success system archetype, lets now look at the Shifting the Burden archetype.

I like my coffee in the morning. In fact I usually need a good cup of coffee before I start to feel human. Some days I like a coffee to start the afternoon as well, and occasionally I’ll have a few more in-between to keep me going. This is an example of ‘Shifting the Burden’ archetype. I feel low, so drink coffee to pick me up. However this is just a short term fix and I eventually need more caffeine to maintain my energy. The real problem is why I have low energy; late nights, a poor diet and little exercise. Rather than getting more sleep, eating a healthier diet, and exercising, I am shifting the burden to the caffeine. If I were to shift the burden to a stronger (and less legal) drug, then it is likely that my need for the drug itself would become the problem, rather than my lack of energy. At this point, the archetype has moved from Shifting the Burden to Addiction.


Shifting The Burden begins with a Problem Symptom. The quick or easy answer to this problem is the Symptomatic Solution which creates a balancing loop. However, there is also another answer – the Fundamental Solution – which can create an alternative balancing loop. The Symptomatic Solution only eases the symptom though, and doesn’t resolve the underlying problem, so the symptom consistently returns. The Fundamental Solution does address the root cause, but has a delay though, which means that it is more of a long term answer than a quick fix. The more the Symptomatic Solution is applied, the more a Side Effect takes place, which over time with delays reinforces the need for the Fundamental Solution, while at the same time making it less feasible. When the Side Effect becomes more of a problem than the initial Problem Symptom, is when the Shifting the Burden archetype becomes one of Addiction.


Recognizing the archetype leads us to examine our solutions to problems and to question whether they are Symptomatic or Fundamental. When problems re-occur over time, then using Root Cause Analysis techniques may lead to finding alternative Fundamental Solutions. Continually depending on technical specialists or coaches may be a Symptomatic Solution, whereas investing in training on knowledge sharing may be a better Fundamental Solution. As the well-known Chines proverb says, “give a man a fish and he will eat for a day, teach him how to fish and he will eat for a lifetime”

A Kanban System can help cope with Shifting the Burden, once a problem symptom has been identified, in the following ways:

  • Signalling occurrences of the identified problem symptoms so that they are transparent and appropriate focus can be made on the fundamental rather than symptomatic solution. A brightly coloured tag or shape can achieve this.


  • Visualizing what problems symptoms are being addressed by various symptomatic or fundamental solutions. The Concern, Containment, Countermeasure pattern can be useful here where problem symptom is defined and stated as a Concern. The Containment action is the symptomatic solution taken to resolve the problem quickly. Then, after root cause analysis, the Countermeasure action is the fundamental solution to prevent repeated recurrence. (Thanks to Jason Yip for pointing me to this pattern)


  • Allocating capacity and limiting work in process for work related to fundamental solutions using a dedicated swim-lane and WIP limits. This treats the improvement efforts as first class work types, with equal visibility to the rest of the work.


What other examples of Shifting the Burden have you experienced, and what other techniques have you used to visualise them?

Kanban, System Archetypes and Limits to Success

In a previous post I introduced the idea that Kanban can play a role in Systems Thinking and understanding System Archetypes. In this post I’ll describe system archetypes in some more detail, and describe the Limits to Success archetype.

Balancing Feedback

Balancing feedback will stabilise a system’s behaviour. For example a thermostat is a balancing feedback system where the temperature is measured, the difference from the desired temperature measured, and a heating or cooling device adjustment made accordingly. This can be depicted as below, with the B identifying the loop as balancing. When the temperature is higher than the target, then the adjustment is to generate cold air. When the temperature is lower than the target then the adjustment is to generate hot air.


Reinforcing Feedback

Reinforcing feedback will amplify a system’s behaviour. For example a bank account is a reinforcing feedback system where you have an account balance, onto which an interest rate is applied, and as a result you have interest paid to increase the balance (assuming your bank pays you interest). This can be depicted as below, with the R identifying the loop as balancing. As the cycle continues, more and more interest is paid, continually increasing your account balance. Conversely, when you have a negative account balance, your bank might apply a charge, which is deducted from your balance (much more likely). This cycle will continue as your account goes into increasing debt.



What makes systems complex is that there are often delays in the feedback loops. Delays separate cause and effect over time which often leads to instability and oscillation. For example, how many times have you been in the shower and tried to adjust the temperature, only to find the water suddenly get too hot or cold? This is due to a delay in the action of adjusting the temperature, and the temperature actually changing. As a result we tend to over-adjust and get burnt or chilled.



Most systems are not as simple as these examples, and consist of combinations of balancing and reinforcing feedback loops with different delays. However, a system’s particular structure will result in its behaviour being constant over time, and systems with similar combinations result in similar behaviours. These patterns which cause similar and recognisable system behaviour are known as system archetypes.

Being able to recognise system archetypes helps to identify the cause of behaviours, and gives insight into how to break (or encourage) the archetype to our advantage. Let’s take a look at an example.

Limits to Success

The Limits to Success archetype can be depicted as below.


To improve performance of a system, more efforts are made, which do lead to the anticipated improvements, creating a reinforcing loop. However, after some time the performance reaches a limit and resistance creates a balancing loop, leading to the performance levelling off, declining or even crashing.


Recognising this archetype leads to the understanding that when the systems resists, or pushes back on attempts at improvement, then rather than continuing to push the reinforcing loop, and increase efforts or do the same thing better, we should look to remove the limits by adjusting the system design to delaying the balancing loop. In other words, deal with the limits before the system does. The system’s limits will result in a worse outcome.

A Kanban System can help to cope with Limits to Success in a couple of ways. Firstly, setting explicit Work in Process limits is a way of directly limiting the system before the system does so itself, avoiding the decline or crash in performance. Secondly, gaining transparency of the work and the workflow is a beginning to learning what the cause of the limiting factor is. Visualising any bottlenecks or impediments gives a good indication of where to start looking to make changes in the system design.