The Project Game

After reading A Theory Of Fun, I started seeing projects (and many other human activities) modelled as a game. In the book, Raph Koster describes a series of game development rules, and I found that they can be mapped to the software development project domain with some interesting results:

  • A project, just like a game, has roles. In projects, they’re specific to each role. These rules define the possible actions for each of them. (This one isn’t described in the book, but I added it just to contextualise.)
  • Role-specific rules should be unambiguous, intelligible and apply to all people in that role.
  • No project can be developed without the meaningful interaction of the people in all roles.
  • The outcome of a project has to be uncertain, otherwise it loses its appeal.
  • Rules and representation of a project are not independent but interact with each other.
  • People require clear and immediate feedback to understand the relationship between action and outcome.
  • People require a clear goal so they can perform meaningful actions within the project world.
  • Conflict and competition against time, budget and scope are essential for everyone’s motivation.
  • The challenges of a project should match the skills of the people involved: neither too easy (boring) nor too difficult (frustrating).
  • Projects can be developed without the need for even skill sets among the team. Instead the people learn through interaction, and this should be allowed and encouraged to happen.
  • People perform actions within the project world and observe how these actions change the state of the project.
  • People form a hypothesis about the meaning of a deliverable or action on the basis of their studies.
  • People recognise and learn fundamental patterns within the project and can apply these to different situations (and, of course, other projects).

The more I look at these, the more this matches the way I see people working in agile projects. I’m sure there’s a lesson to be learned here…