I have a problem with a lot of the rhetoric about "agile methods" lately.

Agile methods, or at least those supported by the Agile Alliance—a nonprofit consortium of software developers—are used by developers to minimize risk by creating software in short time frames, or iterations, lasting anywhere from one week to a month. Each iteration effectively represents a miniature software project, and incorporates the planning, design, coding and testing required to deliver new functionality.

Why do I have problems with all this talk about agile methods? I have been in the software business for almost 40 years and have written a lot of code for a living. By the mid-1980s, it was clear that IT services was a growth segment, and a big part of IT services was focused on custom application development—coding for money. That's when I discovered methodology. Or rather, I discovered that most available methodologies were as much a part of the problem as they were the answer.

So I talked my bosses at Ernst & Young into letting me build a new methodology (with a lot of help, of course). Loosely based on Information Engineering, a rigorous architectural approach to planning, analyzing, designing and implementing applications, it was what I would now call a "variable weight-defined method with optional late binding for techniques and content overloading." At one extreme, it could be used as a strictly defined sequential "waterfall-like" process—relatively safe, but not very efficient. A team was told both what to do and, to a very large extent, how to do it. The method provided a very prescriptive management framework.

As our engineers, supervisors and managers got better at it, the method was redesigned to become more relaxed in order to allow for (even encourage) more self-organization, rapid iteration in deliverables, and tolerance of ambiguity in the work-planning process. From 1987 until 1998 (when I stopped being directly involved) this approach worked extremely well. We delivered well over 90 percent of software development projects on time, and within budget.

Then, in 2001, a bunch of self-appointed evangelists launched the Agile Manifesto at a Utah ski resort one weekend. Ever since, this Agile Alliance has been telling us we did it all wrong because we didn't do it their way. This group often acts as if it wants to blow up everything that works pretty well. In its own defense, the group quotes unsubstantiated research findings on IT project failure rates that are very far from my own experience (and, I would assert, from common sense).

I like a lot of what the Agile Alliance brings to the process of software development—but not all of it. Most of all, I don't like their attitude toward the rest of us. I worry that their often-patronizing attitude stops a lot of people from seeing the real value in their ideas and practices. And that's a shame, because we really do need to improve the quality, speed and economics of software development. Today, too much of the world depends on software that is, at best, barely good enough—and that really worries me.

test