Does Quality always get the respect it deserves as one of the key tradeoffs of project management? Here's an interesting article from InfoQ, a reflection on a talk of Ken Schwaber's, "Sacrificing Quality should be an Executive Management Decision", that I found through Carnival of the Agilists. I think Ken Schwaber's ultimate point is something like this:

Traditional project management focuses on tradeoffs involving time, scope, and cost. Quality is not as explicitly managed. Therefore, quality can be sacrificed at any time for any reason by any individual on the development team.

We now have reason to believe that high quality work actually gets things done faster. Less rework, etc. So quality should be re-emphasized, and the decision to cut corners should only be made strategically by the product owner and never by the development team.

The response is interesting. A lot of people said (kinda rudely) how stupid it was to assume all projects require high quality, and how stupid it was to push everything to the CEO. Well, they're half right. The point is, it's management's call. How high in management, well, that depends on the project. Basically, some people were distracted by the word "CEO", and I'm not sure if that was Ken Schwaber's or the poster's wording.

Anyway, the response illustrates exactly the response many people will have to the idea. I think to those of us that have studied these issues the choice is pretty obvious. So, I have two questions:

Product owners and managers need to ask for high quality work, instead of just getting the job done. Historically they always asked for the opposite. They will also need to fund a test for high quality work. I think actual code reviews may be required. (I don't think a set of passing unit tests is quite sufficient here, because the model itself is one thing that should be reviewed.)

How do we educate the product owners and managers to be able to make these decisions? I agree with Ken Schwaber that these are the people to who should make these decisions. Though I'm not sure they'll buy the "Quality Costs Less" principles easily. I've learned that "Technical Debt" was an astonishingly easy concept to introduce, perhaps because people were already familiar with the idea and finding a name for it made communication easier. Perhaps I can rephrase it in those terms.

There has been a lot of discussion about post-Agile, pliant, ex-Agile, etc. It's kind of interesting to see how quickly people jump off of a bandwagon. I shouldn't bitch; most of these people were probably in fact never quite on the bandwagon. I still think this is a great philosophy... but somehow I never quite managed to consistently sit down and write tests first. But I couldn't put my finger on the reason...

Wow. This one really caught my eye. Fred Brooks of Mythical Man-Month fame, whose wisdom on software is still applicable decades later, wrote an article in 1987 that damn near predicted the Agile movement. This isn't Agile in the name-brand TDD sense, but a more general recognition that the most effective way to develop complex software is to iteratively "grow" it. Build one to throw away becomes a "spike". I can definitely see the evolution of the ideas a bit more clearly now.

There seems to be a lot of talk about the shape of Agile this week.

Cedric Beust thinks Agile is just plain wrong.

Bob Martin responds.

And a few other posts referenced it.

This one predates this argument, but I think it's related. I can't disagree with the idea that different contexts call for different solutions. Personally, I think Agile approaches have a lot to recommend them in the contexts I work in. But I can't deny that there is a little bit of religious fervor out there. These are some good rules of thumb to keep things in perspective. It's not a silver bullet, folks, just another improvement to build on.

Robert Martin recently posted an interesting blog entry on Never Being Blocked. The article's more interesting than the comments, except for my comments of course :), and it ties together not just Agile ideas but several other useful practices into a common pattern he calls Not Being Blocked. I think I see what he's saying, but I think it's part of an even larger pattern.

What are the common elements of these common agile practices:
test-driven development?

refactoring?

customer-directed goals?

pair programming?

continuous integration?

frequent small releases?

and these other practices he mentions, which aren't direct corollaries of Agile, and don't require Agile, but often do seem to come up at the same time, from the same people:

why prefer non-blocking source control?

why build it yourself instead of waiting for another team or version?

why build it freeform instead of with a heavy internal architecture?

why build a stub for an incomplete or unavailable system?

Constant. Incremental. Improvements.

Martin Fowler has updated his five year old essay, The New Methodology. It's always been a great article, and it's even better now. Plenty of useful links for those who haven't heard of Agile.

It kind of makes me want to write a slightly different essay, specifically targeted at IT buyers and users rather than IT developers. People who may or may not have heard the buzzwords and just want to know what this means to them. I'll be borrowing heavily from Fowler and others, of course. :)

So, I present my Guide to Buying Custom Business Software.