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 http://agilecruz.blogspot.com]