Agile Mind-sets: The Power of an Analogy

Guest post by Fred Pernet and Roly Stimson of Emergn

Never underestimate the power of an analogy. Scientists increasingly think it is central to pretty much all thought, but particularly innovative thinking, where we are moving into new conceptual landscapes and need familiar points of reference to find our way (oops – out popped an analogy, right on queue!).

That is how we ended up with gravity being thought of as a form of “attraction,” and sub-atomic particles having attributes such as “spin” and “color”(even though they definitely don’t really have color and probably don’t really have spin).

Analogy is also very useful in helping to change our mind-sets, and keeping them changed, when it navigating through relatively new conceptual territory, such as lean and agile development.

So here is one of my favorite extended metaphors for comparing agile mind-sets and behavior with more traditional development approaches.

Imagine you are super-rich. (If you are not, I’m sure you have practiced imagining that you are!). Your absolute favorite go-to car is your Bentley Continental GT. You know it, and you love it (for obvious reasons).

To relieve the unending sameness of your fabulously leisurely lifestyle, you decide to go on a road trip. To Tibet!

So, do you take your beloved and trusted Bentley Continental, or do you take your slightly less-cherished Toyota Hilux instead (for non petrol-heads: a 4×4, very robust, but somewhat utilitarian)?

It’s a question I like to pose to my agile training classes. Opinion usually splits down the middle, so we start to weigh up the likely outcomes as we embark upon our imaginary journey.

Down to Dover, the Bentley brigade are feeling happiest with their choice. The case is similar as we cruise through Europe.

But pretty soon we hit some strategic decisions. Do we go around the Black Sea or through Turkey? We might have to leave the decision late, depending on the current political stability of various countries. The GT might still be doing OK, but the road conditions are getting significantly more variable.

Anyone who has undertaken long treks like this will know all about Murphy’s Law – “If something can go wrong, it will.” It’s no mystery really; on a long trip like this, through territory we have not charted before, it is a simple fact –  the chances are certain that something will go wrong somewhere along the lines. Burst tires, potholes, a broken axle, …. the possibilities are endless. Can we get our Bentley serviced in Turkmenistan? And what are the chances of it being carjacked and us being kidnapped along with it?

And as we approach our destination, what do we find? Much steepness. Ice. Snow. And how’s our Bentley doing now? It’s clearly out of the race.

The 4×4 is victorious because of its versatility – it enables us to respond to whatever may be thrown at us. And so, safe in the knowledge that “stuff” will happen, it is the right strategic option for a journey into the relative unknown.

So how does this compare with product development in general, and software development in particular? Have you ever developed this software application to solve this problem with these technologies before? No. If you had, you’d be acquiring or reusing the solution, not developing a new one.

So what kind of team do you want be to as you undertake such a journey? One that is adaptable and can respond to the highly predicable likelihood that somewhere along the line, “events” will cause us to have to rethink our approach? Or one that is super-reliable if told exactly what to do and how to do it at all times, but completely at a loss when reality starts to diverge from our carefully laid plans?

Of course, if our destination is our favorite countryside hotel in the Cotswolds, it is probably a different matter. A well-known route. Smooth tarmac all the way. A 4×4 will be neither preferable nor faster on such a journey (and so the simplistic “agile always means faster” gets myth-busted).

And finally, just to suggest briefly some possible extensions of the analogy: what about planning our journey? Not much is needed for our trip to the Cotswolds. Jump into the car, set the nav, and away!

The Tibet trip obviously needs more planning (another common agile myth busted – agile definitely doesn’t mean not planning ahead!). But, if we plan the whole trip in meticulous detail, the chances of that plan being executed is close to zero. Instead, we might plan as far as Vienna, and beyond that have a rough idea of our route options, but plan to re-plan from there based on current information, and probably only plan the next leg of the journey in any detail.

The moral of the story? As a development team, think “4×4” – adaptable, robust in the face of adversity, ready for anything, and always planning to re-plan.

Tibet had better be worth it!