Chapter 5. Agile and Self-Adapting

The pieces of the puzzle are in place. We have seen

• Software development as a cooperative game of invention and communication

• People as funky but good at looking around and taking initiative, communicating particularly well informally, face to face

• Methodology as the set of conventions the team adopts, with different conventions suiting different sorts of projects

• Light methodologies as delivering more quickly but having to become heavier as the team size grows

• Projects as unique ecosystems and the need for a project's methodology to fit the project ecosystem

Everything fits together neatly, except . . . How light is right for any one project, and how do we do this on our project?

"Light but Sufficient" discusses how light is right for any one project, and in particular, what it means to be too light. The target is to balance lightness with sufficiency.

"Agile" discusses the significance of certain project "sweet spots": colocation, proximity to users, experienced developers, and so on. Less-agile mechanisms must be used as the project moves further away from those sweet spots. Virtual teams, in particular, lie far from the sweet spot and so make agile, distributed development more difficult.

"Becoming Self-Adapting" describes a technique for evolving a light-but-sufficient, project-personal methodology quickly enough to be useful to the project. The key idea is to reflect every few weeks on what works well and what should be changed.

Agile and Self-Adapting

LIGHT BUT SUFFICIENT		219
	Barely Sufficient	220
	Recommendations for Documentation	221
AGILE		222
	Sweet Spots	222
	The Trouble with Virtual Teams	224
BECOMING SELF-ADAPTING		228
	Bother to Reflect	228
	A Methodology-Growing Technique	229
	A Reflection Workshop Technique	237
WHAT SHOULD I DO TOMORROW?		239