Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
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.

[1] Emergent Design: Addison Wesley, 2008

[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?

  • Kind of nice to read this article (while eating some peas).

    I liked the fact that you were honest saying it’s marketing. It’s kind of like saying, I’m a developer but one that is actually smart and likes programming. The normal course of things now-a-days is some computer science wannabie that will tell you that development works suck and wants to go “up the ladder”.

    It’s a statement. I’m not that kind, I do this because I love doing it and I’m damn good at it.

  • Steve Conover

    This is the blog post that’s been rolling around in my head for a while, and it’s much better than what I would’ve said.

    Some comments:

    I don’t know that we can beat the agile manifesto folks up too much in hindsight. After all, it’s not as though these changes – basically, our daily work environment – were inexorable or inevitable.

    Agile, like political and social movements, makes a lot more sense when considered in its original era – made sharp and compelling and even radical in contrast to the status quo. But after you win your principles are ingrained into everyone’s thinking – and it all seems like one grand progression of history.

    So I wonder whether people like us – who are sensitive to overpromising, mischaracterization, backlash – skeptical of revolutionary talk, etc – are the acceptable losses in the grander effort to change everyone’s thinking. Making a software product really is different from 10 years ago – maybe we should be thanking Fowler and Beck for Agile, and DHH for Rails, even though we can all stand around and point at all the mistakes and poorly chosen phrasing and second-guess the strategy. Or I could just be settling.

  • Väle Jänes

    Why do you need to emphasize “Agile” on your business card? Why is “Agine Developer” better/cooler than “Software Developer”?

  • Adam Milligan

    I believe the marketing term is “differentiation.”

  • I was actually pondering about this for the last week or so, could it be that we were all fooled and Agile is nothing more than Waterfall done right, or adjusted for certain needs. In one post I’ve recently read about Agile: “Agile encourages constant and continued communication”, but doesn’t this apply across the board. I have yet to see, with a few small exceptions, a substantial difference between Agile and Waterfall done right. I have published once an article on combining agile and waterfall written by an Agile practitioner, reading it does nothing but to add to the theory (fact?) that Agile, in its essence, is a submethodology of Waterfall, but not really one on its own. Then again, this is probably another Project Management subject that is exhausted (similar to the “Is Project Management a Profession?”), and where there’s never a consensus on the answer.

  • Steve C

    “Done right” – every methodology’s famous last words. Should Agile be held accountable for its public perception too, however different it is from what its founders intended (for instance: that there’s no room for design, that it encourages a series of local optimizations that you never break out of)? I don’t know. Maybe that’s not fair.

    I think it can be held accountable for what people actually do under its banner. And on that count I think it’s clear that Waterfall falls down. Yes its founders intended it to be iterative, but if in practice every project that’s doing Waterfall does months up planning up front and documentation, and, closer to the delivery end, manages changes via a painful change request process, and giant projects lurch and fail, isn’t that how Waterfall ought to be judged? And “Agile” (in quotes) is probably a mixed bag.

    I’m think that the writer of that article was trying to say something like, we should learn from both and not forget the good stuff, right? Who could disagree? But let’s not allow this one to be split down the middle: before I started doing Agile, I figured there was at least a 1 in 4 chance that a project would fall over and die for engineering reasons. Now that’s down to…1 in 20? That’s different, and better.

  • Hey, there’s actually a picture of that moment:

Share This