You Have My Permission to Not “Be Agile”

I have a Twitter search for the term “agile” in my RSS reader. As you can imagine, I see hundreds of tweets each day – some on topic, some not so much. Some of what I see really ticks me off. And that it what this post is all about.

Why is it that we seek a silver bullet to magically solve all of our problems?

Why is it that we look to find that one system that we hope beyond all hope will cure the woes that have built up over time in our companies?

Much of the disfunction in existence in companies today – lack of trust, communication, and a clear vision – didn’t happen overnight, yet we expect things to turn around on a dime? But it must exist! That one system that will bring the eureka moment. From watching my Twitter stream there are people out there selling THE cure. And they’ll be damned if you tell them their cure isn’t for everyone. And you know what? People are buying, because they believe it will help them. And it might, but for many it won’t. And I’ll tell you why.

Here’s the kicker, the wrench in the works – any system implemented without taking the context in which it will be implemented into account is doomed to failure.

But that’s what people are doing. And they encounter failure? I’m not surprised, only saddened.

Let’s look at Scrum for a second. I see Scrum as a framework, which is how the Scrum Alliance defines it (a number of pages into the site though – why is that?). Framework is defined on Wikipedia as,

… a basic conceptual structure used to solve or address complex issues, usually a set of tools, materials or components. Especially in a software context the word is used as a name for different kind of toolsets, component bases, then became a kind of buzzword or fashionable keyword.

Please draw your attention to the first part of the definition – a basic conceptual structure. And by definition, a structure,

… defines what a system is made of. It is a configuration of items. It is a collection of inter-related components or services. The structure may be a hierarchy (a cascade of one-to-many relationships) or a network featuring many-to-many relationships.

Nowhere in those definitions does it say that a framework or a structure is inflexible or perfect, and must be taken 100% as-is.

But that’s what’s happening. And though I’m incredulous, I’m not surprised. It all goes back to us wanting the silver bullet – we want to be told exactly what to do.

We want this because it takes the responsibility off of us and put it somewhere else. In this case, Agile methods like Scrum.

But I’m not here to relieve you of responsibly implementing change in your company. I’m not here to relieve you of your responsibility to break down the barriers of communication so that business and IT are aligned so that business objectives can be met. I’m not here to tell you that I have the one true way that will make everything better and can help you implement it.

I’m here to help you understand that there are a number of tools at your disposal that can help get things back on track, and that those tools will bring change. And that change doesn’t have to be scary, threatening, or dramatic. It can happen over time. And it will take your context into account, rather than being a blind devotion to what someone wrote in a book or posted on a blog.

Agile methods such as Scrum, XP, and Kanban are flexible systems that can be tailored to help solve business problems.

But if not being blindly devoted to the one true way means that you aren’t “being Agile,” then you have my permission to not be.

Other Posts That Might Interest You

1. 3 Reasons Your Manager Fears Agile, And Doesn’t Need To
2. Top 5 business benefits of agile development
3. Leave the Agile Manifesto Alone [Rant]