The Magic of Agile

One problem with "Agile" is that it often gets used as an excuse to avoid addressing the real problems in a straightforward matter. People resort to "magical thinking" - hoping that "Agile" somehow does some magic that will make the problem go away. And here's what's happening:

Clarity

In anything we do, we tend to look for predictability: what are we supposed to do, and what will happen as a consequence of what we do?

The coin toss

Let's start with something really simple: tossing a coin. 

You toss it into the air, let it spin, and call "heads" or "tails", and 50% of the time, you're right, 50% you're wrong. Straightforward enough.

Would you believe me if I told you that "if you throw the coin properly, it will turn into a helicopter and fly away?" Probably not. You won't believe me, because you know exactly what a coin and what a helicopter is, and how to toss a coin. There are no Unknowns here, and as such, you wouldn't accept my claim.

But now, let me change the topic:

The Project

Your company has started a project: to toss coins and turn them into helicopters. "Insane", you say. "No," your consultant responds: "we are in the Complex domain - a problem that we don't understand requires an approach you are not yet aware of. Since you can't rely on a familiar approach, you need to use an Agile approach."

Whereas formerly, we would have said "This won't work", now we have "Agile", and the plausibility of success immediately increases!

We have done nothing, absolutely nothing, that would lead to a helicopter as a result, and likewise have done absolutely nothing that would actually help you create a helicopter. All we did was introduce "magic" into the process by reframing the Unknown: "we have no idea how that's supposed to work!" becomes: "Agile will create the result!"

Comfort

Since we know very well that we're not getting a helicopter with a coin toss, we are quite comfortable to state, "That doesn't work." Now, if someone showed us how a coin turns into a helicopter mid-air, we would say, "I see the helicopter, but don't know how that works," (we increased the certainty of the outcome, but not in the approach) - and those of us with a growth mindset would likely say, "I want to learn how to do that!"

If your manager has given you 2 weeks to do it, your nerves would tingle. 

And now your manager tells you that unless you do it, you will be fired? Most likely, you'd be quite willing to try any advice on turning coins into helicopters.

What has happened here?

The further you leave your comfort zone, your willingness to accept magic as part of your mental model increases. When facing an existential threat, you'll more than happily try things you'd call nonsense under normal conditions: the plausibility of the proposal hasn't increased at all, only your perception thereof!

And this quite frequently happens with "Agile Transformations":

Magical Agility

Of course, turning "coins into helicopters" is a joke. Nobody would take that seriously. But what if our challenge was to turn:

• Dissatisfied Customers into Happy Customers
• Poor Time-To-Market into Fast Delivery
• Cost Pressure into Huge Savings
• Tons of Defects into High Quality
• Unhappy Developers into a Highly Motivated Workforce

Someone says, "when you're Agile, you can achieve all these". and now you're all - "Okay, bring on the Pigs in Pokes, let's get this going!" - especially when your job is at stake!

And that's where you get into the realm of Agile Magic. And that's when you need to stop and think.

Let's not get into the nitty-gritty that even if you're agile, you'll still have these problems, just that you will be able to deal with them better, and let's focus on the big hitter:

When your organization has no experience with achieving these, then "Agile" isn't going to change a thing about that unless you start doing your homework!

De-mystifying "Agile"

There is no unknown component that can't be explained. Everything is transparent. We know very well how to relate cause and effect. And where we don't know, we can explore until we do.

Problem -> Approach -> Action -> Outcome. Preferably highly repeatable and reproducible. No silver bullets, no miracle pills.

Where we can't copy+paste a solution from one place to another, succeeding with agility becomes harder, not simpler: we require experimentation and a willingness to fail - and a pretty good understanding on whether failure will lead to growth or be fatal.

There's no Agile ceremony, ritual or incantation that will grant you a magical Great Leap Forward.
You must get to work and clean up the mess you're in. 

Learn what causes you to get the outcomes you currently get, and what you need to do in order to get the outcomes you want. As you learn, you'll catch a bloody nose quite frequently, so bring plenty band-aid. (figuratively speaking)

Mundane agility

Find your own way forward:

Experiment. Fail. Learn. Repeat.

That's all there is.

The only shortcut I can offer: You are probably not the first person who has encountered a problem. Thus, you can often skip or at least reduce the "Fail" part by learning from others before you move ahead.

There are many bodies of knowledge that allow you to accelerate your journey: Engineering Practice. Process Management. Product Management. Quality Management. Supply Chain Management. Team Building. Just to name a few. Make use of whatever knowledge you can get a hold of.

Inspect and adapt until you're clear why you are where you are, and where and how you want to go next. When you don't know, you'll need to figure it out. 

The more you practice this, the more comfortable you become doing it.

The desire to seek magical solutions evaporates.

There is no magic in "Agile.".