The agile development community has a number of guiding principles, such as ‘people over process’ and ‘values over practices’, that try to capture the essence of what it means to be Agile. I’m feeling contentious today, so I’m going to poke at them a bit, and also propose a single core concept by which I think Agility can be measured.
I (and I suspect most people) first encountered agile development in the form of XP. XP got the whole agile conversation started because it was so bold, and made no apologies for being so. For that alone the software community should be thankful.
However, the clarity of XP’s message has since been diluted by the whole Agile movement, and the debates over what it means to be agile, what was agile, and what wasn’t, how do you know if you’re agile etc. etc. and we all kind of missed the point.
The point is this: Agility is (from the dictionary) ‘characterised by quickness, lightness, and ease of movement; nimble.’
Another way of saying that is ‘responsive to change’. What is the single largest change that can affect any software project?
Death.
Any project can potentially be canceled at any point. Less severely, budgets and schedules can be slashed, or teams dissolved. Any one of a whole range of events can occur, but the result is always a change.
So, if being Agile means responding to (and more importantly) coping with change, and death is the single largest change that can happen to any project, shouldn’t an Agile process have a clearly defined mechanism for coping with it?
Yes.
You may cry, “Thats nonsense, this fool thinks you can survive death.”
Not survive, cope. In commercial terms, that means delivering the greatest business value in the face of change. In this case, in the face of unforseen project death.
Can you see where this is going yet?
Now we come to the big revelation. How do you deliver value from a cancelled project? By being ready to ship whatever work you’ve done at any point throughout the project. Ship, as in release, deliver, wrap in clingfilm and stick on the shelves. Not only that, but what is delivered should contain the most business value that was possible to achieve in the time you had.
I submit that this ability to deliver what you’ve got at any time is the single defining characteristic for Agility in software development. Every other practice, value, and position statement can be evaluated in terms of its relationship to this fundamental concept.
Glad we got that straightened out.
Darren Hobbs 
I guess it’s debatable that death qualifies as a change. Well yes, it’s a change, but a special one. It’s an exceptional change.
I doubt that a cancelled project will provide value as a finished and wrapped product, but some of it’s components can provide value if reused in other projects. Like an unfinished car would not sell in a car dealer, but you could take it apart and sell _some_ of the spare parts separately.
Looking at “agile” as it relates to the team rather than the project itself, the other “thing” that is ready to ship when a project is whacked is the team, what it has learned (individually and collectively), and its willingness/interest in going on to the next project and doing good. Not that these are necessarily all positive values: disillusionment and fear of failure are big risks in teams that have had projects cancelled.