The Manifesto

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 matters.

Actually, improved community benefits process-centric development just as much as it does chaotic development.

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 sequence charts, and the like are handy as hints. The team members use 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 running the 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 who are 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 connections to the interactions of individuals. Attention to customer collaboration indicates an amicable relationship (which does not preclude conflict, as explained in 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 a contract is in place and when no contract exists. 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 time-boxed periods are in the two- to four-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

The need for different ways of working in different situations is not in the manifesto, but Jim Highsmith and I like to keep the point always in mind.

Being agile is different for a 100-person project than for a 10-person project. The agile 100-person project will use a heavier methodology than the agile 10-person project. This matches the methodology design principles presented in Chapter 4.

Of course, also in keeping with the methodology design principles, it might be possible to drop 90 people from the 100-person project, keep the 10 best people, and then run an agile 10-person project that delivers the same system in the same time frame.

The point is that we agree that methodologies do not come in ones or twos but in dozens, each tuned to the situation and project at hand, and each agile. This thought is not captured in the Manifesto.

Some of the people in the room recommend agile methodologies primarily for high-flux situations. My experience is that rude surprises pop up on even supposedly stable projects. I am still waiting to see an occasion when the agile value set is not appropriate.