DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Agile Practice and Game Theory

Agile Practice and Game Theory

Tony Siciliani user avatar by
Tony Siciliani
·
Mar. 22, 12 · Interview
Like (0)
Save
Tweet
Share
4.85K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Software development agile

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Secure APIs: Best Practices and Measures
  • Multi-Tenant Architecture for a SaaS Application on AWS
  • Create CloudWatch Custom Log Metric Alarm Notification Email Solution Using Terraform
  • 10 Most Popular Frameworks for Building RESTful APIs

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: