Adapting Agile Approaches to Your Project Needs

T o kick off the millennium, Kent Beck wrote eXtreme Programming eXplained, with all the appropriate capitalization designed to attract attention. 1 This book and the practices behind it have had, and continue to have, a significant impact on the industry, but the book has also caused an extraordinary degree of vitriol. (For a relatively polite discussion of agile ideas with Terry Bollinger, Watts Humphrey, and others, see www.computer. org/software/dynabook.) The reasons appear to include a focus on writing programs rather than analysis or design (also known as model-ing); a disdain for documentation as such; and the Communist notion of working only 40 hours a week. XP is not the only " lightweight " method. Others include Alistair Cockburn's Crystal family, 2 now merged with Jim Highsmith's Adaptive Systems Development 3 and Scrum 4 — both mentioned in articles in this issue. These methods and others are similar to XP, but sufficiently different to cause confusion in the marketplace. Accordingly, in late 2000, Robert Martin from Object Mentor proposed that the various proponents of lightweight methods meet to form a consortium that would promote their common ideas. This proposal came to fruition in February 2001 when 16 lightweight method proponents and I met to form the Agile Alliance. (The label " extreme " was viewed as too, well, extreme, and " lightweight " was considered too, sorry, lightweight.) During the meeting, a manifesto was born and a set of principles declared. I introduced myself at this first meeting as " a spy " because my own interest has always been executable models—the notion that a model can be precise and detailed enough to be executed. Consequently, the idea that code is the only product of interest and that models are superfluous disturbs me. Certainly, we should focus our attention on the final product , but that product can surely be an exe-cutable model. I hoped to derail their evil plans. Notwithstanding my concerns, the result was the Agile Manifesto (www.agilemanifesto. org). It begins thus: " We are uncovering better ways of developing software by doing it and helping others do it. " There are then four statements of the form " We value: <left> over <right>. " The key point here is not that <right> is bad but that <left> deserves more emphasis than it often receives in plan-based processes. Let's look at the four value statements in turn. Processes …