September 6, 2006
Agile TouringIt's a rainy morning up here in the Lake District, and I'm confined to base for a while - hoping that the weather will be kinder this afternoon. This gives me a few moments to reflect on the guided tour I went on yesterday, and - more importantly - what it can teach me about planning.
If you attended my workshop on Agile Governance, you'll see where I'm going with this:
A guided tour is, on face value, a very simple thing. A dozen or so tourists get on a minibus and the driver of said minibus takes them around the region, stopping at notable locations so that the tourists can get out of the bus and take pictures of each other obscurring the aforementioned location. ("And this is a picture of me blocking out Wordsworth's gravestone", and so on.) There are about a dozen locations, each taking a certain amount of time to get to from the last. And at each location a certain amount of time is needed to take it all in: usually just enough time to stand in front of it and wave at a camera.
There are considerably less variables in a guided tour than there are in, say, a software project. So they should be easy to plan in advance, yes? No need for agility here, surely?
Luckily there is actually enough complexity in a guided tour to warrant - ney, to insist on - the use of adaptive planning techniques like the ones we explored in the workshop. Add the weather to our predictable little picture, and all of a sudden things start to look a little less predictable. Throw in the traffic, and things become even harder to predict. And as for the people - well, 10 minutes at location X might be fine for a dozen grown-ups, but you might need to allow more time if there are young children in the group. Hard to imagine as it may be, you're closer to the edge of chaos on a guided tour than you think.
So we have have our dice for our Agile Governance game. And we have our game grid: the Lake District. We could go anywhere in the region, but some locations are harder to get to from certain locations than others, and are therefore riskier options. At the same time, some locations are much more beautiful or interesting than others. This represents the value in each square in our game grid.
In our Agile Tour, we assign relative value to each location based on how much we want to see it, and we assign relative difficulty based on how difficult the location is to get to from the previous location we plan to stop at. This might be measured as distance, but could also factor in traffic, weather/road conditions and other elements that might make the location harder to get to. We earn value by getting a good photograph at each location. We won't know for sure how well we've done, then, until we get home and can examine our photos in enough detail to see how they really came out.
I've blogged before about photography, and how it's a game of odds - just like touring and software development. If you're a fairly weak photographer like me, then the trick is to take as many pictures as you can to increase the odds of catching a good one. On a day trip like yesterday's, adaptive planning is even more important because you have limited battery life and limited disk space for images. You have to keep a close eye on how much of these resources you're using up throughout the day, and then temper your worst David Bailey excesses at one location if you think a better location is coming up.
So when we do our Agile Tour, we throw the dice until we arrive at our next destination. Then we throw the dice again as many times as we can afford to better ensure we get the photograph we need. And then we move on to the next destination. And, if the weather or the traffic or any other of a million variables changes, our next destination might not be the one we had originally planned. Yesterday I believe we skipped a couple of locations from the plan, and the driver threw in a couple of extra locations that he knew some of the older women in our group had been asking about.
Essentially, it's the same game. Once you've stripped away all the extraneous detail that makes one problem about guided tours and another about developing software, we see the same patterns and the same strategies being successfully applied. Except, of course, that so few people actually apply them. Tour guides tend to save the best locations for last, and on the few tours I've been on I've experienced a last-minute rush to get through the final locations - leaving less time to enjoy them, and more crucially - given the aim of the game - less time to get a good photo. I've also run out of battery power on every guided tour I've been on and ended up unable to take any pictures of the final location(s).
The critical property of sortedness can help us measure the effectiveness of our plans, whether they're for guided tours or for software projects. Sortnedness is a measure of the extent to which the highest value, least risk items are scheduled earlier in the plan. It gives a relative indication of the likelihood of value being delivered with limited time and/or resources.
The rain seems to have stopped, so here's one final note before I get back to the serious business of being on holiday (and boy, is it hard work?!):
There's one further analogy I can draw between guided tours and software development, which is refactoring. Yesterday it was quite rainy and grey, and a lot of pictures came out a bit washed out and slightly overexposed. This can be fixed, though. A bit of tinkering in Photoshop and they'll look just as good as the others. A programmer might apply an automated refactoring like "extract class", and a photographer might apply an automated refactoring like "adjust contrast". I can also crop and cut images down to frame more pleasing compositions - another kind of image refactoring. I can even apply more sophisticated refactorings like filters and image effects to touch up the pictures - removing the odd stray tourist, for example. This gives refactoring a more well-defined and more generally applicable role to play in adaptive planning, as it effectively widens the goalposts on how good an image (or code) needs to be to be capable of satisfying the requirements - after a few extra tweaks.
Posted 14 years, 4 months ago on September 6, 2006