Why (most) agile projects aren't the best you ever work on

Matt Heusser’s recent blog entry on Tester/Developer communications prompted me to comment on the dreams of agile projects and tester heaven.

Now, I’ve been tempted to have that conversation, but the conversations I have had instead are much more along these lines:

Me: “Hey dev guy, here’s 20 years of accumulated knowledge describing why the testing approach you are about to take is not going to solve your problem, cost a lot of money, and waste a lot of time”.
Developer: “That’s nice, but we’re going to do it anyway”.

Two months later:

Me: “So, how’d that test approach work for you?”
Developer: “Oh, it completely sucked and was unmaintainable”.

Now, these developers are not stupid people, but it’s difficult for me to understand how things get to this point.

Or at least, it was until recently. Most agile development projects are much like Toyotism (or Lean, if you prefer). Better than how things were in the past, but not fundamentally changing the nature of work. Just as work in manufacturing is still hard, repetitive and largely about lines, so we easily fall into our old factory-style patterns. I believe this is at the heart of Brian Marick’s statement on the current state of Agile project experiences: ‘Whereas the number of people new to Agile who describe their project as “the best project I’ve ever worked on” seems to be declining, and we believe work should be joyful.’

Parallel lines of software development, with variable development and testing tasks performed serially end up being just as unpleasant as the old ways. Except now the moment your testing task takes longer than the development task in the queue behind you, someone’s screaming about the tester backlog.

Of course, it doesn’t have to be this way, but there’s very little incentive for the guy with the upstream work to contribute to solving it. They’re not the ones feeling the pressure. And once those pesky testers are gone, the whole thing actually appears to work much more smoothly. After all, what’s smoother than an assembly line with a single step?

Hint: The last line *is* the answer. But the devil is in the details of what comprises a ‘step’. And what Matt describes is a step toward the solution as well.

Stay tuned.