Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

The definition of the word velocity as defined in a dictionary I just referenced is ‘speed in a given direction’. That has two important components and I am not convinced, that when used in an Agile context, both are always true.

We use velocity as a measure of progress and eagerly count the points we have achieved sprint by sprint, plot them in charts and put lots of effort into making sure the numbers are as high as they can be. But isn’t that mostly concentrating on the speed part of the definition? How much true effort is applied to the ‘given direction’ element? When we use the term, the direction component is implied but is it justified?

Burn up charts just show how fast we are doing work, but they don’t show if the work is targeted towards specific objectives. A team can deliver story after story from a fully prioritised backlog and not make gain any ground towards the objectives unless we manage that ‘given direction’ component. If the work isn’t a vector, then it’s just speed isn’t it? Are we fooling ourselves by proudly using the word velocity and implying something that we can’t honestly justify?

OK, so we use the concept of ‘Minimum Marketable Features’ or ‘Minimum Viable Product’ to try and focus on getting out the smallest solution first, and I think that’s a step in the right direction (no pun intended) but I am not convinced that it’s enough.

At IndigoBlue we use an Incremental Delivery Strategy which helps target work across multiple MMFs but that’s not part of the standard Agile governance tool set and thus not available to most teams.  

So the question I am posing is do Agile projects need more robust governance to ensure our speed is truly describable as velocity?