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?
Interesting article. In reading the article I did not understand the connection between what you described on the beach and what you described in a team. Taking a look at wikipedia http://en.wikipedia.org/wiki/Tragedy_of_the_commons and some of the links from there, I still do not see a connection between Tragedy of the commons and what is described. What I see described are constraints we run into with most systems, that of the shared resource, or the specialist. These are not commons because they do not meet the definition of common property or open access resources that Hardin referred to. The beach is an open access resource, anyone can go there. This is not the same as shared resource, such as a documentation team. The shared resource does not have the same properties as an open access resource. The teams who need something from a shared resource have a known common interest, and the cost of overloading the system out of self interest has an immediate impact on everyone’s success. The ideas you present for managing a shared resource are great, but I don’t think this system can can be classified as a Tragedy of the Commons. The economics are not the same.
cheers,
Robin Dymond
I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize). So if you have a developer team and everyone just gets to dump tickets on to them and then whine if they don’t get what they want, when they want I see the analogy. If people can just treat a resource as though it was suppose to just serve them and the resource is overwhelmed I see that as tragedy of the commons.
There are many ways to manage that problem (some manager deciding the priority for example). Then you may have other problems but avoid the tragedy of the commons scenario.
I see agile software development as a very good solution to the tragedy of the commons problem. Of course you have to take care of other issues to make it work.
[…] Kanban and Tragedy of the Commons 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. […]
[…] Kanban and Tragedy of the Commons from Karl Scotland’s blog. Discusses how to deal with a shared constraint: buffer (a protection action), swimlanes by work type, classes of service. […]
[…] Kanban and Tragedy of the Commons | AvailAgility https://availagility.co.uk/2011/06/11/kanban-and-tragedy-of-the-commons/ […]