Why I Define Agile in Terms of Results

Not everyone agrees with my definition of Agile.

Dave Nicolette commented that he thinks my definition actually describes Lean. He defines Agile in terms of the Agile Manifesto.

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.


Subscribe to our e-mail newsletter to receive updates.

10 Responses to Why I Define Agile in Terms of Results

  1. Daniel Longmore December 3, 2009 at 10:02 pm #

    I would agree wholeheartedly. Who cares if you can repeat the Agile Manifesto from memory but do not see a benefit from it. Who cares if you have infrastructure that appears to support the what is in the manifesto but the results are not there. It is very important to understand why there is an Agile.

  2. Laurent December 3, 2009 at 10:03 pm #

    Why would defining Agile in terms of results not match the Agile Manifesto’s definition? Don’t the 1st principle of Agile, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, directly relate to achieving the results the customer wants?

  3. Glen Ivey December 4, 2009 at 2:53 am #

    Agree with everything. If you’re concerned exclusively with process and not at all with results (1) how did you pick the process in the first place?, and (2) you might be doing meditation, but you’re not doing engineering. Oh, and two points for the cargo-cult reference–not many opportunities for those…..

  4. Jean-Noël Rouvignac December 4, 2009 at 8:20 am #

    While summarizing this post Iwrote this:
    “Focus on results, not an 100% compliant agile process (That’s an oxymoron BTW).”


  5. Olga Kouzina December 4, 2009 at 10:59 am #

    The religious debates. That’s exactly the plague of the community. Look at the buzz – this is similar to medieval scholastic/dogmatic disputes if the Earth is round or flat (from the point of view of how simple and obvious the disputed issues are). If it works, it is agile = it is good. Period. Let’s not fluff it out to the soap bubble of scholastic disputes.

  6. Robert Dempsey December 4, 2009 at 3:59 pm #

    Great post Elisabeth. I agree fully that we need to focus on Agile producing business value, rather than simply looking at it from a process standpoint. Why implement anything new or different if you aren’t going to get more value. Gaining value must always be the goal. If someone is adopting Agile to forgo good engineering practices, then they are adopting Agile for the wrong reasons.

  7. Simon Morley December 5, 2009 at 9:23 pm #

    Good post! Sometimes the most profound words are so simple!

    Yes, at the end of the day it’s what you’re delivering to the customer that matters. It’s true that this is in the manifesto – but sometimes it needs a reminder to come back on track when anyone is getting bogged-down in dogma.

    It’s a sign of Agile’s popularity that there are so many evangelists of all flavours preaching about it – of course with their own spin on what’s important…

  8. Kristoffer Nordström December 8, 2009 at 10:14 pm #

    Very good post.
    For too long people have failed to see that there are no silver bullets and that you have to be context aware when you define how you and your organisation work.
    How otherwise could we possibly believe we are bringing maximum value to the table if we only go by a boilerplate recipe?

  9. Jeff Fry December 21, 2009 at 1:17 am #

    Hey Elisabeth — Very nicely put! This is a great explanation for why I like your definition of Agile so much.

  10. Aaron Frost February 2, 2010 at 12:04 am #

    Elizabeth – I am glad that you have worded your concept as you have. Even after thinking thoughts that are in line with what you are saying, I have had a hard time turning those thoughts into words, as you have eloquently done. Thanks!

Leave a Reply