Why you should probably never say “Agile”

The Agile Toolkit wasn’t made for you.

In the world of business, the word “agile” has been over-used into virtual meaninglessness. It had a very specific meaning almost 20 years ago, and decayed rapidly under the distorting forces of rampant commercialization like I described in my How Marketing is Destroying Agile (link) article.

In 2014, Dave Thomas, one of the founders of agile, posted his own screed, titled It’s Time to Kill Agile (link), calling for “agility” over “agile”. I would agree with Dave were it not for one thing: agility is even more poorly understood — really more of an attitude than anything — than Agile is; what do we possibly improve by making it more vague?

Having been around Agile for way longer than I would like to admit, and having had literally hundreds of conversations with copmpanies, well over 100 of which hired me and my team of neo-post-agile coaches to help them do something that creates results like you would expect from Agile, I can tell you most people think they know a lot but they don’t know shit.

I sometimes do an Agile IQ quiz with a new client, where there are a total of 100 points available for correct answers. I ask everyone how high they think they will score. People who rate themselves a 4 or 5 (out of 5) on an experience scale will predict that they will score 80 or more.

It is not a difficult quiz — if you know Agile pretty well, or even just understand how basic empowerment-in-action works, you’ll score 100 or close. Almost everyone scores less than 50.

The funny thing is, if they really understood what Agile is, or what it was designed to do, they would realize it is not for them, was not built for them. And in not doing so, they create and cling to the fad that is agile today for many, Random Agile.

In reality, Agile is a very specific thing built for a very specific situation. It is not easy to do, it is not “flexible” in the way that most people think of flexible…it requires a level of rigor and effort at customization that goes far beyond what people know.

What is Agile?

I’m sure you know the basic idea: it is a way to run a software development project. So here’s my question: does your work look like a software development project? Maybe, I guess it can at times, but let me explain more about what type of project these techniques were designed for.

Software Agile was designed over a 20 year period as a set of techniques that would help solve the problem of how to build very large software systems. You can read more about that here, in a book published in the 1970’s called The Mythical Man-Month (link). How large of a project? We’re talking 200 staff years worth of work, maybe 50 people all working on the same (one) thing for four years. Does your work look like that?

You’re probably familiar with some of the Agile techniques, like the stand-up meeting, or the lightweight planning (sticky-notes-on-a-wall) technique, but do you know what the fundamental problem was that Agile solved? Was it that software developer teams were not “agile” enough? No.

The problem was that very large projects are very hard to describe, define and understand. In fact, the size of the written specification for a 200 staff year project is so large that nobody could really understand it, and fewer people could even say whether it is right. Does your work include a lot of things that are so hard to understand that you can’t write them all down? No, nor does 99.9% of all other work in this world.

Agile was built for 0.01% of all projects in the world.

A key concept in Agile is the team. But Agile teams aren’t like your teams. These teams are dedicated to work on a single project for several years. Not your teams. Another important part of Agile is that the team should not be bothered by managers, or changing needs, or other projects. Agile dictated to managers: “Stay the f**k away from the team.” That is hard for anyone to honor, but much easier if you know they are only working on one thing and it will take a long while as was the case with Agile. Would your business function if you had to leave teams in isolation for two weeks before you could ask them to work on something different? Probably not.

Here’s what Agile is:

• a detailed set of processes designed for a very specific and rare business situation
• a method by which dedicated teams can “chip away” at the project, choosing which part to work on next (this is the “agile” part), in order to more quickly build the right parts
• a framework in which teams work in isolation on a singular project for an extended period of time
• A framework, method and processes which requires months of tuning of by expert facilitator and coach in order to optimize how all the pieces work for a specific team

Unless it is purpose-built for you, it’s just Random Agile

Even way back when it all started, Software Agile was always hand-crafted for each team and project. This is the part that people seem to not understand. Software Agile was a one-off that required the coach to work full-time with the team for months. Each and every team.

Every truly effective implementation of agile is a one-off that has been highly tuned for the specific situation. We’ve worked with over one hundred clients and all of them thought they knew Agile, and none, really none of them were even close to getting any of it right.

For those of you that geek out on this, here is a more modern example of how a (really good) purpose-built Agile works only where intended. There is a specific set of Agile practices, called SAFe, designed for production software work. Note, this is different than the original Agile (big, unknowable software) problem I described above. Rather, SAFe is designed for environments that have multiple software projects going on, and often have shared resources, and better-defined specifications, etc. SAFe is a different purpose-built version of Agile (read: non-random), and from what I hear, it works pretty well in that situation.

