So you practice agile? No, you don’t. I’m actually positive you don’t. Why? It’s simple, “Agile” isn’t a thing.
The word “agile” is an adjective. Remember 6th grade English class? We learned about adjectives – they’re an attribute of a noun. What’s a noun? A person, place or thing. These days however, the word “agile” has been hijacked. It went from an adjective, to a noun, seemingly overnight. You hear it all the time– things like, “We practice agile”, “I’m an expert in agile” or “I am an Agile consultant.” In these examples, the word is used not as an adjective but as a noun. As if agile itself is a thing. In some cases it’s even awarded the capital “A” – so not just a noun, but a proper noun! Have you ever tried explaining what you do for a living to your family at Christmas or to your new significant other’s parents? You tell them you practice “Agile” as opposed to traditional project management and subsequently try to explain both. They look at you cock-eyed. Why? Because “agile” isn’t a noun. It even sounds weird when you say it.
Remember those seventeen anarchists who met at a ski resort back in 2001 and drafted the “The Agile Manifesto”? That one simple document that now serves as the Holy Scripture of the agile community? No, you don’t, because that’s not what it’s called. It’s called “The Manifesto of Agile Software Development”. Do you notice the difference? The authors of the manifesto used the term correctly. They used it as an adjective with no intention of it becoming a noun and with no intention of creating an entire industry based on their findings. They were simply documenting the things that, when valued, increase a software team’s agility. In fact, it’s essentially derived from things that the authors knew universally impeded agility. Somewhere along the line however, we transformed this to a whole methodology of what teams ought to do. This age of agile-nounism and two-day-certifications coined the new title “The Agile Manifesto”. Check the website– you’ll find it still reads “Manifesto for Agile Software Development”.
So what was the impetus behind the change? What made people start referring to “Agile” as if it’s a thing? Why are you always confused as to whether or not you should capitalize the term when you use it? Simple– money.
The truth is, agile sells. Wait, let me rephrase that. Agility sells. And rightly so. Teamsshould be agile (in the adjective sense). They should be able to to move quickly and easily and execute on projects in a way that works. Teams and companies rightly desire agility. But guess what? You can’t sell an adjective, at least not easily. It’s a lot easier to market a noun (a thing) than it is something abstract, like “agility”. Consider these conversations between the two of us:
Me: I’m an expert in increasing a team’s agility. If you pay me $150 an hour as a consultant, I’ll turn your team into a high-performance machine.
You: Ok, how do you plan on doing that? What’s your strategy?
Me: Well, it depends. Every team is different.
You: So you don’t know exactly how to do it?
Me: No. I mean.. Yes.. I mean.. There’s certain principles that if the team begins to value and promote will undoubtedly increase the overall performance..
You: Riiiight..
Tough sell. Contrast that example to me trying to sell you a noun — something concrete:
Me: I’m an expert in this new methodology that everybody is talking about. It’s called Agile. Even NASA uses it. I can teach your team how to do it just a few days. If you pay me $150 an hour, for those two days as a consultant, it will turn your team into a high-performance machine.
You: So there’s a proven method?
Me: Yes.
You: And you’re an expert in it?
Me: Yes, I’m certified by the Alliance of Agile.
I get it. These are over-simplified examples, but do you get the picture? Notice in the second example how it’s much easier to sell someone something that’s portrayed as a rock-solid, proven, technique (a noun)?
The problem is, “agile” isn’t a rock solid methodology. In fact, it’s not a methodology at all. The values detailed in The Manifesto for Agile Software Development are just that– values. And if employed (valued) in the context of a team, they do help with agility.
This is why (I would argue) that 90% of the teams I work with are in a confused state of practicing “agile” when I arrive. They call themselves “agile” not because they are abounding in agility but rather, because they run sprints, or write user-stories, with often little understanding of why they do these things, to boot. There’s typically very little agility that comes from their new “Agile” approach and they often still reek of PMI doctrine. Not to mention, there’s almost always arguments amongst the team about what “real” agile is and the constant protest of, “At my last company, we were actually agile, and we did.. [fill in the blank]”.
They were sold agile as a noun — as a one-size-fits-all approach to minimizing churn, maximizing value, and making management happy.
To add to the travesty, companies capitalized on this newly crafted noun-approach to agile because, where there’s a buzz word, there’s money to be made. In today’s tech world there’s untold numbers of agile coaching companies, consultants, and organizations offering (selling) certifications, tips, tricks, books, services and conferences. Don’t you find it interesting that the majority of these “certifications” take a single weekend to attain? I’ll tell you what that says about the training– they don’t have much to say! Why? Because the whole “methodology” is based on 12 simple values that a 3rd grader can understand. It’s impossible to instruct someone on how to implement these (in a way that works) when the instructor has no insight on the individual teams, company structure, tools, projects, technology or culture of where the students come from. It’s bizarre. It’s money. Money. Money. Money. End rant.
Let me stop an say, I’m not implying that everyone involved with the organizations that offer these weekend-certifications don’t have good intentions. They do. And I don’t mean to imply they provide no value at all. They do. It’s great to learn best practices from others who have struggled with making teams efficient. It’s undoubtedly helpful to learn the concepts of what an agile (adjective) team values and what they could look like. But, it’s not always conducive to actually breeding much agility back home.
So what’s my point? Let me start with a confession:
I’m an agile coach. At least in part. I work with dozens of teams at some of the largest and smallest organizations in the country. I’m certified by a large agile organization and I often refer to Agile as a proper noun with a capital “A”. The problem is, I get burned by doing this. What do I mean? People expect me and the organization I represent to roll out a single noun-like solution that will fix their problems in one go. I don’t have that. Nobody does. But, that’s OK.
The value I bring is my experience working with dozens of teams — seeing what works and what doesn’t. I know solutions for specific common problems. I understand each organization is different, so the approach is always to first assess the business, spend ample time identifying the real problems, not just their symptoms (a common misconception) and then to institutionalize specific solutions. Sometimes, these are simple. They’re “agile” things. They’re scrum boards, cross-functional teams, and story points. Other times, wait, no — most of time, they’re more complex. They’re tailored to the business. They’re solutions that would never work anywhere else or with any other team, but they work. They produce agility. They produce high-performing well-oiled machine-teams that go bang on all cylinders, and that’s a beautiful thing.
Being truly agile is about doing what works for you, avoiding what doesn’t and changing often. It’s not about a methodology, a certification, a ceremony or a checklist of things a team ought to do. More often than not, it’s just the opposite– true agility comes when you master what not to do. In light of this, my message is:
Welcome the idea that there is no single solution. Don’t buy into the idea that agile is a thing that you do. It’s not. Seeking to become more agile by prescribing a specific methodology is the antithesis of true agility. If you’re going to spend money on helping your team transform to become more agile, that’s good. Just be sure to spend it on someone who understands that agile is not a noun. Make Jeff Bezos proud– try, fail, change, then try again. Be agile.