Why Measure Dev Team Productivity?

I read recently (possibly on a forum?) that as a development manager your product is the team. I like that analogy and, if you buy into it, your main KPIs should be centred on your team’s performance.

There are plenty of reasons to measure performance such as measuring velocity to plan future work but the main reasons I want to measure productivity are:

• To answer the question ‘are we better as a team than last month?’
• To measure the results of changes.

Changes can be changes we have made or experiments we are doing as a team e.g. no estimates or everyone works remotely for a sprint. It’s important to be able to measure the effect of the things we try. Other changes may be external e.g. changes to seating plans in the office or business priorities and again it’s important to know the impact of these.

What Do We Measure and How?

This will be different for different teams and there will never be ‘One Measurement’ that works for any team. The best solutions will include a number of measures that, when combined, will be indicative of team productivity.Another consideration is measuring teams and measuring individuals. There should only be one reason for measuring an individuals performance and that is to support that individual. Even in combination the measures will probably not fairly reflect a developer’s contribution to the team and should not be viewed or used out of context. I am still in two minds how useful individual measures can be…

Complexity

Complexity is useful when done well but is hard to do well and will vary depending on the project the team is concentrating and, probably, the technologies they are using. We have a fairly monolithic legacy app that started life 10 years ago and a number of much leaner loosely coupled services, also the team is, on the whole, a lot more comfortable in Ruby than Javascript.

Contribution

Contribution can be documented in Github as commits, pull requests, comments, and merges, or in Jira as comments, status changes etc. These contributions should be fairly easy to measure but allowance does need to be made for pairing.

Code Churn

Okay, LoC is never going to cut it as a measure of productivity but maybe code added, removed, or changed can be added into the mix, again allowing for developers working in pairs.

Pull Request Lag

No one wants to have to merge a pull request that is 6 weeks behind master.

Avoid manual processes

You will want to automate as much of this as possible, manually collating data can work for short periods to answer specific problems (currently the team is logging interruptions to their flow) but is unlikely to be successful in the longer term.Lastly, it is important that the team buy into this and the reasons for doing it. The team at Reevoo are currently looking at what they want to measure and how to automate collection. I’ll report back when we have something in place.