Developer productivity is a tricky thing to measure and manage, primarily when you’re working with an agile methodology. When I’m leading an agile team I want to be sure my team is continually improving. However, I’ve found some popular metrics are confusing or downright misleading if you're going to foster an environment for reliable, clean, creative code.

The things we measure determine our focus. This is as true in software development as anywhere else in life. For agile teams, it’s important we avoid choosing poor measures of management. The metrics you choose as a measuring stick for your team will determine how your team works to meet their goals. In this article we’ll take a look at measures that encourage productivity, quality, and satisfaction for your agile team.

Bad Metrics for Agile Teams

A confusing paradox in software development is that the worst metrics are usually the easiest to measure. Team managers often make the mistake of measuring commits, lines of code, bugs introduced, or bugs fixed. The problem with these metrics is two-fold.

First, by measuring commits or bugs, you’re implicitly telling your developers what you value. You may say, “Of course we want more commits and fewer bugs!” Developers are smart, though. When you pick something to measure, like commits, your developers will learn ways to game the system to boost their numbers when needed. You’ll end up with employees who feel they’re being micromanaged and who expend copious amounts of energy on gaming the system.

Second, any experienced software developer knows that creating good software is much more complicated than commits, lines of code, or bugs resolved. These metrics don’t track code quality, creativity, or the need to test multiple new ideas before settling on an option. They only tell part of the story.

Context is Key

Good metrics take context into account. They look for overall trends and patterns in the way your team is working. None of the above metrics consider if the tasks assigned to the developer involved more risk, legacy code, learning a new technology, or any other complex challenge.

As you endeavour to measure a team’s productivity many factors can affect productivity metrics. For instance, the team might be onboarding new members or losing veteran members. Perhaps the team encounters unexpected technical debt or has to learn a client’s existing code structure before implementing new features. A team member's absence, or even just feeling a bit under the weather, could affect overall productivity metrics.

Measure the Team & Organization, Not the Individual

Another critical point for agile metrics is not to measure the individual. Individual productivity can vary from day-to-day. You won’t gain much insight from checking in on each of your developers one-by-one. Not to mention, individual tracking makes team members feel like they’re under constant surveillance.

Instead, track team and organization-wide metrics to get a better sense of overall trends in the data. For instance, the impact of a new senior developer can be seen over time in the team’s total productivity.

Tracking the senior developer by him/herself might not show you this overall trend. Perhaps the team is more productive because other team members can now ask questions or run ideas past the senior developer. This synergy wouldn’t show up in the senior developer’s personal productivity numbers, but it impacts the whole team.

If I need to check up on an individual, I look at churn and throughput for individuals and associate that with a team average.

Qualitative Metrics

Modern business methods are obsessed with numbers and quantitative measurement. However, for agile teams, qualitative measures of how the team feels about its performance can be just as useful, if not more so.

Stefan Wolpers has an excellent article on asking your developers how things are going. I recommend it as a great read on qualitative metrics for agile. He suggests a 30-second questionnaire after each sprint to ask about general impressions.

Then, every 4-6 weeks, Stefan implements a more extensive survey with his developers. He asks a series of questions and has his developers indicate 0, 1, or 2 for each. Zero means not applicable or failing at this criteria. One means we’re doing it, but it could be better. Two means I’m happy with how we’re implementing this practice.

In the end, Stefan averages the responses, and the chart looks like this. Notice how it changes over time:

You can clearly see the places where Stefan’s team is performing well and where they feel they could improve. Over time, the goal is to make more of the boxes green. It’s an easy and effective metric that helps identify the quality of work the team is producing.

Conclusion

What you measure matters. When leading an agile team the easy metrics are usually the least insightful. Instead, focus on context, teamwork, and quality with your measurement. It will make a huge difference in identifying areas for improvement and encouraging team morale.