In which Noise is given a new home

Noise (pronounced "NOISE!!!") has moved to a new home at http://code.google.com/p/noisevst/

It's bigger than the old place, but the neighbours are a bit weird.

On the abuse of velocity

I have, over the years, witnessed many abuses of the agile term, Velocity.

• It's used as a stick for managers to beat developers with: "[Y]our velocity of 3.913 is too low. It needs to be at least 4.239 for us to deliver on time".
  

• It's used as a meaningless indication of work completed in an iteration: "Our customer was on holiday and could not sign off any stories. Our velocity last iteration was therefore 0". Or, my favourite: "We completed 10 points last iteration. That's 5 more points than the previous iteration. Thanks for working twice as hard!"
  

• It's used to attribute some kind of precision to a process which has none (see quote #1).
  

• It's used to support all kinds of crazy non-science during planning: "Our velocity last iteration was 10. Bob is off this week so I will deduct 1 point, however Alice is back from holiday and is more experienced than Bob, so I will add 1.5 points back. Plus another point because the clocks go forward tomorrow".
  

But the thing that really REALLY bugs me is that velocity is so often used to measure the wrong thing. Hands up if you release working software each iteration? I don't mean "signed off" or "demoed" features, but actual working software, running in a production environment and ready for the customer to use? If you don't, but you still measure velocity per iteration, and you still "sign up" for the same number of points you "finished" last iteration... why? Why measure velocity? It doesn't tell your customer when their software is going to be ready, because you aren't measuring your success at delivering working software. All you're measuring is the speed at which your team writes code, which is not the same thing.

To figure out when the software is really going to be ready, you now have to factor in all kinds of deployment, load-testing, performance-tuning and emergency bugfixing at the end of your *real* release cycle, but you haven't got a clue how long that work will take because you've never done it before, and therefore have no velocity!

Just because I work for ThoughtWorks...

...don't expect me to know what the hell Shu Ha Ri means.