I just came across an interesting post on The Hijacking of the Word Agile. Here is a quote from that post that got my attention:

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.

Inspired by the list of weird behaviors in that blog post, I thought I’d create my own list. Here are some similar so-called “Agile” actions I’ve seen:

• Quote: “We do releases every 3 months, so we’re Agile.”
• Quote: “We don’t have a process or do much documentation, so I guess we’re Agile too!”
• Being in an organization for months, and seeing no outward clues of anything remotely Agile going on. Later, we were told the organization was following an Agile method that normally is very visible (as in “hard to miss”); most people there had no idea they were doing anything Agile at all.
• “Quality Police” moving from enforcing traditional processes to enforcing Agile processes. This included political manipulation and attempts to humiliate or blackmail developers. All under the banner of “Agile Testing”.
• Copying a variety of RUP, iterative development and Agile writing quotations. Mixing them up into a cornucopia, that, when used out of context, sounded an awful lot like what the team had been doing all along.
• Consultants taking CMM or V Model, (or whatever they have been selling for years,) and sticking the term “Agile” on it, (presumably for the marketing buzz), without actually investigating Agile processes and adapting.

It’s not surprising that this kind of behavior by those ignorant of Agile methods, turns some people off of the term “Agile”. Couple that with some of the obnoxious Agile elitism and zealotry that is displayed by a few who are well-versed in and experienced with Agile methods, and even more people are finding themselves suspicious of this marketing term “Agile”. Tim Beck decided to do something about it, and came up with his own term for software development: “Pliant Software Development.”

We like and use many agile techniques and methodologies. We believe that in theory, agile development and pliant development are pretty much the same. In practice however, we feel that agile development has become a little too un-agile. There are whole sets of “process” which fall under the banner of agile development and unfortunately some people have gotten to the point where they are unable or unwilling to veer from the prescribed course of action. This leads to problems, because no two software development projects are the same. There are far too many technical, social and political issues to be able to come up with a 12-step program that fits all software situations.

–From the Pliant Alliance FAQ

Here are some different ideas on “Agile” from various people:

Unfortunately the industry has latched on to the word “Agile” and has begun to use it as a prefix that means “good”. This is very unfortunate, and discerning software professionals should be very wary of any new concept that bears the “agile” prefix. The concept has been taken meta, but there is no experimental evidence that demonstrates that “agile”, by itself, is good.

The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

The Agile Alliance worked very hard to create a manifesto that would have meaning. If you want to know their definition of the word “agile” then read the manifesto at www.agilemanifesto.org. Read about the Agile Alliance at www.agilealliance.org. And use a very skeptical eye when you see the word “agile” used.

—Robert C. Martin

It really gripes me when people argue that their particular approach is “agile” because it matches the dictionary definition of the word, that being “characterized by quickness, lightness, and ease of movement; nimble.” While I like the word “agile” as a token naming what we do, I was there when it was coined. It was not meant to be an essential definition. It was explicitly conceived of as a marketing term: to be evocative, to be less dismissable than “lightweight” (the previous common term).

—Brian Marick

…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.

—Jim Coplien

As with any mythodology, principles that begin with reasonable grounding can be misapplied and corrupted. This reminded me of James’ observation that the Traditionalists and the Agilists are both instances of the Routine or Factory School of Software Testing (as Bret Pettichord describes in his wonderful paper Four Schools of Software Testing). I may disagree with James to the degree that I don’t think the early or smarter Agilists intended to behave in a Routine-School manner, but I think he’s right to point out that a large and growing number of their disciples appear to have slipped into Routine behaviour.

The common element between Bad Traditionalist processes and Bad Agile Processes is that both want to remove that irritating thinking part.

—Michael Bolton (emphasis mine)

The lesson to me is this: our words are important. When a term is used in many contexts meaning something different in each, it’s a vague word. When a word is vague, it is important to get a definition from the people using the word. Otherwise, it may only seem like we are using a shared language, when we really aren’t. We should also be careful with our own language, and the terminology we associate ourselves with, because, in the case of vague words, it can have unintended consequences.