Holistic vs. Dogmatic Agile Definition – Results Matter!

I originally wrote about this topic in our September email newsletter.  In that article I was trying to explain the difference between two specific types of agile coaches.  Those that believe agile is a very specific set of practices (dogmatic) and those that believe agile is more about following principles leading to good results (holistic).  I’ll let you click the link to read more if you are interested.

In this post I’m following up because I recently came across some interesting stuff which made me recognize other people are making some of the same points I’ve made.  An example is this blog entry mentioning agilists (the more common term seems to be agile purists).  In doing some research I’ve discovered some things I’ve said which I could say even better.  For example, my answer to the question “What is agile?”

Those of you that know me know that I’m not a big proponent of the agile manifesto as written (love the concept, hate the way it is worded).  So my answer doesn’t go that direction at all.  It’s also painfully obvious that I believe agile is more holistic and results oriented than it is dogmatic and practices oriented.  Don’t take that the wrong way, you will likely be doing many of the “standard” practices in order to achieve the results, but it isn’t a requirement to do so – at least not in my opinion.  Now the stage is set for my answer.  I usually say something like (drumroll please)…

“Many people answer this question differently than I do.  When they are asked this same question they will say things like “Agile is creating a product using iterations, while working from a prioritized backlog, which is prioritized by a product owner/customer type, and each day you have a daily standup so the team can make sure they are on track.”  I really despise that definition because you can do that forever and never release a product!  My definition is a bit different.  If you are building high value software, with high quality, and delivering as quickly as possible, then you are being agile!  You may in fact have to do many of the practices from the other definition, but you need to remember results matter.” 

I’ve been saying something like that for a long time now.  At times I almost felt like the lone voice in the wind.  But not any more!  Now I have a BIG name that I can quote instead.  Check out this definition from none other than Scott Ambler.  Scott’s definition may have existed forever, but it is the first time I’ve seen it.  So for those of you that didn’t click on the link, Scott’s definition of Disciplined Agile is:

An iterative and incremental (evolutionary) approach to software development

which is performed in a highly collaborative manner

by self-organizing teams within an effective governance framework

with “just enough” ceremony

that produces high quality software

in a cost effective and timely manner

 which meets the changing needs of its stakeholders.

Is that exactly my original definition?  Obviously not, but it is pretty close.  Let’s look at the ending of Scott’s definition in particular:

that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders

and compare it to my definition:

Build high value software, with hiqh quality, delivered as quickly as possible.

Same meaning, different order.  If I said:

Buid high quality software as quickly as possible while delivering high value.

I would pretty much match the end of Scott’s definition!

The beginning of Scott’s definition is more about the practices involved, so effectively he has tied the dogmatic and the holistic together.  But do I really do anything different?  Go back to what I say, and see how I end things with “You may in fact have to do many of the practices from the other definition, but you need to remember results matter.”  I too mix the two, but I do it in reverse order by acknowledging that the dogmatic definition is not necessarily wrong, just insufficient.

I agree with Scott Ambler!  Who knew?

The point of all of this is to remember the methodology practices don’t necessarily drive results.  You can iterate, collaborate, self-organize and be highly productive until the end of time, and none of it matters if you don’t end up with high value software, with high quality, DELIVERED as quickly as possible! 

Note the emphasis on delivered – it is on purpose!  Results absolutely do matter.  You can never forget that on an agile team.

In fact, Richard Lawrence from Humanizing Work and I have collaborated on a few submissions for the Agile 2009 conference later this year.  One of them is “Don’t Just Build Fast, Release Fast Too”  Check it out and add your comments on whether it is a worthwhile topic for the conference.