Getting nowhere – at high velocity

I put this down for my own future reference a couple of weeks ago: I think David Anderson made an excellent observation with the side-comment

Oh, one thought, there is a way to cheat to make your flow efficiency look good - only measure it inside the Sprint ;-) and not from the point of customer commitment to delivery.

The original reference was in far more complex context,
discussing flow leveling and heijunka – check out the whole discussion on the mailing list – but I think this statement alone is worth re-visiting several times.

Many of the agile projects I have witnessed over the years were in really good shape and churned away story-points at a quite satisfactory rate. Yet, some of them were looked down upon by top management as unsatisfactory from a business point of view and a couple of them even got shut down.

To me this seems to be because of the same 'blind-spot' that could be one of the reasons behind the fact that – according to the Standish Group – 41% of agile projects do not achieve the expected result.

To have a successful project there is much more involved than just writing software and creating 'potentially shippable products' – so our process considerations should not begin and end with the creation of software. Instead they need to start and end at the customer and have to incorporate software-creation as an integral part of this process.

From this perspective measuring and optimizing the development team's velocity can be misleading. In fact, sometimes highly misleading. Apart from the simplest way to enhance your velocity (by just padding the estimates) even a real enhancement of this part of the process does not necessarily speed up the time until a customer is able to use any new features.

Wich brings us back to David Anderson's remark - you really have to measure the whole value chain. Not only inside the sprint but including all the adjacent areas.

• the time it takes from idea generation to the decision if the idea is going to make it
• the time it takes to really ship a potentially shippable product
• the extra iterations it takes to 'harden' the product, reduce 'technical debt' or one of the many other ways to account for thinks that should have been in the sprint in the first place
• etc.

When you start measuring lead-times like this – and focus on the flow of singe requirements in these measurements – you'll get a lot more insights into your real process.

Let me know what you think!

Cheers,
  Michael