The Hijacking Of The Word Agile
Before you read this post let me assure you that Agile Development is great. It includes some common sense ideas and good practices which can help many projects succeed.
Now that we got this out of our way, let’s start.
The word “Agile” was first hijacked to describe a set of software development processes, methodologies, practices and principles. This seemed like a good idea at the time. But soon it became apparent every process, methodology, practice and principle which were not part of this exclusive set was automatically labeled as “Non Agile”.
Since being agile sounds very sexy and attractive, no one really wanted to be “Non Agile”. And so, Agile became the second most popular search string used by software practitioners in Google (right after Web2.0).
This post is not about that hijacking (although I’d be happy to discuss it some time). It is about the second hijacking of the word “Agile”.
It wasn’t long before the word “Agile” was attached to numerous books, practices, tools and concepts for pure marketing reasons.
Maybe the first documented “confession” of such an act is available in Jim Coplien’s book Organizational Patterns of Agile Software Development:
“These notions of healing, repair, and growth are the foundations of Agile development. O.K., we’ll be frank: we chose “Agile” for the title out of marketing concerns. It seems to be the current term of choice for the kind of things we describe in this book.”
Luckily, Jim Coplien’s book is a great book with or without the word Agile in its title. But the idea that the word Agile can be used as a great marketing spin spread like fire. Which brings me to the issue I want to discuss…
The word “Agile” seems to have been hijacked once again. Now, it is commonly used to justify just about any bizarre “practice” and strange behavior in a software project. In some cases, it is even misused to justify complete chaos.
The following list includes eight examples of anomalies which are often justified as being “Agile”. Read them and weep.
1. Changing requirements and external interfaces three times a day
If that’s not embracing change, I don’t know what is.
2. Planning a 6–months project to be delivered in 3 months (using the same resources of course)
Agile does mean fast, doesn’t it?
3. Using Excel to manage 549 interdependent tasks
We favor simple tools on costly fancy ones.
4. Writing quick and dirty code
We can always refactor it later, can’t we?
5. Waiving formal testing
Our developers did spend all this time on unit testing. At least we hope they did.
6. Working on four projects at the same time
Sounds Agile to me.
7. Using only a white board to design a 100 man-months project
We still favor simple tools on costly fancy ones.
8. Erasing the white board accidentally after one month
Ooops… :|
June 7th, 2006 at 11:44 pm
Interesting.
June 8th, 2006 at 3:25 pm
Nicely done. Agile is not a bad concept although as you point out, adopting the name was a cynical marketing exercise. Why are people surprised when they oversimplify and use buzz-words that someone else will latch onto their buzz-words for truly evil purposes?
June 22nd, 2006 at 3:04 am
First, I enjoyed this piece. Second, It’s good to get these cautionary words on mangers’ plates. Too many ideas have gained mindshare for all the wrong reasons. I shake my head at the ones I’ve watched do so first-hand: “knowledge bases,” “object-oriented,” “user-friendly,” and now of course “Agile.”
But third, it’s informative to go beyond the “buzz” of “buzzword” to dig a bit deeper to see what’s there. A number of folks who have given the issue a second thought now believe that the term “adaptive” is a better term for what the careful “Agile” thinkers originally aspired to, and I agree. I think Jim Highsmith was the first to articulate this nuance, and I think it was in the context of XP being a wonderfully Agile way of doing things that was in no way adapative. I try to use the latter term more and more these days. Because it hasn’t (yet) attained buzzword status it helps encourage people to stop and think rather than to jump to conclusions. That — along with the simple principles of customer engagement, product focus, the human touch, and system dynamics — is what’s important to me.
As for the Org Patterns book — yes, we had a little fun with that. Coming up with a title was actually quite difficult. And though Lidor’s book excert above is on the mark, it’s not the only ratioinalization of the title. Most of what is called “Agile” today can be traced back in large part to the early stages of the Org Patterns book. Jeff Sutherland says that the morning meeting concept of SCRUM can be traced back to the Borland QPW study that was one of the foundations of the Org Patterns book (http://www.agilealliance.com/articles/sutherlandjeffinventi/file). Even Kent Beck gives homage to the Org Patterns work as one of the three foundations of XP (http://www.oopsla.org/2002/ap/files/spe-metahpor.html). And so on and so forth. Think of the Org Patterns book as a catalog of the principles and structures of Agile; think of most of the rest as being best known for their processes.
What I’ve found intriguing lately is that a rash of adaptive projects started appearing around 1991, at about the time the Org Patterns research started. That’s when Ward Cunningham’s WYCASH Way was in full swing, as well as the Borland QPW project. I am finding more all the time. It’s like there was something in the air, or in the water, and it was everywhere. The industry underwent a shift in thinking at that time and you owe it to yourself to look at the publications of that time to see how quickly things were changing. I like to think that the QPW article was a catalyst, some turquoise stuff in a glass beaker, that helped give visibility to some of those ideas that even then were tried and true (I think Tom DeMarco had said much about pair programming years earlier; unit testing was old hat; etc., etc.). But those old ideas needed a meme to turn on the thinking gene in software project management. The potion turned some people into thinkers who explored things more deeply — people who turned on their thinking gene and who were able to hear the voice of experience. That’s most of what patterns are about: codified collective experience, made personal through careful feeling and thought. Unfortunately, it turned other people into sheep or, maybe worse, lemmings. Turquoise stuff in glass beakers can have such diverse effects.
June 22nd, 2006 at 10:21 pm
Interesting. In my company, the head of SEPG who is responsible for “bring agility” to our current process once mentioned in an email that documentation has no formal place in an agile process and human interaction is all that matters (!!!), and he suggested that the business analysts should not write any Use Case documents anymore. I guess his next step would be, as you said, telling the developers to use white-board for all design activities. Oh, God helps me.