Metrics

Troubleshooting Velocity

Troubleshooting Velocity

Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.

After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.

Velocity Anti-Patterns - Attempts to show increased velocity

Velocity Anti-Patterns - Attempts to show increased velocity

When leadership asks for an increase in velocity, there are a few common behaviors that occur. Each of them are an attempt to satisfy the potentially unrealistic ask.

It is intriguing to me how often a manager will make a change such as this to a system of work and then later proclaim that the team is gaming the system. This is simply not the case. In fact, the gaming of the system is the improper application of targets or goals for lagging indicators. The rest is just natural consequence.

You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".

Velocity Anti-Patterns - Enticing More Velocity

Velocity Anti-Patterns - Enticing More Velocity

Leaders (and teams) attempt to achieve velocity increases in numerous ways. Most, as you can imagine, have unintended side effects on the teams and none significantly improve the actual flow/delivery of value to their customers. Here we explore a few ways teams might be encouraged to increase their velocity. Unfortunately, no matter how well intentioned, using such techniques still has a negative impact.

This content and more on agile metrics is available in the book, "Escape Velocity"

Velocity Anti-Patterns - Demand for higher velocity

Velocity Anti-Patterns - Demand for higher velocity

Demanding more velocity is far and away, the most common Velocity Anti-Pattern, and quite possibly the most harmful. It manifests itself in a number of differing fashions, but the basics are the same: Somebody determines that the team needs to get more done in less time. So they send out the message - “We are going to need more velocities.” This person is usually an authority figure and typically doesn’t do the actual work being asked of the team. And they clearly don’t know what velocity is. More velocities? Aw C’mon, really?

This content and more on agile metrics is available in the book, "Escape Velocity"

Velocity Anti-Patterns - Introduction

Velocity Anti-Patterns - Introduction

If you’ve been on an agile team that uses velocity as a key metric, you’ve probably experienced or at least witnessed some pretty strange behavior.

I asked a group of agile coaches and practitioners via Twitter and LinkedIn about dysfunctions they’ve seen on teams related to the use of velocity. I received plenty of responses that inspired head shaking and hand wringing. I pulled out the most commonly identified issues related to velocity and metrics and share them here.

You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".

 

Unit Testing is to code coverage as Exercise is to weight loss

This is a quick post, following up on a tweet from a little while back:

"Unit testing is for code coverage like exercise is for weight loss. You're actually missing the point."

A great number of people in the software field appear to think the primary benefit of unit tests is test coverage. Some even talk about them as if they were one and the same. "No need for more unit tests, we have plenty of coverage already."

Stabilizing Velocity

Stabilizing Velocity

Have you ever been on a team where your velocity suffered wild variances? Maybe you ended up using a running average instead of yesterday's weather?

Have you heard phrases like, "Well, our velocity last iteration was 3, but our average is still 22"?

Have you ever heard the phrase, "Dude, we need to get this velocity stable."

Have you worked on teams where they took partial credit for done at the end of the iteration? Where maybe you'd split a card strictly on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration.