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.
Nice post JP. And congrats on the new job, by the way.
One thing bothers me and that is that huge numbers of people, evangelists if you like, have enthusiasms for things like ‘social computing.’ Their enthusiasm isn’t for particular products, more for improving the communication experience, but they have no clear destination in mind. Not one that makes any sense to the sponsors they’re seeking anyway (e.g. the board).
Having been there, done that, do you have any good advice for them?
Thanks.
Hi JP, since you introduced the desert safari metaphor… A few nights ago I watched a documentary – on Nat Geo I think – about an Italian marathon runner who was participating in the great desert marathon of Morocco. He got lost in a sandstorm. And survived in lost solitude for some 9 days, without water or food, before he was found. That was really quite amazing and inspiring.
This story is at: http://en.wikipedia.org/wiki/Mauro_Prosperi
Much food for reflection on his survival strategy. In fact, when he realised he was definitely doomed, after the last of his food and water got over, he cut his wrists and lay down to die. But because of his dehydrated condition, his blood did not flow out and so he woke up the next morning! Then he decided he must survive anyhow!
Cheers, chutki
Hi JP,
When the target moves, the team which is trying to hit that target (a) must know as quickly as possible that the target has moved and where it’s moved to, and (b) must be able to change course as quickly as possible.
When I think of agility in the context of IT systems delivery, I always come back to the same two basic principles. Teamwork, and automated testing.
Particular tools, processes, techniques, methodologies, whatever, these are secondary and their use naturally flows from those two principles.
So …
In order to minimize the time between when ONE person on the team first knows that the target has moved, and the time that the ENTIRE team knows that the target has moved, the lines of communication across the team must be open. There must *actually* be a team (gasp).
And by team, I do not mean just the development team, or just the overall delivery team on the IT side, and I don’t just mean the “business sponsor” with the delivery team – I mean everyone who has a stake in the delivery – REAL customers, business teams, operations, IT, everyone. There must be trust. There must be rapid and frequent communication. There must be an ability for the team to decide what to do next.
Here’s a truism for you: Good teams do good things. Therefore, the first step towards agility is to form and gel the extended team. Even if you do nothing else, some good things will start to happen.
So – you know you need to change course. Now you need to minimize the delay between when you know you need to change course, and when you actually change course.
You can’t change direction safely unless you have the ability to “immediately” verify that everything is still working. This requires as much automation of testing as possible. Unit testing; functional testing; interface testing; isolation testing; performance testing; load testing; resilience testing; catastrophe testing; end-to-end testing; deployment testing; upgrade testing; rollback testing. Etc. The more you automate and the more you cover, the more sure you can be that when the taxi swerves left onto Piccadilly, the driver and passengers aren’t going to be hurled out the doors.
Build an effective extended team. Automate as much testing as you can. That’s it, really. I’m a simple chap.
If in your desert safari, or taxi journey, or whatever, you encounter a major obstacle you might want to change your strategy temporarily. A river you need to cross say. You can’t incrementally cross the river, you need a plan to get all the way across.
I believe this is also true of software projects. Your day-to-day deliveries might be agile, but the roll out of the system to a new location might be planned and executed as a single waterfall project.
Horses for courses, to add yet another metaphor. Even within one team and one project.
David, interesting question in the context of social software. I think it is worthwhile to envision destinations and thereby derive an answer that keeps the ROIters happy.
Gary, couldn’t agree more. Comprehensive automation of the testing process, coupled with starting it as early in the cycle as possible, is a must. The goal should be for us to be change-agnostic, not because we prevent change, but because we can adapt to any and all change. Which we cannot do unless we promote the testing process.
I am also of the opinion that we can seek to refactor testing itself, something that’s worth discussing offline or in a separate post and comment thread.
Hi Dom, welcome to the conversation. Coffee sometime?
What Dominic says echoes Alastair Cockburn’s ideas around a “methodology per project” – even a doyen of Agile appreciates the “horses for courses” argument that different projects may benefit from the choice of a different methodology.
It was more of a methodology per deliverable. JP once pointed out to me a document called “From Worst To Best in 9 Months” by David Anderson and Dragos Dumitriu of Microsoft (link).
Their practice, based on Drum-Buffer-Rope [Goldratt 1984], wasn’t canonically agile but certainly shared some characteristics. It describes a team whose job was to deliver rapid changes for a number of customers. However, stories that turned out to be too large to include in the normal development cycle were re-routed to a waterfall-based project planning and approval system.
You can change horse mid-stream if it’s the wrong horse.
methodology suggests some modicum of standardised repeatable process.
one “anything” per project or deliverable or situation does not suggest standardised repeatable process.
which is why i went back to mindset and principles.
when you then take Gary Casey’s point about the importance and role of testing, you start moving to a situation where you are change-agnostic because you have tested against all possible situations. Obviously a constrained set, so “all possible” rather than “all”.
Drum-Buffer-Rope was closer to “mindset and principles” than methodology-tool-technique. Or so I thought.
You have a long memory, Dom, must have been 2004 when I posted about that.
see you, sean and malc tonight at the film, hopefully? all the info is on the wiki
http://www.thehughpage.com/Hallam_Foe_Bloggers%27_Film_Premier._Thursday%2C_October_5th%2C_2006
look forward!
I’ll be there, Hugh. Be good to catch up.
To me the essence is shortening and firming of feedback loops and learning from it.
Automated testing means you get solid feedback about the state of the system very fast.
Frequent deliveries mean that the real world customers can tell you if you built the right thing.
Reflection on the process in daily, iteration and release frames means that the process itself is constantly refined and optimised.
And now you have my e-mail :-)