Defining "Agile"

Yeah, I know...hasn't this been argued to death?

Folks have criticized agile ideas by saying the whole approach is vague because there is no definition of what "Agile" means. Other folks fall back on the dictionary definitions of "quick and easy of movement" or something along those lines. Individuals known in the community have said there isn't, and likely shouldn't/can't be a definition, e.g.:

Scott Ambler has said - “the agile community will never settle on a common definition for what agile is and more than likely are smart enough not to even try.”

Alistair Cockburn has said - "finding the 'true center' of agile can’t be done. There is no 'center' to agile development. There’s only proximity of similar-but-different personal value systems coincidentally producing similar recommendations."

Of course, people have and are trying to define agile (or, at least, how agile one is), sometimes through standards work, sometimes through assessment and capability scales, sometimes through tests and certifications.

Alistair's point comes from how the term came into existence as a description for what a number of people felt they shared in common with regard to software development ideals. Since what emerged when those people met was from many people's perspectives, each with their own practices and techniques, a "center" wasn't likely.

But, to an extent, I must disagree that there is no definition of "Agile" since what that group of people did in 2001 was precisely that. When someone says, or I read someone state, that there is no definition of "Agile," I must point to the Manifesto's Values and Principles. Before those people created the Manifesto and the subsequent principles, there was no definition for "Agile" as we use it in software (and elsewhere for some of us) today.

It is my belief that the Manifesto's Vs & Ps define what Agile is. Agile is an adherence to those Vs & Ps in getting work done.

Now there are many practices and techniques one can employ that may be closer to or farther from the Vs & Ps. But that's about the "how Agile are you" question, not what it is.

Whenever I have taught Agile intro classes, I start with the Vs & Ps and try to make sure attendees understand what the Vs & Ps say (and what I think they mean in practice). When talking about specific methods and practices, my goal is always to point back to the Vs & Ps to say, in effect, "and this is how method X [and/or practice Y] implements Z" (Z being one or more Vs & Ps).

Now there are surely many methods and practices that can be used to implement given Vs & Ps, but I think there is a "tether" back to the Vs & Ps. It may be made out of Bungee material so, if you really stretch it far, you'll get snapped back.

Some people may cut that tether, either accidentally or on purpose, of course. When trying to fit something new into an organization, "tailoring" methods and practices seems quite the "practical" approach. But if you don't honor the tether, i.e., you cut it, you can end up rather far from the intent of the Vs & Ps and miss the whole point and value of the methods and practices.

I don't want this to sound like some "if you failed at Agile, you didn't do it right" rant. I certainly think, like anything, Agile might not work in your environment. I do think that, if you start off focused on the Vs & Ps, you'll have a better idea, sooner, if that is likely to be true. And you'll know whether any "adaptations" or "tailorings" you make are likely to draw you further away from the intent and benefit of the Vs & Ps.

So, really study the Vs & Ps. Talk them over with people in your organization. Talk to people doing coaching and training about what they think the Vs and Ps mean/imply. When you've done this, then make a commitment to some method/practices and try them out. Doing this investigation shouldn't take long, and you will certainly save time and money later by doing so. You'll also avoid antagonizing and stressing a lot of people in your organization by making sure they understand what Agile means.