Software Development as Cooperative Social Games

Just saw a great GoogleTechTalk video with Amy Jo Kim on social games and the trends that can be seen in platforms like Twitter or Facebook. Since I love to mentally play around with abstract concepts, I started to relate it to Agile Software development and this is where I ended up with.

Game Mechanics

According to Amy Jo key aspects of game mechanics are the following:

  • Collecting
  • Points
  • Feedback
  • Exchanges
  • Customization

Let me sketch these in short for those who don’t like to view one hour of video.

Collecting is a way to express yourself. By collecting things we show what we like and spent time with. For example, personally I started to collect foreign money when I was a teenager, since the age of six I collect Mickey Mouse magazines every week, and during my active swimming period I of course collected my medals and certificates. In a social media like twitter you collect followers and maybe started to collect most recently retweets.

Points are in general everything that gives you a score on your performance. In twitter you have your own tweet counts, the number of people you’re following, or the number people that follow you. There are other third-party applications which count the number of your connections and have them put on a scale.

Feedback comes in the form of retweets or direct messages on twitter. On social sites like Software Testing Club you can also give gifts to others and get gifts in return. That’s feedback. On blogs you have the number of comments put onto a blog entry or maybe a ranking addon for your blog software.

Exchanges happen just on all the same levels as feedback. For blogs there are blogrolls for exchange or comments on user profiles in social sites. As pointed out earlier you can exchange gifts or follow someone back who started to follow you. These are all forms of exchanges.

Customization happens for certain aspect of the user interface. You can customize your profile with a neat photo or maybe a unique picture as background on your twitter profile. Some pages provide various ways to come up with these sort of customization and the longer time you spent on customizing your profile, the more you identify with it and the less unlikely it becomes for you to abandon your profile on the web.


Second, Amy Jo points out several trens in these networks, that I will introduce shortly, too.

  • Accessible
  • Recombinant
  • Syndicated

Accessible gives you a wide-open access to it. Twitter with it’s public API is a great example there. Nowadays you can access twitter using the internet through the web page UI, there are clients for the API available on nearly all platforms, and you can simply send a SMS.

Recombinant in the manner that you can recombine the key data objects in new fashions. Most twitter applications are based on this. Searching for special tags, searching for tweets from different person, the currently added list feature, … there are multiple ways to recombine the key objects on twitter (which are the tweets, simply text).

Syndicated in the sense to build peer groups. Twitter’s list feature is one way to do this. In other social networks there are interest groups, which you may join.

Cooperative Social Games

So, after having introduced the concepts as I understood them I’ll make the jump over the gap to software development methodologies, and in special Agile methodologies based on my understanding of Crystal based on Agile Software Development – The Cooperative Game, Cockburn’s Three steps of Crystal and the User Manifesto the Salt Lake City roundtable came up with recently.


When transporting the ideas from the Theory Of Constraints and Lean to Software development, Alistair considers the flow of decisions through the development project system as the key aspect. Thus, we’re mainly collecting decisions about the code we write in our projects.

There is another aspect, that we also collect. Considering the Software Craftsmanship manifesto in software development we are collecting successful projects as key assets. We collect experiences as indirect output of a software project, which we may use on the next project to come.


Despite the obvious Story points scale, there are other points to gain on each project. The number of unit tests, the number of lines of code, the number of acceptance tests passing, the number of unit tests, … In general, any second-order measurement may fit here.

On a larger scale the number of users that are happy with the product could be a helpful measurement there, too. The amount of successful projects is also a countable point based thing. Considering the long-levity of these points, though, they don’t give good feedback when comparing them to game based measures. So, the daily collected second-order measures are a better model here. Considering iterative development, the positive and negative feedback you may get during an iteration demo may suit also as a point-based measurement in the game of software development.


The major Agile development methodologies like XP or Scrum favor feedback. The three step model of Crystal transports this on another level. Not only does the Shu-Ha-Ri model of skill development on the micro-level provide regular feedback in adaptation of concrete practices, but also the continuous switching between concrete practices, the underlying principles and the self-awareness provide crucial feedback for the project to succeed.

Interestingly claim Amy Jo for feedback to be the single-most relevant practice to incorporate into the product, if one is forced to pick just one of the list. And indeed, project retrospectives and reflection workshops are the most-valued practice on any Agile project. So, continuous and timely feedback is relevant there, too. In the end, the customer’s feedback during an iteration demonstration is a good way to get feedback about the product you built the last few weeks.


Pairing activities are a great way to exchange thoughts and models. Information Radiators provide another way for exchanges. Getting back to the Lean model of software development, decisions flowing through the system are another way for exchange. Customers decide about the software feature most useful for them, hand the over to the development team and get a working product in exchange for some money.


Alistair explained this part during the open-space session at the recent XP Days Germany. He explained that the eight value statements in the Agile manifesto – the four left-handed plus the four on the right – were indeed useful as dials. You can dive into your project, getting aware of the context and then deciding whether or not you may need more documentation or more contract negotiation.

Crystal raises this on another level, though. Just in time methodology construction is the way to decide about the needs of the project and what might be relevant in a particular context. So, when there are more people on a project, light-weight techniques may need more celebration in order to foster. Given the criticality of the project, when essential money of the customer is at stake, there are other practices relevant than on a two-person project for an in-house word-processor template.

That said, software development not only is a cooperative game, but also a cooperative social game. So, let’s dive in how the trends pointed out earlier could be applied to software development.


There are limitations to the accessibility. Remote pairing nowadays becomes more and more improved, though. Last week I read about trio-programming (or triping) remotely from Enrique Comba-Riepenhausen. They put up a picture of one location on Flickr. So, accessibility seems to foster to some degree. Though, one of the Crystal principles favors Osmotic Communication, recently technology has evolved new ways for telecommuting. Lisa Crispin for example has her own navigable laptop with remote controls, which is taken to the meeting rooms from her co-located colleagues.


Recent developments for Scrum, Kanban and XP show that the recombination of methodologies works to some degree. There are good combinations just as there are bad combinations of course. In fact it is possible to combine Scrum, Kanban and XP together with Crystal by relaxing some of the underlying principles. The degree to which this still stays functional is coined to be the sweet spot of the methodology by Cockburn. So, balancing up several sweet spots from the four mentioned methodologies would give a good combination. On the other hand, taking XP and leaving out necessary practices is a very bad thing to try out, and you should at least have some understanding of what you’re doing before trying it.


I don’t dare to argue over this. There is a hard front of Scrum adopters lately, just as there are die-hard XP-practitioners. For me there seem to be silos recently with some leaders sitting in their ivory towers. Part of it started the Devline and Fall of Agile from my point of view. But these are just my 2¢.

This is as far, as I was able to play with it. Feel free to leave some comments when you played further with it.

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

Leave a Reply

Your email address will not be published. Required fields are marked *