Not everyone agrees with my definition of Agile.
I replied to Dave elsewhere, but wanted to post my response here too since this is a topic that comes up frequently.
I have trouble defining Agile solely in terms of the Agile Manifesto.
Mind you, I believe the Agile Manifesto is a great document. With it, the original signatories gave the industry a focal point, a fulcrum on which to turn. They forever changed our industry by distilling the difference, in terms of their guiding values and principles, between the lightweight approaches they used and the then-generally accepted formal processes & industry “Best Practices.”
And turn we have. “Agile,” at least as a buzzword, is mainstream. Increasingly organizations are adopting Agile methods to remain competitive.
However, I see the manifesto as a beginning, not a definitive end. The community has learned much in intervening years.
Part of what I’ve personally learned is that defining Agile in terms of results short circuits two of the bigger problems I see plaguing the community: 1) religious debates and 2) superficial but ultimately hollow attempts at transitions that result in frAgile processes.
Where people define Agile in terms of practices, I see more instances of Cargo Cult adoption (“We’re Agile because we stand up every morning!”) and religious dogmatism (“You don’t TDD?!? You can’t possibly be Agile!”).
Where people define Agile in terms of values, I see more instances of Agile-as-an-excuse (“Documentation? No. We don’t document anything. We’re Agile!”).
But where people define Agile in terms of results, I see greater focus on the ultimate goal: value to the business.
As it happens, the best way we’ve found to achieve that goal so far—or at least the best way I’ve seen so far—involves embracing the values and principles of the manifesto.
But I believe that remembering why those values and principles are important, remembering the result we’re trying to achieve, is essential. And so I define Agile in terms of results.