There is no Agile

On occasion, someone will ask me what I do or, more commonly, ask me what Pivotal does. The title on my business card says “Agile Developer,” which nearly inevitably leads to one of a few reactions, almost all of which boil down to this:

“What exactly does Agile mean?”

You know what? It’s a good question. And, after thinking about Agile for several years now, here’s my answer: Agile originally was, and still is, a marketing term.

Allow me to explain.

We’ve been writing software, in one form or another that most people would recognize as such, for some time now. Scott Bain sets the mark at about 30-35 years[1]. Considering the acceleration of technological advancement in the past century, this is a fairly long time.

In the early days, most programs were small, relatively simple, and written by a handful of developers or fewer[2]. So, the general approach to writing them was to put a number of programming language instructions one after another until the computer did the right thing. Eventually.

I believe it was Watts Humphrey who described this type of programming as “ad hoc development.”[3]

Of course, computers got bigger and badder, and software got more complex, and ad hoc quickly stopped scaling. So, people went looking for a new model to stop the hemorrhaging, and they found waterfall. Now, there’s nothing wrong with waterfall for processes that conform to defined process modeling, such as manufacturing Model-Ts, installing sewer lines, or preparing breakfast cereal. But, most people realize these days that it’s not so hot for processes with requirements that may change.

Years passed, and smart people got stuff done by solving different problems in different ways. And, some patterns started to emerge. And, better yet, some truly clever people started to recognize these patterns and write about them and codify them. However, they realized, astutely, that human beings are a hard-headed bunch who don’t like to change their ways. They needed something to shake programmers out of their collective torpor; they needed something flashy to sell; they needed a manifesto. What better thing to offer to an industry plagued by setbacks and missed deadlines than Agile?

To this day the marketing pitch continues; Agile vs. Waterfall, new vs. old, crazy vs. stodgy.

What can we infer from this brief history?

The move to waterfall wasn’t motivated by an understanding of the specific challenges of software[4]; it was an attempt to apply a working process, any working process, to an industry that was suffering from far too many failures due to a lack thereof.

Many of the principles that have come to be reflected in “agile” processes or “agile” methodologies simply emerged as consistently successful patterns from years of software projects.

Over time, a few people have recognized these patterns, studied them, tried to explain them, and expanded upon them to make them even more effective[5].

The conclusion I draw is this: so-called “Agile” is actually nothing more than a collection of good ideas, based on years of collective experience, for improving how we do our jobs as software writers. Or, to put not too fine a point on it, professionalism.

So, if doing “Agile” things means doing your job well, the term ceases to have meaning. As it should. No one should have to sell us good ideas, we should embrace them and have the discipline to stand by them.

[2] This wasn’t true of all software, of course; the punch card systems that ran the Apollo space program weren’t hacked out by a couple guys in a garage. But, systems like that have their own, mostly time-related, problems.

[3] I loaned out my copy of Winning With Software and can’t immediately find a reference, should anyone care to confirm or deny this credit.

[4] This relates to my rejection of the term “software engineer.” No one really agrees on what writing software is, but we have to call it something. If we call ourselves engineers then we sound like we know what we’re doing. After all, look at all the good stuff in the world that engineers have built.

[5] Pair programming is the classic example of this: code reviews improve code, more frequent code reviews improve code more. How about we code review all code, all the time, as it’s written?