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…