We see a lot of discussion on Agile development and sometimes fanatics get involved and add a lot of fog to the conversations. Other than a vague (and contradictory) 'Agile manifesto', is there a definition that can be used to base opinions on or will this 'tag' remain a myth to most of us. I, for one, believe that 'Agile' is a qualitative word that should not be used to represent a methodology.
There isn't enough space to write an entire treatise on this, but here is the nitty-gritty.
"Agile" is a generic term that refers to a loose set of methodologies that include Scrum, XP, Feature Driven Development, and other iterative AND incremental methods. You are correct in that it is not a methodology in itself.
You often hear very loose descriptors like "trust," "iterative," "low documentation" etc used to describe "Agile" but these are pretty nebulous. To be more precise:
1) Agile methods are iterative, where the complete lifecycle (plan, reqt's, design, test, build) happens in short durations, often 30 days or less. These activities are usually not linear, but empirical, and do not always occur in a specific sequence
2) Agile methods are incremental, where a small set of features is developed, followed by refinement or another set of features. The methods don't espouse the "big bang" but more like small bits at a time
3) Agile methods negotiate scope, not time and budget. A "waterfall project" usually has a fixed scope, and a fixed budget. If a major change is requested, the timeline and budget is negotiated. Agile methods EXPECT change, but negotiate each release (or iteration) to contain a certain amount of "features" (or functionality). If they don't get it all done, they execute another release.
4) Agile methods MUST have buy-in from the end-user or customer, because this type of negotiation is not IT or engineering driven, it's driven by the business, so it's not for everybody.
The different Agile methods have other specifics (XP uses Pair Programming as a form of real-time validation, Scrum has "stand-up meetings and "sprints" for instance) but these are ornamental - not core to the concept of "Agile."
For more information (and for a discussion of CMMI and Agile methods) you can download an SEI Technical Note (CMMI and Agile: Why not Embrace Both!") which I co-authored with several other very talented individuals.