Author: JP

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.

This post was sparked by something I read in Larry Lessig’s blog a week or so ago, on the economies of culture. In it, Larry discusses the challenges and issues involved in linking the “commercial” economy with the “sharing” economy, or what he terms the “second” economy. It’s worth a read; if you get the time, take a look at the comment stream as well.

Enterprise IT departments face this challenge of connecting two polarised extremes on a regular basis, whatever the terms du jour; be it open versus closed, proprietary versus opensource, hierarchical versus networked or even waterfall versus agile. Some months ago, Kathy Sierra had a great post on the difference between start-up and corporate mindsets, covering much the same thing, but from a different perspective.
When you speak to the extremists, the standard response is You Are Wrong I am Right, which gets us precisely nowhere. Which is why people resonated with what Tara had to say in Missing The Point a few months ago, where she spoke of the need to get the pendulum swinging right.

Debate can be polarised, but reality sticks firmly in the middle. And we need to learn how to live with that reality and create value from it.

I still think that it will all boil down to the Because Effect. Commercial economies are all about making money With. Gift or shared economies are all about making money Because Of. And the philosophical differences between the two will probably not converge. They are two different states in time. Enterprises will often have bits in both states. FLOSS is primarily about infrastructure, even if what we call infrastructure is crawling up the stack. FLOSS infrastructures will continue to live with proprietary applications further up the stack.
As exemplified in the Because Effect and Stewart Brand’s earlier writing, the real polarisation seems to be about something else. Scarcity versus abundance. People know how to make money out of scarcity, but are less comfortable with doing so with abundance. The problems we face with bad IPR and bad DRM and “unfair” vendor behaviours all seem to be connected with creating scarcity out of abundance.

Regular readers will know that (a) I liken bad DRM to bad EAI, paying to mine information that should not need to be mined and (b) I like apocryphal tales.

Many years ago, we had a bout of prohibition in India. These things happen. Sometime after the 1977 elections.

Some states went dry, some didn’t. And in my apocryphal story, one of the biggest states, Maharashtra, was one of the Dries. You could still consume alcohol there, but only in “permit rooms” and only if you had a “permit”. You could get a permit if you were (a) a foreign tourist spending hard currency or (b) certified as having a medical condition that needed regular intake of alcohol (!). And as the story goes, the permit-issuing agency in Maharashtra, the “richest” state, grew amazingly. Naturally. Many many medical conditions. Then, some time later, Maharashtra wanted to rescind prohibition. Problem. They couldn’t possibly shut down the permit agency, it employed too many people. What would the people do? So. It was decided. Wisdom of Solomon. No need to shut down the agency. Everyone could drink. But everyone needed permits. And the agency grew. And God was in His Heaven. And All was Well with the World.
Unintended consequence or apocryphal nonsense? You decide.

So it was with some amusement I read this story in GigaOM:  Someone has reverse-engineered FairPlay and used the learning to replicate an equivalent, and is now licensing the equivalent to third parties who have felt locked out of the lock-in.

I guess you could call it an unintended consequence. Continuing along this vein, albeit light-heartedly, I can imagine a time when regulators insist that DRM “facilities” (sic, I couldn’t find a better word) are kept distinct and separate from the OS, in order not to restrict consumer choice. Choose your OS. Choose your media player. Choose your DRMboat.
In Islington there was a man. The dog it was that died. Thanks to Oliver Goldsmith.

I was talking to my son Isaac this afternoon, the subject of gaming came up, and somewhere in the conversation he mentioned that the Sony PS3 was going to be free from region coding, and how good that was.
And I thought to myself, how odd. I grew up with 33 rpm albums and 45 rpm singles, and I could buy them anywhere and play them anywhere. We even had 78 rpm “lacquer” platters, and these played everywhere as well. So I can listen to William Booth talk to his troops on my 1905 mechanical gramophone, T.S. Eliot read his poems on a 33 rpm 12″ “LP” and the latest “vinyl” single from the Arctic Monkeys, all without worrying about region coding.

Why stop with records? I had no problem with reel-to-reel tapes and cassette tapes and even CDs. The first time I hit the oddness of region coding was with my son’s console games, on an early Nintendo I think, and soon after that we had the DVD debacle that continues.

DVD region encoding offers less than zero value to the consumer; allows for unnecessary price and time discrimination between markets; promotes piracy and illegal copying as a result of those discriminations; provides no incremental value to the artist(s).

DVD encoding was brought into existence pretty much by stealth, most of us found out about it after the event. Which was probably a good thing, since it woke me up to the dangers of bad DRM and bad IPR just at the right time.

Because of the stealth approach, many people have no idea what the regions are. I thought it would amuse you to see the actual regions. Looks like a political map of something in Second Life….

It is with some sadness that I note the death of Byron Nelson earlier this week. Everything I heard and saw and read about him spoke of his immense gentleness and humility.

Born on a farm. Worked as a caddy while still a teenager. Worked as an accounts clerk. Thrown out of work during the Great Depression, found himself working temporarily for a banker’s magazine some time later. Turned pro because he couldn’t find work. Rewrote the record books. Retired to all intents and purposes at the age of 34, to run his ranch. Which he did for sixty years.

Here are some of the things he said:

I don’t know very much. I know a little bit about golf. I know how to make a stew. And I know how to be a decent man.

When I was playing regularly, I had a goal. I could see the prize money going into the ranch, buying a tractor, or a cow. It gave me an incentive.

Shades of Peter Drucker and Making Shoes Not Money.

Byron Nelson was hewn from stones we rarely see today. He will be missed. My condolences to his family.