TITLE: Agile Themes: Honesty and Blocking
AUTHOR: Eugene Wallingford
DATE: July 26, 2007 1:08 PM
DESC:
-----
BODY:
I recently wrote about a long-running thread on the XP
discussion list about
defining 'agile'.
Another theme I've noticed across several threads is
honesty. This entry and the one that follows look at
two facets of the theme.
In one thread that seems to be dying down, the list has
discussed the ethics of "blocking", a term that Scott
Ambler borrowed from (American) football to describe
teams that create the facade of following the official
software development methodology while behind the scenes
doing what they think is best to deliver the software.
Scott wrote about this behavior, in which some members
of the team protect the agile process by
Running Interference
for the rest of the team, in a 2003 Software Development
article.
Is it right to do this? As developers, do we want to
live our lives doing one thing and saying that we do
another? I'm leery of any prescription that requires me
to lie, yet I see
shades of gray
here. I don't think that my employer or our client are
better served by actually following a process that is
likely to fail to deliver the software as promised. Or,
if my team is capable of delivering the software reasonably
using the official methodology, then why do I need to lie
in order to use an agile process? For me, programming in
an agile way is a lot more fun, so there is that, but then
maybe I need to find a place that will let me do that -- or
start my own.
As I mentioned last time, I have not been able to follow the
list discussion 100%, and I can't recall if Kent Beck ever
chimed in. But I can imagine what he might say, given the
substance and tone of his postings the last few years. If
you have to lie -- even if we give it an innocuous name like
"blocking"; even if we view it as a last resort -- then
something is wrong, and you should think long and hard about
how to make it right. Agile developers value people over
processes, and honesty is one way we demonstrate that we
value people.
George Dinwiddie has a
blog entry
that considered a more pragmatic potential problem with
blocking. We may be getting the job done in the short term,
but blocking is shortsighted and may hurt the agile cause in
the long run. If we give the appearance of succeeding via
the official route, our employer and customer are likely to
conclude that the official route is a good one -- and that
will make it even harder to introduce agile practices into
the workplace. There is a practical value in telling the
truth, even it requires us to take small steps. After all,
agile developers ought to appreciate the power of small steps.
-----