A few years back a client called us to coach them on Agile — what that really means is, “Can you make it work for us?”— and they were already using SAFe, and they said it was working really well. Huh? Why call us?

Turns out that this company was really two companies in one: they did sweepstake and promotional marketing, so half of the company wrote software for a massive “sweepstakes engine” which was big, complex and always evolving software platform, and the other half of the company actually did the marketing .

Guess what, SAFe didn’t work in a marketing environment. Becuase it wasn’t made for that purpose. We showed them how to craft their own agile toolkit for marketing , and viola, they were Agile with some amazing results. You can read more about it here. I offer it as evidence that every form of Agile, in fact pretty much every instance of Agile needs to be purpose-built.

The Agile toolkit is just a random box of tools some dudes named “Agile”

The biggest misconception is that somehow these “agile techniques” are actually a general purpose toolkit. (Yet another way that the commercialization of Agile has destroyed it.) And for the most part, there are no “Agile” tools at all — every single item in that toolkit existed prior to the word Agile. Let me explain.

Imagine two real-world toolkits, one for an iPhone repair technician, and one for a plumber. Would the iPhone toolkit be useful for the plumber or vice versa? No, because they are such different applications. Could a watch repair person benefit from the iPhone toolkit? Possibly there might overlap that means that some of the tools can be applied, but they would likely not be optimal without significant additions or modifications.

Software agile plucked the “iteration” tool created at least twenty-years prior from a thing called Iterative Enhanced Project Management (IEPM), and renamed it a “sprint.” It lifted the Kanban tool, created in the 1940’s by Taiichi Ohno for the Toyota Production System, a manufacturing management method, and tweaked it for software. They also added the stand-up meeting, which probably has its origins in homo sapiens standing around the morning fire to talk about who will do what that day.

Enter the dudes. In 2001, after 10+ years of experimenting with a whole bunch of tools, 17 middle-aged programmers held a conclave in Snowbird, UT, and named the collection of tools that they preferred to use, “Agile.”

You want to use Agile? You need to make your own toolkit. Those dudes in Snowbird had no idea how your business operates or what it needs.

Why being agile, as in “agility,” doesn’t count

I cover this in more detail in another article called, The Elusive Search for Organizational Agile (link), in which I try to enumerate all the ways people say they are doing agile, but are not. At the far end of the spectrum are things like, “Hey, let’s all agree to just be more Agile.”

My favorite one from years ago was when I was asking which people we could count on to be part of the team that we would coach, and the executive replied that he wasn’t sure, but they would make sure that we always had someone. He said, “Hey, we don’t really need to be specific on this, do we? I mean, can’t we just be Agile?”

He had correctly identified that an aspect of Agile is dealing with uncertainty and then decided to co-opt it to mean that he didn’t need to make a commitment on anything. Nimble and deft in his handling of my question, yes, but he was not being Agile.

In order for us to change behaviors, change the way we work, we need to be specific about what the change is. Change doesn’t happen by platitude, but rather by well-explained and practiced behaviors. Tell people how to do a stand-up meeting, and they will fail. Make them do a stand-up, coaching them into a set of self-managed behaviors, repeat that 4–10 times and they’ll actually be good at it.

Random Agile, the type of Agile that exists in name only, is the result of platitudinous Agile behavior, using the word without any idea (or commitment) to do the hard parts. It makes Agile look like another management fad. I believe it has become that in the minds of many.

When its okay to say Agile

Here’s my short of situations in which you can say you’re doing or being Agile and actually be real about it:

• You are running a software project and authentically using a well-coached and tuned set of Agile tools. This includes something like SAFe if implemented authentically, and it is a fit for how you operate, the types of work and teams you have
• You took the time and did the hard work of crafting your own purpose-built Agile toolkit, and as evidence, the nature of your organization has changed, especially the way managers yeild to teams and the whole organization becomes much more “flat” in style
• You implemented your purpose-built Agile toolkit, and as evidence, the 20–50% of those people whom you had thought of as marginal performers, are actually really solid performers. You realize that the biggest obstacle that they faced was being poorly- or over-managed

I hope for you and many others to be able to authentically make the claim of being Agile. In reality, we both know people can say whatever they want. But now you know that I’ll be watching.

Jack is a recovering client services executive, former senior analyst at RAND, and the founder and CEO of AgencyAgile, a productivity training and coaching firm that helps agencies, marketers, and other complex service organizations transform using Agile and empowered processes