The principle of small regular releases is a religion amongst a fair chunk of the software industry. So the fact that I am questioning it probably means people will create voodoo dolls of me and that I’ll find a severed head on the doorstep in the morning.

Or then again maybe not. I have worked on projects that have gone like clockwork up until deployment time. At that stage things started to go very wrong for various technical reasons. So regular releases on technical grounds to demonstrate that we can do it and to resolve any problems early, makes perfect sense. I don’t think anyone would disagree with how beneficial this is.

The central reasons for doing iterative development in the first place – in terms of how features and stories are managed, analysed, developed and tested – also broadly* stacks up, together with how the work is organised.

It is the idea that iterative development and frequent releases “delivers business value quickly” that I have a problem with. It’s great if it happens, but does it? I have to say that I rarely see it, and there is a big difference between delivering iteratively and people actually using what each iteration delivers.

What I generally observe is a culture where the users or customers think “I might as well just wait until the end when it is all done”.

So why is this?

Well, perhaps your project is such that there isn’t sensible way in which individual iterations could be usable to people. Is an HR system’s Employee Create screen any use if the Employee Update screen isn’t coming until three iteration’s time? maybe I’ll just wait until both are available? Maybe having people use the create feature before the update feature is available is even undesirable: it would complicate a later release and make the deployment of the update feature more risky. This doesn’t undermine the principle of iterative development – it is just a characteristic of the environment you happen to be in.

Another aspect goes back to our old friend estimation. If the estimation and budgeting process for the work has forced people into budgeting for the whole thing way in advance (a daft practice we’re stuck with which inevitably leads to people estimating and making decisions before they sensibly can and should), then the customer will inevitably think “I’ve paid for the whole thing now, so I will come back at the end when it’s all done”. If you’ve ever wondered why customers are reluctant to attend stand-ups, or engage generally there’s your explanation also.

It could be that the regular release principle isn’t a good fit for your sector. Every organisation, department and project is different, so perhaps the expectation of ‘regular releases you can use’ just isn’t appropriate. To deliver iteratively doesn’t mean people can or will use the results.

* I wouldn’t want to give the impression that everything in the world of iterative/agile is perfect because it certainly isn’t and there are many pitfalls. This Blog discusses many of them. It’s not a utopia.

« »