Mark Needham

The last two projects that I’ve worked on I’ve been on the project from right near the start, and one thing that’s been consistent in both projects is that we’ve spent time early on in the project trying to reduce technical risk.

In my most recent project this has involved getting infrastructure in place early on, and in the previous one it involved working on technical spikes for several weeks to prove that what the client was asking for was actually technically possible.

While reading Crystal Clear I noticed that this approach is the same as that advocated by Alistair Cockburn with regards to putting the highest learning tasks up front before business stories, and the idea of the walking skeleton.

Some people consider this opposed to the agile approach in that we are creating something before we absolutely need to use it. I think this is a difference in the understanding between doing something at the last responsible moment and the last possible moment.

The former is the way that I understand we should do things – get the pain out the way early on and not later on death march style

I wonder whether it should be the same on a per story basis or if there is no gain from taking this approach – i.e. usually the backend side of stories is what takes up the time so should we do this first and then drive out the rest or is it better to drive from the front?

One thing I have learnt from conversation about this idea is that we still need to show some progress to the business and therefore need to balance the need to reduce project risk with completing business stories.

Clearly there is a trade off to be made here but I think the ‘risk up front’ approach is preferable to leaving the integration until later on when it is both more difficult to do and doesn’t leave much room for error either.