March 23, 2006

...Learn TDD with Codemanship

The Next Train Arriving At Platform 3

One of the Holy Grails of software project management - and it's not just confined to software - is predictability. Customers want to know what they're getting and when they're going to get it. Project managers like to know that commitments they make to the customer are going to be honoured so they can hold their heads high in polite society.

The problem is that software projects - and, again, it's not confined to just software - are very, very complicated. And very, very complicated things tend to be nigh on impossible to predict accurately. What we can do is get in the ballpark. We can tell by experience - and experience is very important in predicting things - that a project might take a year. It might take 15 months. It might be done in 9 months. But it won't take 100 years. And it won't be done in a week. Our judgement, based on experience, tells us whether we're looking at a flea, a cat or an elephant of a project. But fleas, cats and elephants don't come in standard sizes. Ask me at the conception of a baby elephant how big it is going to be when it grows up, and the best I can tell you is that it will be about so high and about so long and it'll weigh about so much.

And so it is with software projects.

But our goal of predictability won't go away. Customers still want to know what they're going to get and when they're going to get it, and we still want to hold our heads high in polite society. So what do we do?

If we view software develpoment as a service, like a train service, for example, then it might shed some new light on the problem.

This morning my train was late. The electronic notice board didn't say it was going to be late. 10 minutes after it was supposed to have arrived, the noticeboard still said it was on time. I had no idea when the train was actually going to arrive. I didn't know if I was going to make it to my 9am meeting. I could have taken a taxi instead, but a taxi journey into central London would take longer than the train - assuming the train turned up in time. And a taxi would cost about 10 times as much as the train. I could have left the station to grab a taxi, and the train could have turned up 2 minutes later.

Should I get the taxi? Should I call the client and tell them I'm going to be late? Should I wait a bit longer and see if the train turns up? I hate being in that situation where it's difficult for me to plan my day because someone I'm relying on - the train company - isn't giving me the information I need to make a decision.

Experiences with other kinds of service suggest that if there's one thing we hate more than delays, it's not knowing what's going on. And the sooner we know, the sooner we can adapt our own plans. The sooner we know, the less disruptive it tends to be.

If software development is viewed as a service, then maybe it's not changes to the plan that are the problem. It's not knowing that the plan has changed. And the longer customers are left in the dark, the more disruptive it is to their own plans.

As developers, we need to give customers the information they need to make decisions, and we need to give it to them as soon as we can. And the quality of that information is paramount. The worst of all worlds is subjective, handwavy project data delivered too late for the customer to do anything about it.

It's a good idea for train companies to keep their noticeboards up to date. And it's a good idea for the information they give their customers to be accurate and useful.

It's a great idea for project managers to keep their customers informed - maybe on a weekly basis (maybe a daily basis near a release date). It's a really great idea to give customers honest, accurate and useful information.

Agile planning creates many opportunities to "refresh the noticeboard" with an up-to-date picture of progress. The most useful information you can give a customer is how much longer there is to go for the requirements to be satisfied. If the deadline's fixed, they might like to know how much of the requirements will be satisfied by then. It gives them an opportunity to respond and adapt if the plan changes. And the plan will change.

Your estimate of progress will be much more realistic if you don't base it on opinion. Asking developers when a feature or bug fix is likely to be finished is universally accepted to be the worst way of measuring progress. User acceptance tests give you a clear picture of what actually has been delivered and what hasn't. If it works, it's finished. Don't take anybody's word for it.

If I were a project manager who wanted to satisfy my customer and hold my head high in polite society, I'd be updating my plans every week based on objective feedback from executable tests.

It's not rocket science!
Posted 14 years, 9 months ago on March 23, 2006