I see folks using metrics to manage software development teams in a less than positive way. My friend Ed Hughes shared this article on why Velocity is Killing Agility and I tend to agree with the abuse of velocity in software teams these days.

I have advocated collecting velocity in past teams in order to capture the inherent capacity of the team. It’s a measure of a team; not a goal. It can’t be used to measure productivity. Don’t get me started on trying to measure productivity in software teams. If I have to have another conversation with an uninformed business leader on why we can’t simply measure something simple like lines of code by FTE to measure productivity I may never come back to software development.

Metrics can provide great insights into the effectivity of your development team. I love the advent of some newer metrics like cycle time that shows something that really matters - measurement of work in progress. Metrics can be used to inform team where they can improve. It can uncover issues that the team can then tackle.

Although many, many business books will extol the virtue of reducing inventory and work in progress on a manufacturing floor we have a hard time seeing it as a valuable metric in software development when we don’t have the complementary manufacturing measures like “widgets per hour."

I love using velocity as a metric for a team. I do find it useful for the right purpose. I use velocity to plan iterations and help a team become more predictable. And every business person I know loves predictability. If velocity is used to measure team productivity (or heaven forbid, developer productivity) it’s going to be gamed and become useless. If velocity is used to create incentives for people (or punish people), you should find someplace else to work.

In the end, I see the usefulness of metrics as part-and-parcel to the reason for the metrics to exist. A team (and by "team", I include executive leadership) needs trust. Where there is trust, the team can use metrics to improve. If the team doesn’t trust one another and metrics are used to “get more” or “find out who isn’t pulling their weight.” Work on establish trust within your team as any part of of using metrics to measure that team. One way to do that is to engage the team in the discussion around what you're measuring and why.

I don’t see folks ask the question “why are we measuring this?” I like metrics that help us understand if the team is producing software effectively. I also like to look at metrics to be sure the team is producing the right software. So many times, folks over-focus on producing software effectively and they don’t care if it’s right. The team can optimize to produce a lot of garbage software.

If you want a business metric to tie to a software development team - I still love the idea of using customer-based metrics like net promoter score (NPS) to really measure customer happiness. I see NPS as a way to truly get at the thing the business cares about most - a forward looking revenue metric (something that predicts sales and renewals). I also love to look at utilization, although there are more nuances to that metric by product. In the end - find a way to tie a product team to NPS as a business metric to be sure they’re producing value.

So what metrics can a healthy team use to measure and improve their effectiveness?

To measure that your team is functioning effectively: I like velocity for planning. I also like cycle time to measure the work in progress. I think a team needs to know how many escaped defects they allow out of an iteration. I think there are creative measures like number of source code check-ins that I don’t see anyone use. We had lots of success using an internal measure we called “release GPA” that measured the communication during release and the success of the release process. These are a sample of what I’ve seen as successful metrics to measure the health of a team producing software.