Mark Needham

One of the key ideas behind agile software development is providing information as early as possible to allow the business to best make decisions.

There are a variety of ways that this is done including the use of burn up charts, estimates of scope and velocity for example. This data is compiled to try and give an accurate idea of how long a project is likely to take so that the business can work out early on whether the value it adds is worth the expected cost.

I strongly believe in this approach, certainly favouring it over other approaches that I used before working at ThoughtWorks. However, over the last couple of months I have started to wonder whether providing the business with this information so straight up actually works against you.

I believe the way that the information is viewed is different depending on when it is provided.

For example, if you have a piece of work which is due to take 12 weeks and you work out after 3 weeks that based on the current velocity it is likely to take 14 weeks you are in a weaker position than if you keep this information to yourself and then ask for another two weeks when you get to the 12 week mark.

From the business' perspective I suppose it makes sense – if after 3 weeks you're already 2 weeks behind then who knows how far you will be behind after 14 weeks.

I am not suggesting that it's better to hold back this information but surely there has to be a better way to present it because from what I've seen the baseline figure is what's looked at and the details are ignored.

Nor am I advocating that we under estimate on purpose to get the baseline figure lower. Clearly you will end up ruining your delivery reputation if you consistently over promise and under deliver.

The driver behind the agile approach is to always add business value, and while as a developer I would prefer to try and provide something to the client, as Mark points out, it has become clear to me that maybe sometimes cancellation is the best way of doing this.