The CooperativeGamePrinciple describes software development as a very specific type of game. The primary goal is the delivery of the system, the secondary goal is to leave enough "residue" from this round to assist the next set of players. The residue is composed of markers -- project documentation -- to get the next group "up to speed" on the problem space and the current system.

In AgileSoftwareDevelopment, Alistair talks about various balancing strategies that managers use to make sure both the primary and secondary goals are accomplished. I think he is also going to provide lots of specific content for determing how much residue is required/desirable for a given project in a specific organizational/technical context (I'm still reading in the first few chapters). This is related to the idea of JustSufficientImplementation of the code -- delivering just enough of those markers to help the next set of players, but not letting the secondary goal take too much energy from accomplishing the first.

There is another very desirable secondary goal, at least for the project manager. That is to develop the ability of the current set of players to perform even better in the next round. Many project management and software development practices overlook this critical aspect: what happens when you cross the finish line and you're team is so burned out and burned up that they aren't capable of performing well in the next race.

I've always thought of this goal as a type of "residue," the skills, attitudes, and most importantly relationships among the development team. Culture is a competitive advantage in the evolutionary struggle between development teams and development approaches.

Or is this just the goal of a completely different game called TeamManagement?

-- BillBarnett

----
Indeed, Bill has hold of a crucial part, that I keep forgetting myself, and PeteMcBreen keeps reminding me about -- the useful residue of a project includes the team!

Speaking of TeamAsRacehorsePlantOrBacterialColony, I view it as a cohesive whole (perhaps not a racehorse, but that's a pretty good place to start). The project produces code, tests, documents, AND a set of people who are now

	* more practiced at their profession
	* more knowledgeable about their problem domain
	* as knowledgeable as possible about the system design
	* practiced in working together, knowing each others' strengths and weaknesses.

These are all part of the ProjectsTacitKnowledge. Part of paying for junior people to learn is that after the project they are middle or senior people who know. It seems that both large and small projects depend on such people hanging around to remember the wheres and the whys of the system design. -- AlistairCockburn