Agile Practice and Game Theory

much of the agile movement has been influenced by scientific theories, like complexity theory, chaos theory or game theory. let's look at how the latter can be applied to software development.

game theory focuses on how groups of people interact and often compete. it is as much about outsmarting competition than fostering collaboration between "players" in the "game".

here's an example of a classic game applied to software development, simplified for the sake of argument:

two developers are working on the same project where there is no common code ownership. both developers are running late, and each one of them is struggling with a section of code where the other developer might be able to help. what should they do? here's the deal:

• if the developers don't collaborate with each other, the project will run late by a couple of weeks, and they'll each get only half their yearly bonus.
• if one developer helps the other one without reciprocity, the one getting the help will be on time and get 100% of his bonus. the helper however will be the only one running late, he will be considered solely responsible for the whole project going overboard and he will get no bonus.
• if both collaborate with each other, the project will be delivered on time, both get 100% of their bonus, and everybody wins.

question: will the two developers collaborate? the problem is, why would one developer start helping the other, when he's not sure that he will be returned the favor ?  there is the issue of trust, and the possibility that the cheater strategist will beat the altruist every time.

what we have here, is a "soft" version of the famous prisoner's dilemma , a game where two individuals won't cooperate with each other even if that is in their overall best interest.

looking closer at the issue, a couple of things make the collaboration difficult:

1. at a personal level, the reward of not helping is greater than that of cooperating . the helper could lose all of his bonus. 50% is better than nothing.
2. the developers don't trust each other because it is a one-time interaction for a "big bang" delivery .

the non-collaborative strategies adopted by the two developers is a nash equilibrium , i.e. no player gains by changing  unilaterally his strategy (i.e helping out)  while the other player keeps his (selfish) strategy unchanged . each player has made the best decision possible taking into account the other player. but the situation is not optimal for the players, nor for the project as a whole. however, while unilateral changes in strategy don't pay off, nothing prevents the players from meeting up with their managers and reaching another nash equilibrium by concerting their strategies and that would profit all parties involved.

and so it seems that acting on the above two issues, we can make the collaboration successful:

1. r eward cooperation . for example, if the project is not delivered on time nobody gets a bonus. collective code ownership ensures that all participants in the "game" are responsible for the whole project, not just the part assigned to them.
2. break the project delivery into multiple phases, or iterations and a dopt a strategy for the iterated prisoners' dilemma (ipd):  the more the developers interact with each other to produce something, the more trust can be built over the long run.

the above is a simplified, even simplistic example, but it illustrates  how software development can be seen as a cooperative game and why being agile may help with project issues steaming from non-collaborative environments.