Matt Heusser has been writing some provocative notes on the
agile-testing list. I thought I'd take one of those as my text
today.

I'm very interested in discussion and feedback on this. I've been
observing what I'll talk about here for a long time.

He wrote:

> If anyone is interested in the long version of this discussion, the
> definitive work is Steve McConnell's "Cargo Cult Software
> Engineering", available on-line here:
>
> http://www.stevemcconnell.com/ieeesoftware/eic10.htm

I don't agree with that whole article but I'd suggest giving it an
open-minded read. I look at it in this light:

McConnell writes about process-imposter and commitment-imposter
organizations, and points out that they are similar in that each
group does poorly because they don't fully understand what they are
doing, whether it is following a process or trying to gain a
hard-working commitment. He says:

Cargo cult software engineering is easy to identify. Cargo cult
software engineers justify their practices by saying, "We’ve
always done it this way in the past," or "our company standards
require us to do it this way"—even when those ways make no sense.
They refuse to acknowledge the tradeoffs involved in either
process-oriented or commitment-oriented development. Both have
strengths and weaknesses. When presented with more effective, new
practices, cargo cult software engineers prefer to stay in their
wooden huts of familiar, comfortable and-not-necessarily-effective
work habits. "Doing the same thing again and again and expecting
different results is a sign of insanity," the old saying goes.
It’s also a sign of cargo cult software engineering.

Now McConnell moves from these observations to a call for increasing
competence through education and training. He points out -- and I
agree -- that more competent people are more likely to succeed.

But while I agree with him on that, my own concerns are a bit
different. Over the past decade+ of doing this, I've seen a lot of
teams who plateau, never attaining the level that they could. And
that's not just my judgment of how good they could be, but their
own, and their management's. I've seen a lot of teams reach a really
good level of performance, and then fall away from the behaviors
that got them there. Even worse, I've seen teams who seem to be
sticking to the practices that got them there, but nonetheless do
not prosper.

I am not entirely sure why this happens, and suppose that different
teams have different reasons. But here are some patterns I've
noticed:

1. The team does its practices as if they were some kind of ritual
that is followed for its own sake. Perhaps they have never
understood why they do them, or perhaps they have forgotten.

2. The team does its practices because it has been told to do the
practices. "That's just the way we work here."

3. The team is under pressure, imposed by management, or
self-imposed from a feeling of urgency, which causes them to
revert to old habits, or to rush the hidden aspects of their work.

Now at first there seems to be no common element here. But I think
there are one, perhaps two.

First, the team may not be doing its practices mindfully. If we want
to increase our skill, we have to think about what we are doing. We
have to do a thing, experience the results, and reflect on them.
This is the Feedback value of XP in action.

Second, the team may not be continually varying their practices and
observing what happens. When we drive, we are always adjusting the
wheel based on what we see. When we drive for performance, we change
our route around the track in small ways, to find what works best.
Again Feedback in action.

So I hypothesize, based on a lot of observation, that teams that
plateau or fall back have not been paying attention to what happens
as their practices vary. There are a number of reasons why they
might not do that. I'll list a few here:

The practices may not be their own but imposed through fiat or
habit.

The practices may not vary, because of habit or external
influence.

The practices may be seen as not important, owing to louder
voices in the organization, who may be calling for more features
and harder work.

It would be necessary to look at a team that wasn't improving, and
to assess openly and honestly what might be getting in their way. It
seems likely that every one of the items above would be happening
with the best of will. Unfortunately, good will is not enough to
provide good results.

Introspection might help. Help from outside might be of value.
Ultimately the team has to examine itself with a cool head and
recognize that they need to change, no matter how good their will
may be, and no matter how well they believe things should work.

To improve, we have to change.

Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
-- after Mark Vaughn, Autoweek.