TITLE: Taking the Pulse of the Agile Community
AUTHOR: Eugene Wallingford
DATE: April 30, 2010 10:17 AM
DESC: 
-----
BODY:
Thanks to all of you who have written in response
to my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-04.html#e2010-04-29T20_47_16.htm">
   previous entry</A>
with suggestions for my May term course on agile
software development.  Most everyone recommended
what I knew to be true: source control, automated
builds, automated testing, and refactoring are
the foundation of agile teams.  Keep those
suggestions coming!

Over the last semester I have been reading the XP
mailing list a little more closely in an effort
to discern the pulse of the community these days.
Every so often an interesting thread pops up.  For
example, a few months back, the group talked about
its general aversion for software done "quick and
dirty".  One poster quoted Steve McConnell as saying,
"The trouble with quick and dirty is that dirty remains
long after quick has been forgotten."

This thread stood out starkly against comments from
a couple of my colleagues who view agile ideas as a
poison, not just a bad idea but a set of temptations
that prevent developers from learning The Right Way
to make software.  They often rail against XP and
its ilk as encouraging quick-and-dirty development,
producing bad code with no documentation before
moving on willy-nilly to the next "story".

That sounded quite funny as I read professionals who
use agile practices every day promote unit testing
and especially test-driven development as ways to
guard <EM>against</EM> a quick-and-dirty process.
Similarly, building refactoring into your weekly,
daily, or hourly development cycle is hardly a recipe
for reckless development; it is a practice that shows
deep care for the code base and for the quality of
the software we deliver to our clients.

One of the most active threads on the list over the
last few weeks has been a discussion of the
"characteristics of a great XP team".  This thread
has been full of enlightening capsules from people
who have been doing XP in the trenches for many years.
Some of the discussion offered advice that applies to
great teams of any sort, such as a desire to know the
truth and adapt to it.  Others took a stab at
highlighting what XP itself brings to the table.  In
one especially insightful message,
<A HREF="http://www.williamcaputo.com/">
   Bill Caputo</A>
suggested that, among other attributes, a great
XP team...
<UL>
<LI> can deliver well-tested software at a regular
     pace indefinitely, because it has "successfully
     flattened [the] cost-of-change curve".  </LI>
<LI> "has mastered the art of adapting [its]
     process to the needs of [its] environment."  </LI>
<LI> "have such a distribution of knowledge ...
     that any one person could leave [the] team, and
     [its] velocity would not be negatively impacted
     any more than any other person leaving."  </LI>
</UL>

Steve Gordon decomposed the question that launched the
thread into two parts:
<OL>
<LI> What are the characteristics of a great software
     team?  </LI>
<LI> How does XP achieve -- or not achieve -- these
     characteristics?  </LI>
</OL>

I think Gordon's decomposition serves as a nice way for
me and my students to approach our course, and I think
Caputo's list is a good start on what we mean when we
talk about agile teams.
-----