Kanban and 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?