I went to the Agile Midwest conference last week and I heard a lot of people talking about their agile experience in the context of what they were doing. People said things like “I’ve been doing agile for 3 years.” Many people said “using agile” instead of “doing agile,” but in most cases, it amounts to the same thing. I found these descriptions of agile experience very interesting, especially given the context of a conference full of people who are invested in agility.
I like to think of agility in the software development in the context of the metaphor that it’s derived from: physical agility, the ability to move quickly and easily. In this context, agility is a spectrum. You might say that an elderly person using a walker isn’t very agile. You could also say that I - who can get around without aid, but can’t touch my toes - is more agile. And you’d likely say that an Olympic gymnast is more agile than either our hypothetical elderly person or I am.
If you were asking a person about their physical agility experience, they likely wouldn’t ever say that they’ve been “using agile” or “doing agile.” This is because physical agility is a state of being. A person might, however, say that they’re more or less agile than they used to be. In this context, “doing agile” might be something like practicing yoga or parkour. A person engaged in one of these activities would be more likely to tell you about the specific discipline or exercise regimen that they’re engaged in that enhances physical agility. They might even go on to explain how that activity has enhanced their agility.
Much like physical agility is a state of being, so is business agility. Business agility is the ability to respond to the changing needs of the organization. These can range from changing features in the products we sell to changing the way we create the products to shifting to a whole new product line entirely.
When people talk about “doing agile” or “using agile” they are usually referencing a framework or some other defined set of practices. Typically, this is something like Scrum or XP, or perhaps, simply a collection of practices such as daily stand-up meetings, retrospectives, pair programming, etc. Now, there’s nothing wrong with this, per se. Perhaps they’re just using a short hand to describe how they’ve achieved business agility. “I’ve been doing agile for three years,” becomes something like, “I’ve been doing Scrum for three years to achieve a greater degree of agility.” If that’s the case, we just need to be cognizant that this is the concept we’re conveying.
The difference between the two is the difference between the means and the end. Being agile is the end goal. Doing agile is the means to that end. No one is going to care that you’re working in sprints and delivering every two weeks if the product isn’t addressing customer needs and you’re not adapting the product to that landscape. Your developers aren’t going to care about their retrospective meetings if your organizations processes are so rigid that they don’t have any space to do things differently.
When we talk about doing agile, we should always have the question in the back of our minds, “How is what we’re doing contributing to agility?” The answer shouldn’t be, “It’s a stand up! It is agility!” The answer should address some situation that’s unique to your business that has been improved by those practices. If not, it’s time to inspect and adapt. That’s agility.