Planning & preparation versus agile

Many of the interesting agile discussions I have are with those whose job has an element of 'crystal ball' about it. No matter how crazy this might sound, this is what we try and do time and time again whilst delivering IT - we tell the customer how long it will take, we tell the customer how much it will cost. And in many cases we also attempt to document how systems will be structured in the years to come, the technologies they will use, the interactions they will have, etc. etc.

Of course, some of this is necessary - if you don't know where the ship is heading, you might as well not leave the port. So certainly we need an idea of whether a system is going to become legacy, whether it has a future, and what that future might look like. But it's important to control the amount of effort put into this kind of work, and the message which emerges.

An estimate given before work commences is just that - an estimate. It should be accurate enough to set expectations appropriately but at the end of the day, its only based upon the data we have at the time and our past experience. The same is true for any kind of strategic planning or design work - what is often overlooked is what we don't know. We don't often know the complexity which will arise out of the development of a particular component, we don't know that we'll find a tool on the web which can simplify our email template editor, we don't know that the business will cancel the project and complain that they've sunk £1.8M and received no benefit.

Lets get back to the primary goal of software development - the engineering of software which supports the business and allows it to operate efficiently. At its heart are the developers - the 'coalface' workers, and our responsibility is to minimise the work which isn't actually chipping coal from the coalface - everything else is less useful and unless tightly controlled is simply waste.

But we can't just go developing code randomly without a target in mind. And the customer is funding all of this and expecting some benefit, so they need to understand how long and how costly this will be - that's entirely understandable.

Agile can really help here - it is simply a matter of when and how to communicate. I think we would all agree that when a project kicks off, we need to get some brains in a room and discuss options. There's a lot of ground you can cover in a few hours with the right people. You can set the approximate direction, the tools you'll use, the objectives, etc. If you get the business involved we've seen huge leaps forward with gathering requirements (user stories) and success criteria, dependencies, etc.

So you have a couple of kickoff meetings. At this point you've spent next to nothing and should have a very rough idea of the size of the project (S-M-L-XL), the features it will deliver and the benefit. Enough to secure funding for a small team to execute a few sprints? If not, you're doing something wrong.

Once the team is up and running you'll have the experts on the case - developers will be able to get their hands dirty, the testers will be able to get to grips with any complexities, and we'll be deploying at the end of every 2 weeks so will understand what it takes to get the code released. In short, we'll touch every part of delivery and will build up experience.

After 3-4 sprints i'd recommend a major checkpoint to validate that the velocity is appropriate and burndown shows delivery at a suitable point. Now is the time to can the project, continue, or inject some investment (additional teams?) to potentially speed up delivery. The decision is in the hands of the customer but is based upon fact rather than crystal ball.

Strategic planning isn't irrelevant - it's the backbone on which the meat of development sits. But it supports development, rather than constraining it. Of more concern is the planning & prep work which we attempt on each project - we need to spend more time learning from development teams rather than second-guessing what they will do in the misguided hope that this somehow makes us more efficient. In many cases, the opposite is true.