The Swamp Game


Rock climbing has one limitation when used as a metaphor for software development: When people finish a rock climb, they walk back down to their cars and drive off. When people finish a software project, they stay around and enhance the system or build the neighboring system. They have to live with the results of what they did, and they have to integrate other people into the world they created.

There is an activity that is closer to software development than rock climbing. It is an imaginary activity for now, but who knowspeople may really start playing this game or simulating it in a SimCity-like computer game to train project leaders.

Imagine a competition in which each team must build something somewhere in a swamp. They don't know exactly what they have to build, they don't know where they have to build it, and they don't have a map of the swamp, but they are in a race to build it. They will create subteams. Some will scavenge for building materials, others will explore the swamp, and so on. Note that this corresponds to people finding different specialties in software development.

If they have to play only one round of the game, they will find it optimal to build the weakest, sloppiest bridges and to draw the most careless maps possible to get to the end of the game. However, if they know another team will be coming in after them, they may choose to make better maps, better bridges, better paths. This difference between strategies corresponds to a software project team updating their system documentation and training their junior people.

It is this difference in strategies that makes the swamp game a better metaphor than rock climbing. Every software project contains a carryover to the next project, so the strategies to use in software development should pay attention to both this game and the next game.

Observe that people are part of the carryover from one round of the game to the next. In an ideal world, the team would ensure that none of the original team would leave. These people carry a lot of tacit knowledge in their heads, information that can't be put into the paper documentation (this is the exact point made by Peter Naur in Appendix B). However, in a real-world setting, people flow into and out of the team. The team's strategy needs to include ways to transfer as much knowledge as possible to the arriving people.

The swamp game lets us explore in our heads different strategies the teams might use and map those strategies to software development:

  • We can imagine keeping the original team intact for as long as possible.

  • We can imagine junior players on one round becoming team leads on the next round.

  • We can imagine using an apprenticeship model to train new people joining the team.

  • We can imagine making the paths and bridges weak on the first round but taking the time to improve them on subsequent rounds (think here of refactoring code in subsequent releases).

The good news is that delivering the result in the current round is a finite task. The bad news is that setting up advantageously for the following round is essentially an infinite task: There is never enough time, money, staff, or mental and communication capacity to do it perfectly.

This tells us why the documentation and training never seem to be satisfactory at the end of a project. Project managers always feel like they are underresourced, and they are. They are trying to balance finite resources across a finite task plus an infinite task. They will always come up short.

The trick is not to aim for perfection but to construct strategies that serve a useful purpose in getting to the next move or round of the game.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net