On Scrum, the Prisoner’s Dilemma and Nash’s Curse
Dr. Tobias Rüdiger Maier
Business Psychologist – Change Management (M.Sc.) ? Change & Senior Agile Coach ? Speaker
You probably know that Agile in general and Scrum in particular is a highly cooperative happening. Alistair Cockburn called it a cooperative game. Which brings us directly to Game Theory and the famous prisoner‘s dilemma situation.?
The prisoner‘s dilemma occurs a lot throughout our daily life. Every situation is a prisoner’s dilemma where two parties interact with the following choices of behavior: Each may decide for itself to either cooperate or to defect (= not to cooperate) towards the goal of the interaction, like in a negotiation. If both parties cooperate they achieve a win-win-situation with pretty good outcomes for both. Cooperation can mean, for instance, that you disclose some internal information, so that the other party can better adjust to your situation.
However, if only one party cooperates and the other not, then the defecting party benefits from cooperation, whereas the cooperating party gets exploited. In other words, the nice guy gives more than gets back in return, which then is a win-lose situation. Unfortunately, humans occasionally tend to exploit others. The fear from getting exploited naturally pushes both parties to defecting. The result is just a small win for both, but for sure also no loss. In that regard it‘s a garantuee for justness, though, it‘s also sort-of a lose-lose-situation since both parties don‘t achieve what they could have achieved by mutual cooperation. That‘s called the Nash equilibrium in Game Theory, according to John Forbes Nash, one of the most important contributors to that discipline. The situation about cooperating or defecting is called a game where each party decides on its move independently from the other’s because neither party knows the other’s move (strategy) till its done.
But here comes the thing: If you knew you were repeatedly in the same game with the same play-partner then you would think twice about defecting. The game partner would supposedly adjust her future behavior based on yours now. And if she cooperated why wouldn’t you do that either? In the long run, you both like to get the best out of the joint situation, wouldn’t you? The game partners remember the past moves. Watching other’s cooperative behavior would make them?more trustworthy. From that you could give it a shot and dare cooperation too. Meaning, you try to establish win-win outcomes in each round to establish a fruitful partnership. For example, A company and a supplier are bond together for delivering a service or product to the market. Together, they compete with competitors in the market, so together they‘d like to perform better than others which is more likely to be achieved through maximum cooperation. If you achieved that, why then change partner anyway?
But cooperation requires trust. You would be more likely to invest trust if you knew you still had some time ahead together. Not just one project after one negotiation, but multiple projects over years. This resonates with the Lean principle to establish long-term partnerships based on trust. A deliberate win-win-situation requires trust.
Game theory shows us that trust can only be built on long-term partnerships. The time duration of a partnership shall even be unknown to foster collaboration in the best way. We talk about the?iterated prisoner‘s dilemma. So, how to start the iterations? What strategy for your first move would be best? Well, Anatol Rapopol proposed a quite simple strategy called Tat-for-Tat: A player is cooperative in the first move and subsequently decides for the same move as the other player did in the previous round. Robert Axelrod showed in the 1980s by means of computer simulation that this simple behavior?achieves the best win-win-outcomes over time in iterated games.
Coming back to Scrum as an agile method, let‘s look at some characterists of it: There is a team whose members are meant to fully commit themselves to the team and the shared mission over a longer period of time. Every two weeks or so they play a game which is called sprint. Each team member plays the round with the rest of the team. The prisoner’s dilemma here is, for instance, who gets more or less work compared to the other team mates and considering the own skills. We would like to recognize work distribution as fair. If there’s no way to recognize this, we tend to do less to prevent our exploitation, which is defection. Obfuscating the actual workload and withholding information is defecting by in-transparency, which allows for being more relaxed on the expense of others, also known as social loafing (or social facilitating). The more members in the team behave like that, the more likely it will be that others copy it (Tit-for-Tat). No one wants to be exploited.?
So, among other factors the legendary success of high performing Scrum teams is attributed to the mutual trust they build, also including psychological safety. The trust for not being exploited allows them to cooperate. From Game Theory’s perspective this can be achieved because they play together for an uncertain number of sprints. By help of a Scrum Master they establish an open and transparent team culture. Based on that they interact on a daily basis for the sake of the mission goal. Members learn first to commit to the team?before they are able to commit to a common team goal. After a view iterations the team members sense that cooperation pays off better then defection and they start performing better as a team. Eventually, commitment to team goals becomes a reliable statement and the team establishes a stable velocity. Old story.
The aforementioned description is also perfectly fitting to Bruce Tuckman’s team phases - forming/ storming/ norming/ performing. However, the whole idea is jeopardized if we built the team with part-time members which are at the same time members in other teams too (multiple team membership). This usually happens in matrix organizations where the resource managers deploy specialized people with the required skills for a limited duration into a project group at a certain time-point. This is a task optimized way of allocating people to work and the underlying assumption is essentially known as Taylorism, leveraged by rewarding people for their individual work performance. It’s not necessarily a bad thing, it’s just not supporting maximized cooperation.
Think of it: When you ocasionally jump into a context because of your special expertise, then of course you want to accomplish in the best way what you are paid for. That is called a transaction. You need only minimum cooperation from others, if at all, to get required information, and if you don’t get it, well, then they don’t want your contribution, do they? Any cooperation from your side, like explaining others what you do, would increase your estimated time spending on the task. So, you are reluctant with cooperation. This sort of defecting behavior is naturally fostered by such organizational set-ups.
Now, rethink it: If you were permanently working together with the same guys while pursuing a common team goal, you would start thinking in terms of the team goals and how to achieve these in the best possible way. You would start asking “what is the next required task to do”, rather than waiting for the next task which fits best to your skills while doing nothing – then you would really look picky, dumb, or just useless for everything else but your special tasks. This comes with social bonding in a team: The stronger relations become the more responsible each member feels for each other and is willing to support wherever required.?
Commitment, trust and perceived responsibility are mental resources which are limited.?People that are members of multiple teams split these resources between their teams. A part time team-member has only partly trust. Trust is built by the shared experiences of the team mates. The more you are split among other teams the less shared experience you have with one team. Then it takes longer for you to build trust in the team mates and vice versa. Combined with being distributed to different locations, maybe even hidden in the comfort of the camera-off-mode, people might never build the trust that is required for establishing a high performing team. The pity is, you don’t really know what that is until you’ve experienced it. This is why many managers are satisfied with a well established transactional leadership style. As said, it’s not a bad thing, it’s just not maximizing cooperation.
So, if you were a manager, what would you require for trusting a team? If your answer is weekly or even daily status reports, well then, don’t worry, you already reside in the natural Nash equilibrium. Nash’s curse catches us all, doesn’t it?
Founder & CEO, Group 8 Security Solutions Inc. DBA Machine Learning Intelligence
10 个月Thank you for sharing this!
Business Psychologist – Change Management (M.Sc.) ? Change & Senior Agile Coach ? Speaker
1 年Fixed a few grammer and idomatic errors.