There seems to be a lot of confusion these days about whether something or other is really Agile, and what that means. Here’s my take on how to sort that out.
Growing up, I lived in a city called Grand Rapids. As you’d expect, there’s a river running through it. Does the river actually have rapids, and if so, are they truly grand? Do other rivers have rapids more rapid, or perhaps more grand? Those questions are interesting, but from the perspective of the name, it doesn’t matter. A long time ago, somebody thought that was a good name for the place, and it stuck.
A decade ago and more, a bunch of people were working on new software processes. They were very different than what had come before, but they all had something in common. It was hard to put a finger on exactly what that was, but eventually they got together and came up with four value statements and twelve principles. And they came up with a single word: Agile. As in “Agile Manifesto” and “Agile Software Development”.
Was this perfect? No. Was it meant to explain everything about software development for all time? No. Was it a software development process on its own? Definitely not. But it was a declaration of common purpose, a list of things they could agree on.
That’s what capital-A Agile is: a bunch of people seeing that they had something in common, and attempting to say what that common thing was. They gave it a name and a partial definition. And most importantly, they formed a community that is still working out what that means and how best to do it.
It’s important to note that they weren’t saying that they had an exclusive lock on agility, or even what made software development agile. As with the naming of Grand Rapids, they were pointing at a particular spot in the landscape of ideas and naming it. The word agile has a variety of meanings, and there are a lot of aspects to software development to which you could apply those meanings. They weren’t trying to lay claim to agility as a whole, any more than Grand Rapids is claiming all the rapids in the world, especially the grand ones.
That also means that there are plenty of ways to develop software that aren’t Agile. After all, software got made long before the Agile Manifesto was written. And there are surely ways of being agile that aren’t included in either the Manifesto or in the current practices of the Agile community. Heck, that’s part of why we get together every year, and talk so extensively on line. Processes based on continuous improvement gives you a real taste for continuously improving that process.
Saying “that’s not Agile”
So given this, what does it mean when somebody says “that’s not Agile”? To me, it just means that the thing they’re pointing at is a different spot in the landscape of ideas.
Some people get upset when they hear that, because they believe they’re doing well at making software, or because they think they’re being pretty small-a agile. They may or may not be right, but that doesn’t matter. If people in the Agile community say that something isn’t Agile, then it probably isn’t, the same way the city of Grand Rapids gets to decide where the city limits are.
If it bothers you to get told that something isn’t Agile, you have three basic choices:
- Find out more about what we mean about Agile. We’re generally a friendly bunch, glad to show you around. Join a mailing list, come to an event, or even ask in the comment box below.
- Persuade us we’re wrong. If Agile is the city we’ve built on the landscape of ideas, it’s a city that’s grown a lot over the years. It in effect started with a number of different little towns growing together. More recently came Lean, but these days it’s getting hard to even tell where the boundaries used to be. We’re very open to new construction, and your idea might be the next big development.
- Start your own thing. Agile may be the big thing of the moment, but it will eventually be as obsolete as the cavalry charge. Just because we say that something isn’t Agile doesn’t mean that it’s not a good idea. If you’re sure of yourself, do what the Agile founders did: stake out your own territory in the landscape of ideas and give it a name.
Regardless, there’s no need to get upset. Having different approaches or coming from different schools of thought doesn’t mean we don’t share the same goals in the end.