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.

Explore posts in the same categories: Uncategorized

3 Comments on “Variation in Velocity”

  1. tim Says:

    Oh, geez, I didn’t realize I wrote it that way. I mean events, but it was late on a friday (sustainable pace? Not so much). Thanks for pointing it out.

  2. Heh. Definitely sounds better when you say event instead of emergency but the special vs. common cause distinction still applies.

  3. Jeffery Dilegge Says:

    You are absolutely right. I underquoted the timeframe on a large project a couple of years ago and I have regretted it since. Chalk it up to a learning experience.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: