On Velocity, and Being the Chump

Last week, I mentioned my theory that most development teams have one person who just isn’t that great at getting things done. Like spotting the mark at a poker table, you want to figure out quickly who that team member  is. In poker, it’s so you can take advantage of that person. In software development, it’s so you can set a kind of intuitive trust level: something between will this person make it harder to accomplish our goal? and can I count on this person’s tasks being properly fulfilled? with a little bit of how should I adapt my work style? in there.

Obviously that perspective’s going to be different depending on whether you’re a peer, a specialist, a team lead, a manager, a client, or whatever else. In this post, however, I’m talking generally from a project management angle.

Velocity defined and refined

One huge part of this relates to the term “velocity” when applied to Agile projects, particulary those using Scrum. Oversimplified, velocity is a rough measurement of how much work a team or member can accomplish in an hour or a day or whatever. The units can–and should–be abstract, but proportional to your estimation system.

For example, in a sprint planning session you might figure a certain set of tasks as a hundred units of work. Given the twenty to twenty-twoish workdays in a monthly sprint, one of your team members (or you) can successfully handle fifty units of work. That’s your velocity. You’re not going to get that work done this month.

Another developer might have a monthly velocity of a hundred units. She will very likely finish those tasks if they’re assigned to her, or at least come really close.

Why it matters

There are two keys to this view of velocity. One, you have to be really nonjudgemental about it. Just because a certain team member has a lower velocity than some others, that’s not an indictment of the person. He might be fantastic in meetings, or a great pair partner, or simply just learning. He might have less experience overall, or much more experience but weighted in a different area of expertise. He might be the team member who everyone else turns to with questions. He might be someone you keep around for political reasons or because of potential. That’s fine. Velocity isn’t personal worth. Period. It isn’t even team worth.

But two, you do have to know the number! It’s kind of a fine line, isn’t it? You end up with a number more or less publicly attached to each person on your team, and bigger numbers are (out of context at least) automatically better. And at the same time, you can’t get sucked into a tempting competitive comparison of those numbers. They just are what they are.

The real chump

How does this come back to being the chump? Maybe I shouldn’t use that word… being nonjudgemental and all. But no, I will.  Because the chump isn’t the developer with a smaller velocity number. The chump is the one who’s satisfied with it, who doesn’t look for ways to improve, who lets the team down and creates problems for others.

Sometimes chumps come in a high-velocity version, like the “Hero” that John Miller talks about. A Hero may have a fantastic velocity, but if it comes at the cost of excessive overtime, code hoarding, or really difficult handoffs, that awesome velocity verges into chumpery. You have to look at the whole effect on the team’s health and its ability to meet goals.

Note that I’m not including testing or QA or remediation time in that list of high-velocity pitfalls. That’s because the velocity measurement is supposed to already include full-cycle time costs. The feature that takes eight hours to code, twelve hours to debug, and two hours to get configured in the installer–that’s not a twentieth of your velocity for the month, it’s more like an eighth. If your code goes through a lot of break/fix cycles, that’s low velocity–not high velocity over and over again!

Conclusion and comparison

Don’t get me wrong. A lot of times the chump is the low-velocity team member who simply isn’t getting that much done and is okay with it. Then you have a management decision. But once in a while you get the mixed blessing of a high-velocity developer who also engages in chumpness. Then you have a different management decision!

Next week I’ll write a little more about programming “heroes” and heroes. In the meantime, The Smartest Guy I Know gave me an idea that I’ll develop for Friday’s blog entry: why really capable people end up working on stuff that doesn’t matter. What’s that about?