And here's why you need to understand it in order to understand "agility at scale."
Before we get started, though, let me explain the dilemma:
The Tragedy of Commons
Imagine there's a huge, pristine green pasture. The lord of the land has decreed that everyone is free to use this pasture for shepherding their flock.
The first shepherd who arrives finds a vast green pasture, and the flock is happy to graze on the fields.
Soon afterwards, another shepherd arrives, and their sheep graze happily on the lush pasture as well. Both shepherds are happy, as their sheep have ample food to eat.
In the excellent conditions, the flocks multiply.
As the flocks grow, there is no longer an overabundance - the sheep of the two shepherds begin competing for food. The first shepherd's sheep had more time to multiply, and the second shepherd's sheep lack the required conditions to multiply freely.
Both flocks compete over increasingly scarce food: the sheep lack nutrition and are threatened from starvation. The first shepherd feels that the second shepherd's presence has caused this threat to their flock. The second shepherd considers the first to be using their unfair advantage of having a bigger flock to drive them off the pasture. Quarrels arise.
The feudal lord settles the dispute by dividing the once lush green pasture into an allotted segment for each shepherd, based on the size of their flock. Both shepherds now have access to less land than they could access before - but each now has full control over their flock.
Should the lord have settled the dispute in this way? Should the lord have found another solution? Take some time to think. What would have happened - had the lord not intervened?
Tragedy of Agile Commons
There are many, and massive, applications to the Tragedy of Commons in the realm of software systems - moreso in scaled environments. In the land of Agile, they're much more visible than in the land of Waterfalls, where the lots are already divided before they exist: Agile teams incrementally and empirically discover their next best move based on where they are today - perfect preconditions for the Tragedy of Commons.
Common Code
Teams who haven't learnt discipline in code will find it highly irritating to see one developer interfering with another developer's code: "my" coding style is always better than "yours."
Quickly, quality problems begin arising on the Common Codebase: quarrels over style, functionality placement, inconsistencies and many others.
As more and more developers enter the scene, the tendency for code silos built around personal preference, coding style, technologies, or even domains increases.
Whereas one team can often be left to freely roam the green pastures of service implementation, the field quickly turns into a brown quagmire when multiple teams all play their preferences, until the code base becomes entirely unworkable.
Once teams build fences around their codebase, Collective Code Ownership becomes a thing of the past, and Component Teams find themselves entertaining a dreadful nightmare of coordination meetings.
Better approaches could be:
- code conventions
- linting rules
- cross-team Pairing sessions
- Code dojos
- Continuous Integration / Continous Delivery
- but these things are all topics large organizations struggle with after the code has been divided into silos.
Common Innovation
A green field project is often a great way to introduce new, more powerful technologies that allow teams to do less with more.
As the development organization matures, and standards begin to shape the landscape, new ideas becomes exotic and marginal, struggling to overcome inertia.
Imagine - just for example - introducing agent-based logic into an architecture driven by RPC's and SOAP requests: There will be few takers for such an innovation.
The Tragedy of Common Innovation is that new ideas have to find a really small niche when the field is already taken by old ideas. Many good ideas go extinct before they can catch a hold.
With a constant decline of innovative ideas, organizations eventually find themselves investing massive efforts into servicing outdates ways of working and technologies, incapacitating their ability to deliver high value to the customer in the same ways others do.
Better approaches might be:
- innovation allotments
- hackathons
- innovation sessions
- innovation champions
- cross-team collaboration on innovation
- intrapreneurship
Common Meetings
Have you ever been in a 2-hour meeting with 40 people? Did you ever pay attention to how many people actually speak? Hint: it's most likely not an even distribution.
Small organizations find their meetings very effective, but as more and more people appear on the scene, meeting effectiveness quickly declines. And there's a reason.
In an effective 3-people, 1-hour meeting, every person gets to speak roughly 20 minutes. That's a lot of time to voice ideas, offer feedback and draw conclusions. That's a 33% activity ratio. And everyone has pretty much the same understanding afterwards.
When we constrast this with a 30-people, 2-hour meeting: Simply by dividing clock time, we see that every person gets to speak an average of 4 minutes, while being forced to listen for an average of 116 minutes: The ratio of ideas contributed versus passivity is staggering for each individual - the activity ratio has dropped to a mere 3%! In such a scenario, the tragedy of common meetings becomes that some of the more experienced people take the stage, and everyone else becomes decoration.
Solution approaches might be:
- focus sessions
- using a need-to-know principle
- Law of Two Feet
- breakout sessions
- topic ownership
Specialisation also removes the need for everyone to participate in all discussions.
The tradeoff is mainly between not everyone getting firsthand information and people suffering through hours of only marginally relevant meetings. To any solution, there's a downside.
Common Work
A single developer can work on any code at any time, and there will be no unpredicted side effects like merge conflicts caused by others' work. Small teams will usually learn quickly how to coordinate so that they minimize mutual interference.
Without good engineering practice, delivering a larger, integrated piece of software means lots of simultaneous changes in many places. Teams will either get into a Riverdance of constantly stepping on each other's toes, or they will require so much coordination that things get really messy. Of course, the "solution," is - once again - code silos and dependency hell: productivity tanks as risks and delays rise skywards.
Every developer joining an organization that hasn't managed to deal with the Tragedy of Common Work adequately, will make every developer's productivity decline - up to a point where the net productivity gain of hiring additional developers may be negative, i.e. with each new hire, the organization gets less productive overall!
Potential solutions could be:
- visual dependency management
- domain separation
- decoupling
- joint roadmap planning
- cyclical synchronisation points
- communication by code
Now what?
These are just four examples of how the Tragedy of Commons matters a lot in a Scaled Agile setting, and there are a vast number of potential commons.
Regardless of whether an Enterprise is new to agile ways of working or have been doing so for a while: you need to establish overarching rules that mitigate the conflicts, lest you run afoul of the Tragedy of Commons.
The "Tragedy of Commons" is entirely evitable in a holistic system where every participant sees themselves as an integral part of the whole. The solution is coexistence and collaborative conflict resolution rather than competition.
Ground rules address unregulated, harmful growth, a lack of discipline, and myopic actions, but each rule comes with a drawback: it reduces flexibility. While Team Autonomy needs boundaries where these are for the Greater Good, it's important to set these boundaries wisely, and revisiting these where they aren't useful. That can't be done by only one group - in a common system, it has to involve all those whom it concerns.
Which boundaries will you set to prevent your organization from suffering the Tragedy of the Commons, and what is their cost?
