The Agile Manifesto is the product of 17 smart, well-meaning developers who met in February 2001 to discuss problems in software development. The list of developers included Kent Beck, Alistair Cockburn, Martin Fowler, Ron Jeffries, Robert "Uncle Bob" Martin, and Dave Thomas - people who have all made substantial contributions to software development.

During the three days the group met, they spoke of the frustration they had with writing software and found a great deal of common ground. From their discussions, the Agile Manifesto emerged in its current form.

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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

"Agile programming" is the name given to any methodology that subscribes to the Agile Manifesto. The most well-known example of agile methodologies is the set of 12 principles stated by Kent Beck in his book, Extreme Programming Explained: Embrace Change. In this article, I'll explain what Extreme Programming (XP) is and why I think it is so profoundly wrong-headed.

Beck states that XP is founded on four "values": communication, simplicity, feedback, and courage. Beck says that these values are worked into the following XP practices:

• Test-driven development requires that tests be written before the software is written.
• The Planning Game is used to derive "user stories" - extremely brief reminders to the developers to have more in-depth conversations with the customer.
• Whole team (previously "on-site customer") requires a continuously available customer to answer questions. This is necessary since XP "requirements" are so vague as to be almost nonexistent.
• Small releases assure that every 1-3 weeks a new version of the developing software is released.
• System metaphor provides a way of thinking about the application that takes the place of a documented system architecture.
• Simple design is guided by the aphorism: "Do the simplest thing that could work." Developers are highly discouraged from actual system architecture, which the extremists pejoratively term "Big Design Up Front."
• Emergent design is the hope that an overall system architecture will slowly coalesce, based on individual design decisions and an understanding of the system.
• Refactoring is the process of rewriting code as more requirements are introduced and the overall design "emerges."
• Collective ownership prohibits individuals from owning code. Instead, developers are encouraged to make changes to (refactor) code written by others in an attempt to ensure that the best software is written.
• Pair programming requires that all production code be written by a pair of programmers working on one computer.
• Continuous integration eliminates the problems of late integration by integrating code several times a day.
• Sustainable pace forbids developers from late-night pizza and Mountain Dew sessions, insisting that developers work no more than a 40-hour week.
• Coding standards, the last of the XP practices, make all the other practices easier to implement.

"If code reviews are good, we'll review code all the time (pair programming). If testing is good, we'll test all the time (unit testing), even the customers (functional testing). If design is good, we'll make it part of everyone's daily business (refactoring). If architecture is important, everybody will work defining and refining the architecture all the time (metaphor)."

On one of the XP wikis, one impassioned fan put it like this: "XP is the Jonathan Livingston Seagull of programming!" He's not alone: XP is now a mini-industry, spawning dozens of XP books and a core of fervent followers.

But does XP have it right? If something is good, does "turning the knob up" to extreme levels really make it better? It's an important question, for this is the guiding principle behind all of XP's values, practices, and activities.

A logic professor of mine in college used to say that a helpful activity in judging the validity of an assertion is to apply it to a different field. If the principle is really universal, the conclusions should be similarly acceptable. And here, XP fails fatally. Let's try this "wisdom" in some other areas.

"If sleep is good, we should sleep all the time."
"If talking is good, we should talk all the time."
"If working is good, we should work all the time."

These are absurd conclusions: clearly, Beck's guiding principle is not universal. But it may still be that in this particular field of endeavor - writing software - a happy confluence has occurred and that this particular set of practices just works well together.

To determine this, argumentation is futile. If the practices work, the results should attest to them by a success rate that is above the norm. Unfortunately, in reading the impassioned writings of XPers, it becomes clear that the advocates feel that the "higher truth" of XP should be self-evident and does not need to demonstrate actual project success. This may explain why there are so few actual case studies of XP projects. For guidance, we must use the "poster child" of XP projects, the Chrysler Comprehensive Compensation (C3) project, guided by Kent Beck, Ron Jeffries, and Martin Fowler. Certainly, if anyone knows XP, these are the people.

The C3 project was an attempt to take an existing mainframe system and port it to PCs. Chrysler was concerned about the Y2K bug and felt they needed a replacement in case the bug turned out to be real. The project began auspiciously enough in 1995, judging by some of the contemporaneous quotes of the XP advocates who worked on it:

"The best software development team on the face of the earth!"
- Chet Hendrikson

"I'd never have said it, but it turns out payroll is so complicated that it is very interesting finding the inner simplicities that make it possible to write a program that works. Objects are perfect for it. Smalltalk is perfect for it. That's just part of why we call C3 Payroll the best project in the world." - Ron Jeffries

Magazine articles with the XPers took up the refrain: XP had proven itself. Alistair Cockburn, talking with Ron Jeffries in February of 2000, put it like this: "As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know."

Well, maybe not quite all of what needed to be known. In February of 2000, the XP faithful were stunned by this announcement on the XP wiki:

"As of February, 2000, the C3 project has been terminated without a successful launch of the next phase."

The "next phase" was something beyond a simple pilot program, the most that the C3 project was ever able to achieve. The much-vaunted C3 project, the best project in the world, was a failure. Again, comments from the XP wiki:

"...at Daimler Chrysler these days the terms, "C3", "Extreme Programming", and especially "the Planning Game" ...are now unutterable by anyone wishing management to take them seriously..."

"...in the view of DC's [Daimler Chrysler] management, C3 was a disastrous project and never the like shall be seen again there."

Given the devastating failure of XP in the C3 project, have the XPers moderated their claims? Not at all. The problem, some of the XPers involved in the project stated, was the customer and not the methodology at all. Undaunted by failure, the XP industry continues to churn out books, articles, and unsupported claims at a prodigious rate.

Unable to use statistical analysis - or even numerous anecdotal successes - to bolster their claims, XPers have lapsed into New Age talk.

"Unacknowledged fear is the source of all project failures."
- Kent Beck and Martin Fowler

"Why do we need a software process? For the same reason that we need government, taxes, and laws: fear." - Kent Beck and Martin Fowler

"I had an epiphany. I went back where Kent was and said that we were just ?balancing hopes and fears.' We had focused on our hope that we could launch the system as planned and our fear that we wouldn't. Kent told me that I had just ?snatched the pebble from the master's hand.' We knew what had to be done..." - Chet Hendrikson

Opposing XP today will likely get you branded as an obstructionist, someone who just doesn't "get it." Shorn of actual project success to point to, the XPers have "turned up the dial" on the rhetoric. Alan Cooper, the creator of Visual Basic and author of such books as The Inmates are Running the Asylum, had a discussion recently with Beck about XP.
Beck: For all its Dilbertesque qualities, I'm still proud of having "Embrace Change" in the title of the first XP book. I've consciously decided to give up the ability to predict the future.
Cooper: I see that in XP. It's an abdication.
Beck: Is Zen an abdication?

No, Kent, Zen is a philosophy of life. Wrapping a failed methodology in high-sounding terms doesn't make it profound; it simply obscures the issue. I believe we must demand more of project methodologies than cultish phrases and mystical patter. The ability to repeatedly produce successful software projects is a thing of extreme value - to both programmers and the clients they produce software for. Is it too much to ask that a methodology that promises this actually works?