The Failure of Agile

—Andy Hunt

05/06/2015
Published in Andy's Blog

I am proud to be one of the 17 founders/authors of the The Agile Manifesto back in 2001. I think it provided a jolt of energy, hope of a better way of doing things, of creating software and making the world work better. It was a pivotal turning point.

But in the 14 years since then, we‘ve lost our way. The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they’ve forgotten their aim.

And worst of all, agile methods themselves have not been agile. Now there‘s an irony for you.

How did we get into this mess?

The Joy of Rules

The basis of an agile approach is to embrace change; to be aware of changes to the product under development, the needs and wishes of the users, the environment, the competition, the market, the technology; all of these can be volatile fountains of change. To embrace the flood of changes, agile methods advise us to “inspect and adapt.” That is, to figure out what‘s changed and adapt to it by changing our methods, refactoring our code, collaborating with our customers, and so on.

But most agile adopters simply can‘t do that, for a very good reason.

When you are first learning a new skill—a new programming language, or a new technique, or a new development method—you do not yet have the experience, mental models, or ability to handle an abstract concept such as “inspect and adapt.” Those abilities are only present in practitioners with much more experience, at higher skill levels (see my article Why Johnny Can’t be Agile for more).

The only way for beginners to be effective is to follow simple, context-free rules; rules of the form: ”When this happens, do that.” And since agile methods conveniently provide some concrete practices to start with, new teams latch on to those, or part of those, and get stuck there.

So instead of looking up to the agile principles and the abstract ideas of the agile manifesto, folks get as far as the perceived iron rules of a set of practices, and no further.

Agile methods ask practitioners to think, and frankly, that‘s a hard sell. It is far more comfortable to simply follow what rules are given and claim you’re “doing it by the book.” It’s easy, it’s safe from ridicule or recrimination; you won’t get fired for it. While we might publicly decry the narrow confines of a set of rules, there is safety and comfort there. But of course, to be agile—or effective—isn’t about comfort (see my article Uncomfortable with Agile).

And if you only pick a handful of rules that you feel like following, and ignore the hard ones, then you’ve got it made! You are ”doing agile” if anyone asks, and you can focus your energy on enforcing a small set of largely useless rules. Everyone feels better. Until it’s time to actually ship something.

Stuck in a Concrete Rut

Following a rigid set of rules limits your performance to that of a novice (see my book Pragmatic Thinking & Learning: Refactor your Wetware for more). So teams find themselves unknowingly stuck in a rut: blindly following the concrete rules, not gaining the experience they need to get to the point where they know they need to move beyond the rules.

It’s all too common these days to see arguments on Twitter or mailing lists with these rules-bound zealots arguing that ”you’re not agile” because you aren’t following the rules to their satisfaction.

What happened to the idea of inspect and adapt? What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand? The canonical agile practices of popular methods have remained essentially unchanged for over a decade. We are stuck in a rut.

And as I’m fond of saying, the only difference between a rut and a grave is the dimensions.

A Way Forward

Now there have been many folks complaining about the agile movement, some quietly, some loudly, and none of these complaints are novel. But here‘s a new twist: let‘s fix it. Right here, right now. Together, we can fix the inherent problems in agile adoption and evolution and help move the industry forward.

First off, we need a name. A loose collection of good ideas doesn‘t generally get much traction in the world. There has to a be a name, a brand, to hang it on. Let’s call it:

The GROWS™ Method.

GROWS in this case is an acronym, for GRowing Real-World Oriented Working Systems. It’s an idea Jared Richardson and I (Andy Hunt) have been working on.

These seem like important concepts: software is not designed and built; that’s far too a deterministic, linear model that doesn’t work here. Growing is a better metaphor, because with growth comes change. Real-world oriented is a nod to the idea that we need to base all our decisions and direction on actual evidence: feedback from the real world, under actual conditions. Anything else is just some unfortunate combination of a fantasy and wishful thinking. And of course, working software, our ultimate deliverable. But not at the expense of a working, functional team and overall organization. The software, the team, the users, the sponsors all form one system. And we need to make sure the whole system works, for all the participants.

So let’s base our ”new” method on four foundational ideas:

Evidence-based
Dreyfus Skill Model
Local Adaptation
All-Inclusive

That is, every team should be able to inspect and adapt based on actual evidence, on real-world feedback. But to get them there, we need to use the lessons of the Dreyfus Skill Model to provide support for beginners and latitude for more advanced practitioners. With that framework in place, we can position every team to adapt themselves to local conditions, safely, based on actual evidence. And finally, whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors. There is no ”us” versus ”them.” There is only us.

In the next post, I’ll take a closer look at each of these foundational ideas.

If you find this sort of thing interesting, please join us at growsmethod.com and sign up for our mailing list.

With your help, we can fix this thing.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.