Updated:

This is Part 2 of my mini-series on Simple Agile for Enterprises. Feel free to start with Part 1.

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.

Need for Speed

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?

The Steering Wheel

“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 methods are the car’s steering wheel, not the 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).

An agile car

An agile car

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.

The Gas Pedal

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.

Steering Can Make You Faster

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.

Steering from the Top

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:

  • They happen once a month at best, so any feedback loop that it could generate is going to be quite slow. It’s going to look like a drunk driver swerving from one side of the project road to the other.

  • It routinely turns into a confirmation exercise - “hey, look, everything’s fine” - because projects aren’t really setup to change course (this is where the famous watermelon report is widely used).

  • The steering committee is often itself not motivated to maximize value delivered but simply wants to minimize deviation from prior plans or ensure corporate guidelines are adhered to.

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

The steering wheel is generally placed inside the car, not outside.

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

The Governance Wheel

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.

Steering before you move Steering before you move

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.

Wishing for What you Value

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.


Next Up: Part 3: Conversation Stopper: IT Should Become Agile


Learn More About IT Transformation

37 Things

Find more real-life stories about the intersection between architecture and IT transformation in my book The Software Architect Elevator. Buy it on Amazon US, Amazon UK, Amazon Europe