Navigating in the Mountains, Using the Right Technique for the Conditions – Testing an Agile Analogy

One of the joys and challenges of being human is that we communicate and understand differently. Some people prefer numbers and facts, others need a picture or a story. Art exists in many forms because it helps us to break through and communicate.

I’ve been trying out a new analogy recently and wanted to expose it to a broader community to see if it resonated. I’d love to hear your views.

One of the joys of my life is a day walking in the hills. There are various skills that that you need when you are out in the hills, perhaps the most important being navigation. I call navigation a skill because it isn’t a method, it’s a collection of tools and techniques that you need to apply in the right situation to get the right result. The tools and techniques that you use on one particular day, or even during a specific hour, are influenced by several factors, including:

Visibility – How far can you see?

Local knowledge – Do you know where you are going? Perhaps you’ve been there before?

Terrain – Is there a defined path? What are the hazards ahead, or to the left or right?

If visibility is good; if there’s a defined path and you are walking a route you’ve walked many times before you join the chosen path, look ahead and walk. Navigation is straightforward and doesn’t require you to spend all of your time looking down at a map. When things are really good you can even see places where the journey could be improved by taking a slightly different route or by taking a shortcut.

This approach is fine until the factors above change. Clouds roll in causing visibility to drop to a few metres and you arrive at a point where the defined path becomes less distinct and the terrain becomes indistinct. At this point the navigation techniques need to change, it’s time to get the map and the compass out.

For anyone who hasn’t used a map and compass in this situation what you need to do is to take a bearing. This video shows you how to do that:

Unless you are a very skilled navigator and there are lots of visible landmarks it’s not likely that this approach will get you directly from A-to-B, but it will get you there. Even if you could navigate on the direct route it’s likely that there will be obstacles in the way that will cause you to stop and adjust. Navigating this way is slower than when conditions are good, taking a bearing takes time and diversions cause extra work.

The key skill in this approach is to take bearings often enough to keep you focused on the end goal, but not so often that you are spending all of your time taking bearings. The length between bearings depends upon the amount of visibility and the available landmarks. If you can only see for 5 metres, then that’s as far as you can navigate. The last thing you want to do is to pick a landmark that is itself out of sight, that’s a recipe for disaster because you are likely to miss the landmark in the mist and plunge yourself into a situation where you don’t know where you are on the map. Relocating yourself on a map is another skill, slowing progress further.

Some days you start out on a walk where visibility is good and you have great local knowledge but that situation can change rapidly. That’s when the approach needs to change to match the conditions.

Projects, particularly IT projects, are journeys from one place to another. The methods that we use should be dependent upon the conditions, that’s where this analogy comes in. Agile is fabulous for those situations where it’s a bit foggy and the path isn’t clear. Take a bearing, pick a landmark and then sprint to it, then take another bearing. Lean isn’t great in the fog, but is the fastest way of making progress when conditions are good. Even in a Lean situation you may still want to define some interim goals to maintain motivation but you’re not changing the path or the destination just because you’ve reached an interim goal. Even if you think that the road ahead is clear and you can follow tried and tested routes doesn’t prevent the conditions changing and a different type of navigation being required.

Like all analogy this isn’t a perfect picture of the different approaches, but it’s helped most of the people I’ve described it to. Does it work for you?