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.
January 4, 2009 at 1:06 am
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.
January 4, 2009 at 2:24 am
Good post, Adam. However, let me play the Devil’s Advocate.
The term “Agile” *IS* important, because it is important to give names to important things.
Here’s a concrete example. Have you ever spent fifteen minutes debating with your pair (and neighboring pairs) over what the proper name is for a key new Model class, which will be a fundamental part of your new app? I have – and this is time well spent, because good names are powerful. You may not get it right at first, and you may refactor it later if a better name emerges. In many cases, though, the first name tends to stick, and if it is a good, intuitive one, it will decrease confusion and raise the effectiveness of your code and your team.
Likewise, when the signatories to the Agile Manifesto applied a *name* to these practices, it was an important step. It made disparate collection of “good” practices into a specific and concrete *thing*. It is a good name, because it does well at capturing the philosophy and practice that the Manifesto signatories wanted to promote.
It is true that Agile” might be hard to explain to the uninitiated, and may even cause debates over the details among experienced practitioners. However, I believe that for the most part, people who truly practice “Agile” have an understanding of what it is, much like Aristotle’s list of virtues as discussed in [your prior post](http://pivotallabs.com/users/amilligan/blog/articles/637-aristotle-aristotle-was-a-bugger-for-the-bottle-), and more important, the ability to recognize practices which are *NOT* Agile, and therefore less likely to lead to success.
Of course, as “Agile” becomes more widespread and popular (due to its power and success), people will try to exploit and subvert it for their nefarious marketing purposes. I’m not too worried about that, though, because the values in the Manifesto are clear, and most people with a even a mildly sophisticated BS-o-meter (a prereq for anyone in software development) should be able to see through this if they truly care about their success.
So, as Steve said, I don’t think we should second-guess the “Agile” movement which brought us to where we are, because it has undeniably advanced the **art** (*NOT* engineering or science) of software development. The practices have innate value, and most developers who truly follow them recognize that they lead to greater success and happiness. Giving a concrete “name” to this “path” has facilitated these advancements, and I believe it has been a Good Thing overall.
– Chad
January 4, 2009 at 4:13 am
I think it’s important to make clear that I don’t mean to condemn the creation of the term “Agile,” the use of it to make people pay attention, or the Agile Manifesto or its values. I actually think it’s entirely appropriate that Fowler and Beck (and Cockburn and Evans and Schwaber and Thomas et al) became a marketing machine. The message is worth hearing, and most people aren’t going to pay attention unless there’s something sparkly attached.
However, my point is that we should be conscious of the fact that the term “Agile,” and for the most part the methodologies and dogma associated with it, served the purpose of getting attention. (I also don’t want to underplay the reality that the signal still hasn’t gotten through a significant percentage of the software industry.) Once you have the attention, you have to shift to education. This marketing approach is why you hear about so many teams who “do Agile,” but don’t succeed. They hear the siren call of guaranteed productivity, but they don’t understand the underlying disciplines.
Chad, I’ll be the first to say that naming is important. However, in this case I disagree with you. In this case we’re not modeling something, we’re defining it. As long as we give something a name, it will always appear as simply one alternative amongst many. XP is an alternative to Scrum, BDD is an alternative to TDD, Ruby is an alternative to Java. But well-written tests, or frequent, iterative feedback? There’s no reasonable alternative, those are just good development practices.
Surgeons don’t wash their hands because they’re “Agile” or “HyperClean” or “Pasteurific”, they do it because they understand why sterile procedure is important. Likewise, in software we need to get people doing the right things because they fundamentally understand the value, rather than because they’ve been promised success via some (dare I say it?) silver bullet.
January 4, 2009 at 7:39 am
Why do you need to emphasize “Agile” on your business card? Why is “Agine Developer” better/cooler than “Software Developer”?
January 7, 2009 at 5:28 pm
I believe the marketing term is “differentiation.”
January 7, 2009 at 11:22 pm
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.
January 14, 2009 at 1:14 pm
“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.
January 14, 2009 at 4:11 pm
@Gina (aka PM Hut),
I don’t think I could disagree more with your central assertion, that ‘Agile’ is nothing more than ‘Waterfall done right.’ As you say yourself in your article, Waterfall “infers structure, [and] control.” This is the hallmark of the Waterfall methodology: the assumption that you can predict and control outcomes. Ohno Taiichi wrote famously about the drawbacks of this defined process approach, and how it focuses on maximizing the benefits of a mass production system. Control exists in mass production because of repetition; if you know how long doing something took, you know how long doing that same thing 1000 times will take.
Software simply doesn’t fit the mold of mass production; if we write the same software more than once, we’re wasting time. Software is, by necessity an industry of custom work.
Astute programmers have accepted that predicting and controlling a software development process is untenable. Rather than throw up their hands in defeat they chose to try a different strategy: try something, get feedback, correct as necessary, repeat frequently. Call it Just In Time, or empirical process modeling, or Agile, or Engelbert Humperdinck, it’s about as different as different gets.
Also from your article: “It’s difficult to implement [Agile] when… time to market and budget cannot be shifted.” This is a common, and in my opinion amusing, misconception of iterative development. I can say “this project will be complete on September 30, 2009,” but that doesn’t mean it’s going to happen. By eschewing prediction, iterative development doesn’t mean we just iterate until we figure the project is complete, deadlines and budget be damned. It means we do as much as we can up to that deadline or budget cutoff (highest priority work first, of course). So, in this way you could call it ‘reality-based development,’ as compared to ‘guess-based development.’
That’s different.
January 15, 2009 at 4:39 am
Okay, so I was there at the birth of XP. I don’t pretend to be Ward or Kent or Ron. But I was on C2 when Beck started his exegesis. I wrote the early “XP Challenge” pages. And by a show of hands at XP-2000 I was the only person in the room apart from the 3 extremoes who’d actually run an XP project. And I was one of the dirty dozen at the “standup in the med” afterwards when Dave Thomas turned to Fowler, Beck, Johnson, Cockburn, Jeffries, Uncle Bob and a few more alpha-geeks who know who they are and actually said, “Rational are going to start promoting XP next month. That’s it. We’ve won!”
A few weeks later came the Agile manifesto. I missed that bit which was probably silly of me – from here it certainly looks like I skipped out on stopping working for a living. It was partly a way to just prevent squabble between Cockburn, Beck, and the DSDM/Scrum guys.
But it was mainly a way to write books.
I wasn’t looking to make money on XP and didn’t have the patience to write about what was already well described for free on Cunningham’s wiki. It was, as it is, just good engineering. Lots of other important things to do.
Having worked through it and before it, I can say Agile isn’t just XP. But it is mostly XP. Beck’s original dozen practices, more than the manifesto, are what Agile mostly markets. If you’re doing them, or modern variants of them, you can call yourself Agile no matter what your toolset or problem domain.
Agile is just the word invented so no one has to say “Extreme”.
February 23, 2009 at 7:58 am
Hey, there’s actually a picture of that moment: http://www.martinfowler.com/articles/poetta.jpg
June 23, 2009 at 1:32 am