In 2021 I finally decided that the time had come to let “Agile” go. This is complex, so I want to be clear: I still value the Agile Manifesto and I still live the XP values in my daily life; however, “Agile” the brand has drifted far enough away that I no longer feel connected to it.

Yes… I know how ridiculously self-indulgent that sounded. Pompous, even. I get it. Who cares?! Please stay with me.

I mention this, not to puff my chest nor to play on your heartstrings, but rather to try to convey my intention more explicitly and clearly. I don’t hate Agile. I don’t even dislike Agile… depending on which “Agile” we’re talking about.

I digress. I want to have that conversation, but not right now. This is not that.

What Is This, Then?

I have made peace with one of the harmful consequences of the Agile software development movement: the expectation that going Agile means going faster. This expectation has driven many well-meaning adoptions and transformations straight into the ground. It has done real and lasting damage to people. It hasn’t even had the common decency to act quickly enough to spare their suffering. It has been awful and it seems like it was entirely avoidable, but it really wasn’t. And the worst part is that we didn’t even fail. We were never going to stop it from happening.

What Can We Safely Expect from Agile?

Going Agile simply doesn’t make you go faster. Worse, going faster would probably be a mistake, anyway. I know—I hate it, too, when I ask on a forum how to do something and the first five answers are “You shouldn’t want to do that”.

Even so, you shouldn’t want to do that. Probably. It’s complex.

I know that Agile (as we generally intended it) can help you figure out what not to do, so that you know how to use all your resources—time, energy, money—more effectively. Some people focus on improving efficiency through eliminating waste, some people focus on improving impact and value through working more closely with customers, some people focus on flow through limiting work in process and visualizing the value stream. Different groups need different things at different times. For example, a group might know very well how to create impact and value, but are continually distracted by bureaucracy, so they might focus on eliminating waste. Another group might need to learn how to create impact and assess value, but don’t know how to get started, so they retreat to the comfortable world of refactoring carefully and planning meticulously with story points. Agile has something for each of these groups, but it remains relatively easy to look where the light is brighter rather than where you might have dropped your keys.

Moreover, Agile can help you learn to trust yourselves and each other actually to use what you learn about where to focus. It’s not enough to know what you ought to do if you don’t feel safe doing it. Most Agile practices force us—often not gently enough—to confront the obstacles to psychological safety. I’m not talking about singing campfire songs together; I’m talking about candor, openness, vulnerability, and their role in helping us gradually cure ourselves of our inattention to the results that we claim to care about. The practices of XP, for example, provide us a way to train ourselves to work more closely together and more effectively together, but when we frame this training as “learning to go faster”, it rarely works. We often want to go faster without admitting that we’re not prepared to invest in struggling to work more harmoniously together. Maybe we can do that another way, but “Agile” isn’t going to get us there. Not intentionally, anyway. If we do it, Agile becomes at most an unwitting co-conspirator.

In general, “Agile” does not allow us to go faster while retaining core values of rewarding the individual, controling behavior through centralized policymaking, and undertaking large investments in projects with a predictable long-term payoff. I’m not entirely against those things. They have their place. I use them from time to time. And I don’t know how to do those things with “Agile”. I don’t know how to make “going Agile” equate with “going faster” while leaving everything else untouched.

And I don’t think anyone else does, either. I would view with suspicion anyone who claims that they do.

So how did we get here?

Agile = Faster? Since When?!

Popular ideas become diluted, then they take on a life of their own. I learned this from Jerry Weinberg, with his law of Raspberry Jam:

The wider you spread it, the thinner it gets.

I understood this originally as a warning against the common belief that, if you have a good idea and you want to help the most people the most effective way possible, then you ought to try to tell that idea to as many people as you can. This law tells us that we’re likely to fail. We can’t control how others interpret our message. We try; we fail. You’ve probably experienced this yourself. It creates a complex responsibility relationship.

  • On the one hand, I can’t control their interpretation; therefore, I refuse responsibility for it. (Self-compassion.)
  • On the other hand, knowing this effect, I need to take it into account when crafting a message that I intend to broadcast to a wider audience. (Compassion for others.)

Do you see the feedback loop there? I think it makes for an excellent exercise in Systems Thinking. It seems fundamentally unfair.

The wider you spread it, the thinner it gets—and your “new, improved, clearer” message is something you need to try to spread.

Good luck with that. It sounds hopeless. What now?

Here’s What Now

Accept. This is merely what people do. That’s what I take from the Law of Raspberry Jam. On my best days, I treat it as yet another constraint of the system: when an idea becomes popular, its message becomes abstracted1, in ways that I can’t control, often in ways that I can’t predict, and almost certainly in some significantly unhelpful way. You are virtually guaranteed to become a victim of your own popularity, so prepare yourself to deal with the fallout. As soon as the Agile Manifesto was published, its destiny was to have its key details ignored by an overwhelming population of its readers. “Misinterpreting” the Agile Manifesto was a clear sign of its growing influence. We wish it weren’t so, but calling it a leg doesn’t make it a leg.

And this is not fault of the readers; indeed, it’s an artifact of our successful survival as a species. That sounds grandiose… and it’s true.

