Frankly Speaking: Agile programming is no hooey

If you read Tom Hoffman’s article “A Telco Giant Gets Agile” about how BT is using agile programming for a major software project, you may have stumbled a bit when you got to the description of the “Manifesto for Agile Software Development.” Chances are good that, after a quick read, your reaction was “That’s all agile is?”

Or maybe your response was “What a load of hooey!”

Agile programmers value individuals and interactions over processes and tools? Working software over comprehensive documentation? Customer collaboration over contract negotiation? Responding to change over following a plan? That’s all very warm and fuzzy, but kumbaya circles don’t deliver real applications.

Hard-nosed pragmatism is what you need to produce real software — right?

Exactly. So let’s get hard-nosed and pragmatic for a moment about software development.

What do we know from a half-century of software projects? Most of them fail. They run over budget, run late, run off the rails. They cost more, take longer, and deliver less functionality than they should.

The bigger a software project is, the more likely it is to fail. And the bigger the project is, the more likely it is to have all the trappings of traditional software development: the extensive plans, complex negotiations, detailed documentation and painstakingly defined processes.

The hard-nosed, pragmatic conclusion?

Relying on plans doesn’t work.

Relying on contract negotiations doesn’t work.

Relying on comprehensive documentation doesn’t work.

Most of all, relying on processes and tools doesn’t work.

At worst, these things are merely bureaucratic crutches.

At best, they’re still only the machinery of programming projects. You can’t rely on them to deliver the goods.

From a hard-nosed, pragmatic perspective, machinery doesn’t deliver software.

Programmers do.

And the software that they deliver to corporate users has to meet the needs of human employees, changing business requirements, and shifting market conditions. Oh, and that software is useless until it’s actually in the hands of the people who can do business with it.

So responding to change is at least as important as having and following a plan.

Getting in close with users is at least as important as negotiating what is to be delivered.

Delivering software that helps users do business is at least as important as writing the documents that describe it.

And the interactions of the human beings who will make and use the software are at least as important as the processes and tools they’ll use to create and take advantage of it.

As much as that manifesto may sound like highfalutin hooey, this isn’t warm and fuzzy kumbaya. It’s coldly logical and utterly pragmatic.

It’s also not enough.

Because just as machinery doesn’t deliver software, values don’t either. If you believe that’s all agile programming is, you’re still missing something truly important.

We need the machinery — some of it, anyway — to help us get the job done. We need the values to keep our priorities straight.

But most of all, we need the focused skills, intelligence and experience of both programmers and users. That’s the heart — and the hard nose — of any successful software development approach, agile or not.

And that’s no kumbaya.

Frank Hayes is Computerworld’s senior news columnist. Contact him at frank_hayes@computerworld.com.