TITLE: Agile Themes: Defining Agile
AUTHOR: Eugene Wallingford
DATE: July 24, 2007 3:42 PM
DESC:
-----
BODY:
Every so often the
XP discussion list
takes off in a frenzy of activity. The last few weeks have
seen such a frenzy, which makes it difficult for readers
like me to keep up. Fortunately, I am often able to find
some nuggets of value with a two-pronged heuristic approach
to reading: I usually home in on messages from a few folks
whose posts I have found valuable in the past and scan the
sub-threads that follow, and I occasionally select messages
pseudo-randomly based on subject lines that tickle my fancy.
I'm sure that I miss out on some valuable conversations
along the way, but I do find enough to keep my wheels moving.
One long-running recent thread has focused on "defining agile"
-- that is, being able to tell when an organization is using
agile methods or not. If the list were made up solely of
academics, this thread would be a natural. Academics love
to put things into categories and name them. But this list
is made up mostly of practitioners, and there interest in
defining agile comes from many different directions, not
the least of which is dispelling hype and distinguishing
practices that help folks succeed.
I used to be much more dogmatic about naming things and
separating methods and approaches and people into categories.
A prime example was "real" object-oriented programming from
the charade that some people display in a language that
supports objects. Over time, I have soured of the battles
and am more likely to espouse the point of view expressed
by Andy Hunt somewhere back in the thread:
Instead of a test for agile, how about a test for "was your
project a success or was it horked?" If it was a success,
call it anything you want. If not, don't dare call it agile. :-)
This sort of pragmatism is reminiscent of Alan Turing's
sidestepping of the question "what is intelligence?" in his
seminal
Computing Machinery and Intelligence.
Such a definition makes it hard for agilists to defend their
turf, but it lets folks who want to build systems get down
to busy, rather than argue.
That said, I think that George Dinwiddie has done a nice job
of capturing the essence of defining agile methods in a
blog entry
responding to the thread: using feedback that is frequent,
timely, aligned with our desired goals, and pervasive. If
you have read much of this blog, especially back in the first
couple of years, you know that I have written frequently of
the value of using feedback in many different circumstances,
from developing software to teaching a class to training for
and running a marathon. My appreciation of Dinwiddie's
characterization is unsurprising.
Tim Haughton created a branch off this thread with a post that
defines the
Three Colours of Agile.
Haughton reminds us that we need to tell different stories
when we are dealing with the different parties involved in
software projects. In particular, the customer who will use
our software and the manager who oversees the development
team have much different views on software development than
the developers themselves have. Most of our discussion about
agile methods focuses on the practices of developers and only
peripherally with our interface to the rest of the world, if
at all. Telling the right story at the right time can make
a huge difference in whether another person buys into a new
method proposed by developers. When we communicate the value
of agile methods to the customer and manager from their
perspective, the approach looks so much more palatable
than a laundry list of developer practices they don't understand.
Again, frequent readers of this blog will recognize a recurring
theme of story telling.
-----