Conclusion – A Response to “Traps & Pitfalls of Agile Development – A Non-Contrarian View”

So, I offer my final thoughts after responding to this entry by Sean Landis.  Previous entries in this series are:

Philosophy vs Implementation


software is hard. Developers know that.  Product owners, even if they

understand that, still may not understand the full implications of that

reality. Agile attempts to bridge that gap and does a pretty darn good

job, in my humble opinion. 

However, as with all good ideas,

philosophy and implementation can be world’s apart.  Some people

criticize Agile as being some sort of Utopian Ideal or non-attainable

Nirvana.  In conversations I have had, I have made analogies to the

essential core of social philosophies that seem to promise a lot but

fail to recognize certain realities of humankind.  Those very

philosophies, with noble and lofty ideals, have often failed in their

implementation.  But, that does not necessarily mean we abandon the

heart of those ideals.

In software we can afford the luxury of

pressing on toward the ideal that Agile offers without causing the

downfall of a government or social system (at least, I hope so!).  We

should not just abandon it because it is not perfect, has been

misunderstood in the past or has been misapplied with abysmal results

somewhere else. There have been tremendously successful software

projects that owe their success to Agile and which, in my opinion,

would not have been as successful with a more “traditional” approach.

Be Agile With Agile


fundamental analogy behind Extreme Programming (an Agile variant) is

that of driving a car.  You get in the car, back out of the drive way

and begin heading toward your destination.  You have a map, you know

where you are going, but along the way you make necessary corrections,

keeping your goal in mind.  Your steering drifts to the right, you

correct; you run into a construction zone, you detour around it – all

the while keeping the goal in mind. 

That is a fitting

analogy for our approach toward this broad term, “Agile”.”  Just as we

correct ourselves along the way on an Agile project, we could take the

same tack with our understanding of Agile itself.  Let’s learn from our

mistakes in implementation, continue to refine our understanding of

what Agile means, adjust our course along the way and press on toward

the goal of writing higher quality software that serves our customers

in more efficient and meaningful ways.


[Original version of this was posted 1/16/2009 at]

Part Five – A Response to “Traps & Pitfalls of Agile Development – A Non-Contrarian View”