The destination not the route: A sideways look at “agile”

Malcolm and I were having a chat over coffee recently, and, spurred by his recent posts and those of Tom and Tim, we meandered into discussing Agile. We didn’t discuss methodologies or tools or techniques or processes (OK, OK, I heard the catcalls and sighs of relief), what we focused on was Agile as a mindset.

And thinking about what we’d discussed and what he’d said, I began to realise that much of what is written about Agile is “preaching to the converted” material, with its usual share of fans and flamers. So I thought I’d take a different tack and see what happens, see whether it helps the unconverted.
When you don’t know where you are, a map’s no use at all.

When you don’t know where you’re going, any road will do.

Agile is first and foremost a way of thinking, a mindset. It is more about destinations and journeys than about routes. Of course routes are important, but the destination is what’s really important.

Imagine you want to go somewhere. You have an idea of where you want to go, and you have a number of options as to how you can get there.

One way is by rail. You get on a train and it takes you from where you are to where you’ve decided you want to go. This is fine. You already have all the information you needed about your destination, you have a time and a price, with a little bit of luck and a following wind you even have a seat on the train. And for the sake of argument let us accept that the train’s not cancelled or delayed. You get to where you want to get to.

That’s fine. There was no need to adjust your route, so it didn’t matter that you couldn’t. There were no back-street doubles to take, no roadworks to manoeuvre around, no cyclists or little children to look out for. So you could afford to have a low-manoeuvrability vehicle and travel on fixed rails from point to point.

You didn’t need Agile. And so it is with software development, there are times when you don’t need Agile. Where the start and the destination are clearly known, where you have no need to discover information about route options or journey conditions, where you are consuming a commodity service on a standardised basis.

Now imagine you’re taking a car from the City of London to Heathrow Airport. You know where you want to get to, but you have a number of different ways of getting there. You’re comfortable with the route you plan to take, but you know that you may have to adjust your route as you discover and acquire more information about traffic and weather conditions. But you’re in the driving seat, you have the dashboard in front of you, and all is well.

This is also fine. You are Agile. You know precisely where you’re going, you’re in control of the vehicle, and you have the limited flexibility you need to deal with traffic conditions and other road users and the weather.
Take the metaphor a little further. You’re in a licensed London taxicab, you know roughly where you want to go, but you can’t be sure until you get close. The driver has done the Knowledge. He represents a brand, a set of values, some certified skills. You have a trust relationship with the driver. So what do you do? You tell him where you want to go, as accurately as you can, and let him know that you will only be able to improve on that when you get closer. You leave him to work out how to get to that point. And he does. Now it’s his problem to check on traffic and road and weather conditions.

The most important thing to bear in mind from this part of the example is that you’re on the journey together. With a destination in mind, a destination you will be able to describe more accurately only when you get near it. And, because you trust him, you leave him to work out the route. And adjust that route in response to what he discovers.

Most probably he’s given you an indicative time and price for the journey. You may even have placed conditions or constraints on those aspects. Which means that, as and when he hits a problem, he consults with you. We can go this way, it’s more expensive but you will be on time. Or we can go this way, it’s the same price, but you could be late. And you make the call. Together.

In this example you have a rough idea of the destination and time and cost, but you iterate through options as you get better information, optimising as you go along.

Now you are Agile. It’s a bit difficult to do this with a train.

Let’s take the example one step further. You’re on a desert safari, a race, you and your co-driver. You’re all mapped up. You know where you want to get to, but all you can see is sand. Dunes and dunes and dunes. You have some idea of the direction you want to go in, you have some idea of how you will recognise it when you get to where you want to be, but the options you have are far more extensive. So you select a route, and keep adjusting it as you go along. Sometimes you track back to a specific landmark and carry on from there. You keep adjusting the route using your compass and your map and whatever landmarks you can find. You’re a little loose on the cost and time implications, but you know the basics within a reasonable level of tolerance. And you get there. And yes, maybe you got a little lost on the way, but you worked that out, retraced your steps and got there.
Now you’re really Agile. No trains, no lines, no roads, no traffic lights, no traffic. Just sand. Undulating as only sand can.
Jim Highsmith, one of the doyens of Agile, would refer to the declaration of destination as Envisioning; the selection of initial route as Speculation; the adjustments to the route in response to external stimuli and better information as Exploration, the finalisation of the route as Adaptation and reaching your destination as Closing.

[Incidentally, if you’re not one of the converted, but you’d like to know more, it’s worth reading the Agile Software Development Series edited by Alistair Cockburn and Jim Highsmith. Their web sites also give you some good pointers and information about other places to go to, other things to read.]

The journey and destination metaphor used above can be extended as needed. The type of car used, related to the terrain you will drive over, may represent facets of the team. The capacity of the car and its range has meaning as well, as also its manoeuvrability and size. The nature of the instrumentation required is also something to consider.

I shall spare you any further stretches of metaphor. What matters is this:

• Agile is about a journey and a destination
• It is meaningful when you have incomplete or inadequate information
• You’re together with someone else for the journey, in a trusted relationship
• You need the right instruments to capture the information as it is discovered or as it changes
• You work your way through options, altering route as you learn more and as you need to
• You have the flexibility and the manoeuvrability to optimise on time, distance and cost as you go along, within a previously accepted envelope
• You get to the destination more reliably as a result, in comparison with less flexible and optionless routes.

Agile is about a mindset; it works best when you have a broad idea of where you want to go, where you need a process that collects and improves your information base, and where you need the freedom and optionality to respond to changes in that information base.

The methodology and tools and techniques and processes are secondary. It’s all in the mind.