Variation in Velocity
Tim Ottinger, a guy I’m proud to say was a co-worker of mine in an ancient past life, wrote a nice piece about a common mis-practice in measuring the velocity of a software project. I won’t re-explain velocity here. His article defines it very well and the way he explains how you can do it wrong really makes clear what it’s all about.
In case any of my 4 readers are too lazy to click, think of it as a number, bigger is better, measuring how quickly you are approaching the goal of shipping your software so you can get paid for the new stuff in it. How fast are we getting there? We have 30 things left to do. We are getting 12 done every three weeks. Looks like we start selling this thing in July. Yay!
Measuring it wrong leads to disaster, obviously. Oops, we couldn’t actually start selling until September. No one can sustain a business like that, at least not in this economy.
I’d like to quibble with this point:
“If velocity is going to have some normal variation due to emergencies arising, then many wise managers know to plan with a little slack.”
I don’t like seeing “normal variation” and “emergencies” so close together in the same sentence.
Deming had a purist view about variation, much like Tim’s purist view on velocity. Both are correct.
In Deming view there are exactly two kinds of variation.
Common causes of variation are statistical noise. Even the most well-managed stable system has variation. You don’t and can’t know the cause of it. You can manipulate it indirectly by experimenting on your environment, procedures, materials, etc. in hopes of making a new stable system that is better than the old stable system. “Why” is a dangerous question to ask here. It’s nearly impossible to have any confidence in our answers.
Special cause variation is introducing new causes, often by accident, into a system. These include but are not limited to emergencies. You fix them by looking for a root cause and eliminating it. We want special causes to be rare, and we mitigate our risk by building ever more robust systems to work in.
If we work in systems where special causes of variation are common, what can we say? We still haven’t figured out how to build robust systems. Agile at it’s best seems like a candidate for being that system. But if we can still say “normal variation” and “emergencies” in the same sentence with a straight face, we have a long, long way to go.
That sounds about right, come to think of it.