Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster.
by Martin Fowler and Jim Highsmith
In the past 12–18 months, a wide range of publications—Software Development, IEEE Software, Cutter IT Journal, Software Testing and Quality Engineering, and even The Economist—has published articles on what Martin Fowler calls the New Methodology (see
www.martinfowler.com/articles/newMethodology.html), reflecting a growing interest in these new approaches to software development (Extreme Programming, Crystal Methodologies, SCRUM, Adaptive Software Development, Feature-Driven Development and Dynamic Systems Development Methodology among them). In addition to these "named" methodologies, scores of organizations have developed their own "lighter" approach to building software.
Formation of the Agile Alliance
On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, 17 people met to talk, ski, relax and try to find common ground. What emerged was the Agile Software Development Alliance.
A bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants. Although the Manifesto provides some specifics, a deeper theme drives many Alliance members. At the close of the twoday meeting, Extreme Programming mentor Bob Martin joked that he was about to make a "mushy" statement. Though tinged with humor, Bob's sentiments were shared by the group—we all enjoyed working with people who shared compatible goals and values based on mutual trust and respect, promoting collaborative, people-focused organizational models, and building the types of professional communities in which we would want to work.
The agile methodology movement is not anti-methodology; in fact, many of us want to restore credibility to the word. We also want to restore a balance: We embrace modeling, but not merely to file some diagram in a dusty corporate repository. We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who brand proponents of XP, SCRUM or any of the other agile methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term (a "hacker" was first defined as a programmer who enjoys solving complex programming problems, rather than someone who practices ad hoc development or destruction).
Early on, Alistair Cockburn identified the general disgruntlement with the word light: "I don't mind the methodology being called light in weight, but I'm not sure I want to be referred to as a 'lightweight' attending a 'lightweight methodologists' meeting. It sounds like a bunch of skinny, feebleminded people trying to remember what day it is." So our first task was to come up with a new adjective that we could live with. Now our processes are "agile," even if some of us are a bit creaky.
The result of this meeting (and the ensuing frenzied online interaction) was the Agile Manifesto (see sidebar). While the purpose and principles of the Manifesto were developed by the entire group, we (Jim and Martin, both authors of the Manifesto) have added, for this article, our own interpretations and explanations. The Agile Manifesto: Purpose
"We are uncovering better ways of developing software by doing it and helping others do it. We value: Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan."
This statement has a number of fascinating aspects, not the least of which was getting 17 people to agree to it. First,...