Abstraction Saves Lives

Abstraction was a key instrument in human survival. Our brains can’t handle many details. We need to hide those details or risk freezing in place or becoming distracted. Either way, the tiger eats us. It’s really that simple. The details can fill a bookshelf, but this idea is enough to get started. If we blame people for abstracting our ideas, we might as well blame them for being human. Let’s not do that.

But It’s Right There!

It is. It’s right there in the Manifesto for everyone to see.

Simplicity—the art of maximizing the amount of work not done—is essential.

I can draw a straight line from here to “Sooner, Not Faster”. Indeed, that’s how the whole discussion first started! I understood “Agile” to mean something close to this:

  • Treat people as people.
  • Choose cashflow over long-term investment.
  • Remove anything that doesn’t help.

The last point relates to “Sooner, Not Faster”. When we “go Agile” we don’t suddenly do everything at triple the speed; instead, we figure out what we don’t need to do, then we have the courage and determination to not do it. And if we don’t have that courage nor determination, then we try to cultivate an environment in which we have it. That’s one of the ways that I understand the value of simplicity. This framing of simplicity has had profound effects on my life, both professionally and personally. It’s very powerful stuff.

Based on its power and importance, you might have the impulse to blame the reader for missing it when they talk about Agile. I know I did.

“Read the manifesto! It’s right there!!”

But most of the people in our audiences haven’t read the manifesto and that’s as it should be. They don’t have the energy; they’re too busy surviving their own metaphorical tiger attacks. They are far better off attending to the urgent issues that affect their daily life. It is a sign of privilege and luxury that we have taken the time to read the Agile Manifesto so attentively—let’s stop blaming those who don’t have that privilege for not having taken the same time and care that we have. It feels good to blame them… for a moment. It loses its luster fairly quickly. I know.

And I’m really, genuinely sorry for years and years of doing this myself. Not Canadian sorry, but sorry sorry. Truly. I got it wrong.

And that’s why “Agile = Faster”. It was always going to be thus.

I accept. I don’t always love it, but I accept.

And I still care. I care, but I don’t mind. I accept. In this one case, “it is what it is” isn’t just some pointless aphorism to me. I say it to remind myself that I accept, but I still care, and so I try to help people change their outcome.

Stop Me If You’ve Heard This…

Evidently I care so much that I forgot that I’d already written an article called “Sooner, Not Faster Revisited” in 2018 and tried to reuse the title for this one. “Sooner, not faster” truly matters. And the fact that so many people are not taking this advice to heart creates a marketing opportunity for us. I am happy to dive in with both feet.

And Now, The Subtle Call To Action…

If you believe that your organization is suffering from the belief that “Agile = Faster” and see the wisdom in “Sooner, Not Faster”, then please contact me and let’s talk about how we might work together to make things better. I’m looking for clients who fit this profile:

  • We do not want to fall prey to “Agile = Faster”. (Or maybe “we’ve had enough of it” or even “we’d like to be better prepared for it next time”.)
  • We do not merely want to complain about “Dark Agile” nor “Faux Agile” nor “The Agile-Industrial Complex” nor whatever the cool kids are calling it these days. We’d like to do something about it.
  • We do not believe that it helps merely to shake our sleeves, expecting an army of Agile Coaches to fall out, run around, and fix the problem.
  • We do not expect to install a defined process and walk away satisfied that everything will work itself out.
  • We are ready to work with an adviser to help us gradually adopt the practices, principles, and values that will help us address the issues that matter deeply to us. We would like to change how we deliver features, plan work, and interact with each other.

If this sounds like you, then we are probably a good fit to work together. I have an idea where to start and I’m ready to work with you to figure out the details. Success is not guaranteed, but it wiill be us against The System. Whatever happens, we’re in it together, we’ll learn interesting things, and you’ll be better prepared for future challenges. (Did that sound enterprise-y enough to get approval from your purchasing department?)

And we’ll approach the work with a Lightweight spirit.

  • Small up-front commitment.
  • An agenda built by ongoing collaboration.
  • Responding to change, while the plan evolves.
  • The only rule is that if it’s not working, then we try something else.

Intrigued? Great! Think about what you’d like to achieve with our first working session together. Start small. Who needs to be involved now? Which questions would you like to have answered? What would you like to have happen? What can we get done in 2 hours or 1/2 a day?

Give yourself time to consider these questions. There is no rush. I’m here when you’re ready. When you’d like to schedule your first working session, even if you’re not entirely sure what that would look like, contact me and let’s figure out the details. Or schedule your session and let’s just get started.

One Last Thing

To some of you, this all sounds like “Agile As If We Meant It”. Yes, it does to me, too. And I’m tired of having that discussion. Let’s move on and help to improve each other’s lives. I know it’s “really” Agile and you know it’s “really” Agile. That’s good enough for me.

  1. You can think of “becomes abstracted” as merely “hides some of its details”. This is how I teach abstraction to programmers, but the idea applies more widely. Not all abstraction is helpful, nor even intentional. Humans often abstract ideas as a survival mechanism, even when our survival is not a stake. That’s where the Law of Raspberry Jam comes from.↩︎