Agile Is the Steering Wheel, Not the Gas Pedal

• Read original article here

As my love for car metaphors is well-documented, let’s try to apply it to one of the most annoyingly misunderstood approaches to software delivery: Agile development.

The Agile movement could consider it a sign of success that its methods have been portrayed as the cure for about any ailment that IT could possibly have. Naturally, no business has ever complained that IT delivers too fast, so folks are always looking for ways to speed up software delivery. It’s not a giant leap to hearing the battle cries: “We need to deliver faster! Let’s go agile!”

I routinely remind folks that the method isn’t called “fast development” for a reason. This might give a slight hint that speed isn’t the main purpose of being agile. Alas, as Russ Ackoff once commented, managers are people subjected to more panaceas than they have problems, so when something looks plausible enough to reduce cost or shorten time lines, most managers are quick to grab it. Can’t hurt, can it?

“Agile” got it’s name from the ability to be flexible, meaning being able to adjust the project along the way as opposed to defining everything upfront. The core of being agile is being able to change direction.

The simplest way of explaining agile to a broad audience that I have found is by clarifying that “agile” is the car’s steering wheel, not its gas pedal.

Agile lets you change direction, not just go faster. Taking the metaphor further, and to fully appreciate the steering wheel, delivering business software is more like an auto rally (or an obstacle course) than a straight-line drag race: competitors launch new products, new markets open up, or simply new ideas pop up. That’s why the steering is actually very important. You want a rally car! (I’ll never give my Integrale away - most funnest car ever).

If you’re looking for a more punchy metaphor, the Titanic ocean liner had plenty of horse power (some 45,000) but its rudder, while impressive in its own right, wasn’t big enough for fast turns. The Titanic was fast, not agile. For going straight from Southampton to New York, that’s fine. However, for dodging icebergs it’s not. Very few businesses these days are going in a straight line, and those that do might want to check for icebergs.

Without a gas pedal the car can’t move, so we’d want one as well. However, the gas pedal metaphor translates into very different different mechanisms of software delivery. For example, a fully automated software delivery pipeline reduces friction and speeds up software delivery. That’s equivalent to pushing down the gas pedal.

Always looking to stretch our metaphor a little further, a good steering system can also make you move faster, in addition to having a good engine and gas pedal. Although the steering wheel’s main purpose is to give you agility by letting you change direction, on a curvy road a nimble and precise steering system is essential to taking turns the right way. So, while the “let’s become agile to deliver faster” slogan originates from a rather blunt misunderstanding of what Agile is, in a business environment that’s defined by twists and turns, it actually does increase your velocity. But as so often, you need to understand the mechanisms at work, not buy snake oil.

When large organizations hear about “steering”, they first thing coming to their mind is often the dreaded “steering committee”. Although the original idea of a steering committee is indeed to provide priorities and direction, several factors contribute to them rarely being effective:

So, when I think of steering committees, I come back to my car metaphor and observe:

You’d want the driver to steer, not some external committee who isn’t there when things are headed for the wall.

Lastly, when organizations are looking to steer their projects, the other word they think of is “governance”. Such governance assures that the standard software stack is used and existing processes are adhered to. Overeager and aware of the limitations of steering committees, governance folks often attempt to bestow these constraints onto a project before it has even started.

Naturally, steering doesn’t make a whole lot of sense until you are actually moving as I commented in a LinkedIn post a good while ago.

When talking about governance, I can stretch my car metaphor one more time and remark that a governor (the device, not the person) is generally used to limit speed (see Wikipedia). So, enterprises should think twice about governance.

I have been wondering why the fairly simple approach of agile methods keeps getting misunderstood so much in enterprises. I came to the conclusion that it isn’t a simple misunderstanding - it’s the result of misaligned values. Traditional IT is measured by delivering projects faster and at lower cost. A straight line appears to be the most efficient way to get there, so anything that zig-zags must be less efficient in their minds.

However, “Agile” has become so prominent that IT management can’t totally ignore it, so they make ends meet by mapping Agile to those properties that they value, regardless of the built-in mechanisms. They haven’t realized that going zig-zag can be the more efficient approach when your road has a lot of twists and turns.