Kanban and Tragedy of the Commons
One of the comments on this post suggested that the tragedy of the commons wasn’t an accurate description. My comment:
I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize) the danger exists for the abuse. 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 as accurate. 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 may avoid the tragedy of the commons scenario (in reality this setup is often done, but most don’t accept the prioritizations and just expect the development team to get everything done – which means you don’t avoid the tragedy of the commons problem).
I see agile software development as a very good solution to the tragedy of the commons problem. In the blog post Karl Scotland shows kanban doing, what I see as forcing prioritization. By setting constraints on work in process we allow the resource to serve its purpose properly (instead of it being overwhelmed. To use the tragedy of commons analogy we restrict the use (grazing) on the commons (land) with a constraint (number of cows) and it isn’t overused and ruined. Without this we often see systemic problems (that are due to the tragedy of the commons really, but often blamed on developers) developers breaking good development practices (to get the work done), degrade the codebase (again under pressure to do more than can be done correctly in the current system), have people work on things they don’t understand because its needs to be done now… resulting in (along with overworked developers) a degrading the developer team capacity (burn out, frustration, technical debt buildup, turnover…) in order to meet unrealistic workloads created due to the failure to manage the capacity constraints properly.
Of course kanban takes some real effort to install in your organization. Unless the prioritization is done in some sensible way there will be problems. But if that prioritization isn’t done in some systemic way, it is still much better to limit work in progress and avoid overusing the resource. You will have a bunch of unhappy people wondering why their important thing wasn’t done, but then it is up to some manager to take the role of deciding what the priorities are not just telling all the developers to work harder, and longer, and stop making so many mistakes.
Related: Assigning Story Points to Bug Fixes – Stop Starting and Start Finishing – Positivity and Joy in Work – Build an Environment Where Intrinsic Motivation Flourishes
Pingback: Tragedy of the commons « True Lean Development
I really think this was an interesting article. It has been seen that the tragedy of the Commons refers to an economic concept that shared goods get abused. Thanks for sharing this useful information