Arie van Bennekum, from the Netherlands, represented DSDM (Stapleton 1997).
Andy Hunt and Dave "Pragmatic" Thomas, authors of The Pragmatic Programmer, protected the interests of experienced programmers who have no affiliation to any one method.
Brian Marick represented the software testing perspective.
Stephen J. Mellor was there to protect his interests in model-driven development. He was perhaps the most surprised to find himself able to agree with most of what was said, and signed both the manifesto and the principles.
There were others who had been invited, and would certainly have contributed and signed, but those were the people who were there, argued, crafted and signed the agreements.
We hoped against hope that we would actually agree on something.
None of us was interested in merging the practices to create a "Unified Light Methodology (ULM)." Given the individualism in the room, it was actually surprising we agreed on anything.
We agreed on four things:
· We agreed at the first level, on the need to respond to change. We agreed that agile reflected our intent, and permits discussion of heavier-agile methodologies for larger and life-critical projects.
· We agreed at the second level, on four core values, as described in the manifesto.
· We agreed at the third level (just barely), on twelve more detailed statements consistent with those four values.
· It was clear we would not agree on the fourth level, detailed project tactics. We did agree that this was healthy for the industry, and that we should continue to innovate and compete in the world of ideas, to discover a larger set of agile software practices.
With those agreements and the adoption of the term agile, the 17 people created the Agile Alliance.
Let's look at the wording of the manifesto more closely.
"We are uncovering better ways of developing software by doing it and helping others do it."
We (the people in the group) are software development practitioners, not merely onlookers making rules for others. We feel that we have "uncovered" practices more than invented them, and want to be clear that we will continue to work by helping as well as by telling.
"Through this work we have come to value..."
The ideas were not arrived at in a vacuum, but rather are an outcome of our direct experience and reflection on that experience.
Before listing the four choices, I'll skip ahead and look at the closing sentence:
"That is, while there is value in the items on the right, we value the items on the left more."
We are not interested in tearing down the house of software development. We recognize that tools, processes, documentation, contracts and plans have value. What we wish to express is that when push comes to shove (which it usually does), something has to give. We feel that people who hang onto the right hand choices in the list will not do as well as people who hang onto the left-hand choices.
We also want to recognize that some people disagree with one or all of our choices. One person said, on seeing our list: "I can agree with three of the four." We agreed that that sort of disagreement can lead to constructive conversations.
There is no "opposite" to agile methodology, just as there is no opposite to "Bengal tiger". There are alternatives to agile methodologies, phrased according to their own value systems: repeatable, deliberate, predictable, even capricious methodologies.
Understand, of course that all of these denote the successful version of the practices. Perhaps
better terms are: would-be-agile, would-be-predictable, and would-be-repeatable development.
It is important to me, personally, to leave room for disagreement on these matters. Our industry still disagrees about what is critical to successful software development. The best approach for the time being is simply to say what one stands for. Evidently, this point is important to the other signatories, too.
With that in mind, let's look at the four choices:
"Individuals and interactions over processes and tools."
The first value is attending to the people on the team as opposed to roles in the process chart. Although a process description is needed to get a group of people started, people are not plug-replaceable, as we have seen.
The second choice being highlighted there is attending to the interactions between the individuals. New solutions and flaws in old solutions come to life in discussions between people. The quality of the interactions matter.
Actually, improved community benefits process-centric development just as much as it does chaotic documented.
What this first value expresses is that we would rather use an undocumented process with good interactions than a documented process with hostile interactions.
"Working software over comprehensive documentation."
The working system is the only thing that tells you what the team has built. Running code is ruthlessly honest.
Documents showing the requirements, analysis, design, screen flows, object interaction sequences charts and the like are handy as hints. The team uses them as aids in reflecting on their own experience, to guess what the future will look like.
The documents serve as markers in the game, used to build an image of the unreliable future.
On the other hand, the composite act of gathering requirements, designing, coding, and debugging the software, reveals information about the development team, the development process, and the nature of the problem to be solved. Those things together with the runing final result provide the only reliable measure of the speed of the team, the shortcomings of the group, and a glimpse into what the team really should be building.
Documents can be very useful, as we have seen, but they should be used along with the words "just enough" and "barely sufficient."
"Customer collaboration over contract negotiation."
The third value describes the relationship between the people who want the software built and those building the software. The distinction is that in properly formed agile development, there is no "us" and "them," there is only "us."
Collaboration deals with community, amicability, joint decision making, rapidity of communication, and connects to the interactions of individuals. Attention to customer collaboration indicates an amicable relationship (which does not preclude conflict - see Chapter 3) across specialties and organizational boundaries. Saying, "there is only us" refers to the fact that both are needed to produce good software.
Although contracts are useful at times, collaboration strengthens development both when there is a contract in place and when there is none. Good collaboration can save a contract situation when it is in jeopardy. Good collaboration can sometimes make a contract unnecessary. Either way, collaboration is the winning element.
"Responding to change over following a plan."
The final value is about adjusting to fast-breaking project changes.
Building a plan is useful, and each of the agile methodologies contains specific planning
activities. They also contain mechanisms for dealing with changing priorities.
Scrum, DSDM and Adaptive Software Development call for timeboxed development with reprioritization after (not within) each timebox (XP allows reprioritization within the timebox). The timeboxed periods are in the 2 - 4 week range. The timeboxing guarantees that the team has the time and peace of mind to develop working software. The relatively short development phases, what Scrum calls "sprints," allow the project sponsors to change priorities to match their needs.
Building a plan is useful. Referring to the plan is useful until it gets too far from the current situation. Hanging onto an outdated plan is not useful.
Reflecting on the Manifesto