ego.istic.org

Consider what you do when you go to Ikea. Usually, you go for one or two particular items: a new bed, maybe, or a bookcase. You wander around the shop and you also find a few more things you like: a modular storage system, a light fitting, a bedside table. You pick up a really nice kitchen knife too, one that's perfectly weighted and would save you ages when chopping veg, but when you glance at your trolley you suddenly think you don't have room for it. Satisfied that you've bought everything you could possibly want, you head to the checkout and pay. But disaster of disasters: when you get to the car, it doesn't all fit. You spend an hour trying to arrange it all and find you can just about get it in if you leave the bookcase behind (it was on special offer anyway) and you can live without the handbrake.

Sound familiar? Even if you've never heard of Ikea, this might sound like a software project you've been involved with recently. The product manager, or whoever is in charge of “specifying” the product, has some ideas for things he wants (a new bed), and the developers set off to achieve those things. But while they're doing that, he discovers other things he wants (a modular storage system) and piles those into the spec too. Perhaps the developers complain that the deadline won't allow them to get everything done; the manager makes a token sacrifice of a really useful feature that would have only taken a day to write anyway (like the kitchen knife). But after the manager has marketed the product to customers or investors (paid at the checkout), he finally discovers what the developers knew all along: the features won't fit into the timescale (car). Then all the remaining time is spent trying to rearrange the plan to get as many features in as possible, and the product's original selling point (the bookcase) gets lost as the developers weren't happy with it anyway, having rushed it. QA and the polish that turn a project into a commercial product are thrown away (like being able to reach the handbrake).

This sounds like a Z Cars approach to software development, but it does happen, and it's one of the reasons so many projects fail. So how can we mitigate the risks of failure? How can we make sure we only buy what we can fit in the car?

One way is to sit down at home (with a cup of tea or a glass of wine) with the Ikea catalogue. Find everything you want, and make a list. With the list take a note of the flat-packed measurements of each item. Also measure your car, and with those measurements work out exactly how each item is going to fit. Keep taking things off the list until everything fits. Then go to Ikea, buy those things, and put them in the car in that order.

This is broadly equivalent to traditional project management techniques, with informal but carefully worded specifications. It's a great technique, and it has the useful property that you know before you even leave the house what you have the capacity to bring back. If not all your must-have purchases fit in your car, you can go and hire a van in advance. You're not tempted to load your car unsafely because of over-committal. But the more carefully you form your plan, the more brittle it is:

• If you measured the car wrong, or the size of any of the goods is more “approximate” than the catalogue claims, your plan is worthless.
• If Ikea launches a new bookcase, not in the catalogue, you can't buy it until the next trip.
• If you meet a friend at Ikea and she offers you some of her spare boot capacity, you don't have anything to fill it with.
• If the shop is out of stock of your bookcase, you can't choose an alternative.
• If you can't decide whether to buy the kitchen knife until you've picked it up, you will waste some space.

I hope you've already spotted how each of these failing cases corresponds to something that can also occur in software development: estimates can be wrong in either direction, you come up with new feature ideas after starting, you get extra programmer time you were not expecting, an idea proves to be unworkable and you need to schedule something else, or you can't evaluate different approaches until they've been tried.

So, both of the above ways of running an Ikea trip have problems, but they can still work in some circumstances. If you drive a Transit, buying too much might seem like a remote possibility, so just picking up what you like works fine. Similarly, if you have a relaxed timetable, or you're writing a hobby project, then planning as you go along will work fine, and it's a very efficient way to get things done. At the other end, if you are good at visualizing how furniture will look in situ, and you know exactly what you want, and you can get the shop to reserve one for you, then doing all the planning up-front works fine. Similarly, some projects have completely obvious requirements, plans produced by competent engineers who understand the issues, and guaranteed feasibility; these projects can be planned up-front, and this plan makes it clear from the start if you need to hire more people and what features will be available.

I've worked on successful projects run in both these ways. But I've also worked on unsuccessful projects run in both these ways; projects whose failure was seen as an unavoidable risk inherent to the problem, but was in fact caused by applying inappropriate analysis and management techniques. (The same is true of Ikea trips.) The third way, which I'm about to describe, of running a shopping trip is neither necessary nor sufficient for success, but if you're not sure you're driving a Transit or know exactly what you want, it's a much safer bet.

Pick the list of things you really want: a new bed, a bookcase. Go to Ikea. Walk around the shop once, and pick up those things. When you see something you like, make a (mental) note of where you saw it and how big it is, but don't put it in your trolley. When you get to the checkout, pay for your goods and then put them in your car.

Now, look at the state of your car. How much space is left? Do the things you've bought look much bigger now? Taking account of how much you overestimated the size of the car or underestimated the size of the goods, think about how much you can fit in the car.

Go back into the shop. On your (mental) list, find the things you want the most, and pick a set of them that you're sure will fit in the remaining space in your car. Keep adding new things to your list to be considered next time around, but don't put them in your trolley.

Again, when you get to the checkout, buy what's in your trolley and load it into your car. You might have to rearrange (refactor) some already-packed things to get the new things in. Reassess how good your size estimates were, look at how much space is left. Keep doing these iterations until you run out of space or run out of things to buy.

This is the core of Agile planning. Each Agile methodology has different practices and recommendations, but they all aim to support the idea of protecting against uncertainty (about what you want and what is available) and ignorance (of how big each thing is) by planning a little bit at a time.

If your project doesn't have uncertainty or ignorance: if you know exactly what you want, and how big it is, and the risk of unexpected problems is small, then just buying it all and fitting it in the car perfectly first time is an efficient way of doing furniture shopping. But if you find yourself getting back to the car and having to settle for a commercially unviable set of furniture because the ones you wanted won't fit, then Agile planning can help you to reduce this problem. It's not a guarantee of success, but if your projects are already failing, it's almost certainly better than what you're doing now.