TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
If you talk to the people who signed the Agile Manifesto, you will find that they are by and large proud it. They might not be as committed as say the framers of the US Declaration of Independence, but the statement reflects what they think is important.
On a second level, the Agile Manifesto achieved another, perhaps unstated goal, which was to draw a line in the sand. Here, the authors said, we're in favor of people, working software, customer collaboration, and responding to change -- take that all you folks using heavy, rigorous management methods (e.g., users of CMM)! It was clearly a way of getting people's attention -- and it worked. Like everything else involved with agile development, I think that it was very carefully thought out, but as a propaganda piece, it may go down with "loose lips sink ships."
My quarrel with the Agile Manifesto is that, in the long run, it creates, or seems to create, artificial barriers to future improvements in the software development process. I believe, for example, that for something like agile development to be adopted widely and really affect software productivity and quality, it will be necessary to place as much emphasis on rigor, documentation, and tools as we do on people, collaboration, and working software.
Some forms of refactoring, namely data refactoring, are simply too complex to be done by hand, no matter how skilled the practitioners or how good the team. Saying that we value people over tools deemphasizes the development of tools that make agile development work better, faster, and cheaper.
Tactically, I think that issuing the Agile Manifesto was a good idea. Strategically, I think that having drawn a line in the sand, the agile development folks may have to stand on the wrong side. Over the long haul, individuals and interactions are not opposed to process and tools. Neither is working software necessarily at odds with comprehensive documentation -- documentation using the right tools should be a byproduct of producing working software. Neither is customer collaboration necessarily at odds with contract negotiation, though here I'm inclined to give the agile developers some slack on this issue -- contract negotiation is usually a lose-lose activity. Finally, responding to change is not fundamentally opposed to following a plan.
Now the agile development folks will say that they never said they were against tools and processes, just that individuals and interactions are more important. Granted! But there are few generals in the world who wouldn't rather have a group of relatively untrained recruits with rifles against the most skilled folks with bows and arrows. Civilization and software operate at many levels; major advances in civilization often result from seemingly simple advances in technology.
Agile . since Jun 23 . Index . DOCs TOP TOC
To begin with, agile development is all about the end product. In an agile development project, the product is always the clear focus -- not the requirements, nor the design, but the final, delivered product. Having the product as its main focus makes up for a lot in the real world of project management.
A second major advance that agile development brings to software is institutionalizing the process of incremental product releases, while, at the same time, challenging the time involved to produce them. Most nontechnical people respond best to something they can see and touch.
Another plus is the focus on integrating many programming best practices into basic principles that all work together. The agile development folks have done an admirable job of taking a lot of things that have been known for a long time -- how programmers work best and how to produce quality software -- and blended them together into a single coherent whole. After studying it for a while, it strikes me that agile development is quite a lot more than the sum of its parts.