There’s nothing better than checking something off your to-do list.
Except, of course, checking off that big, burly project that has taken way too long when you’ve finally completed it. (Yeah, that feels pretty good.)
This simple insight has some important implications for how we consider and measure productivity.
Getting more done isn’t the same thing as being productive. This is one of the key reasons why a software developer’s productivity is difficult to measure in an accurate and effective way.
But it’s not impossible.
Developer productivity is something that’s measurable. With the right tools and the right data, we can understand the overall effectiveness of a development team and their ability to produce results.
In order to do that, we need to first consider the context of the work that’s being done.
Start by Prioritizing the Most Important Work
Getting sh*t done feels good. But, getting the right sh*t done moves projects forward.
That’s why the first and most-critical part of understanding a developer’s productivity is having a priority order of what tasks are the most important or have the most dependent items.
It’s easy to accomplish 100 small tasks to make yourself look more productive. But in many cases, it’s the one, big, ugly project that takes the most time and is holding us (and the rest of the team) back from moving forward.
So, how do you decide which tasks are the most critical?
President Dwight Eisenhower–the decorated military General–had a famous and simple way to quickly decide which items were most important. It cuts out the guesswork about which tasks are critical and which tasks can wait–or be eliminated entirely.
It’s called the Eisenhower Box.
Most development tasks within a sprint or iteration already have a relative priority assigned to them. But that doesn’t mean that there aren’t sometimes competing tasks to consider.
Developers and managers can use a similar framework for understanding and prioritizing that work.
This provides a clear picture for what work needs to be done. But, there’s still the question of measuring or evaluating the productivity of individuals. There are a lot of competing ideas about which systems are best for accomplishing this. Some of them are good–many are bad.
First, let’s look at all of the ways that aren’t right.
How NOT to Measure Developer Productivity
There are a lot of bad ideas in the world.
But some of the worst are–without a doubt–ways to measure developer productivity.
In almost every case, these half-baked metrics are used to measure the wrong thing. They’re easy to game. And they don’t provide any real or actionable insight that individuals or teams can use to improve their performance.
1. Lines of code (LOC/SLOC)
Do we even have to discuss this one?
I’m not even a developer myself and I know that trying to understand productivity by simply measuring lines of code is a terrible idea.
As a writer, I strive to be succinct. More words don’t make my writing better–they make it worse.
Writing code is similar in this regard, of course. Some of the best, most elegant solutions to complex problems require a relatively small amount of actual code. Writing two perfect lines may replace 500 lines of spaghetti.
Not only is this not a good way to understand productivity, but it actually incents developers to do worse work. Obviously, not ideal.
2. Hours worked
This one should be obvious, too.
The most productive, efficient, and high-performing developers accomplish more work and solve more difficult problems in less time. So defining productivity as the number of hours worked is a nonstarter.
Not only is this a poor way to measure productivity. Additional work hours actually reduce the average productivity per hour for each hour worked.
In a study from Stanford University, researchers found that employees made to work 60 hours per week often accomplish less–in aggregate–than employees who only work 40. The findings implied that people who are overworked may even begin to clock negative productivity. This would likely be characterized by an increase in errors or oversights that workers then need to later correct.
Time worked as a measure of productivity is a lose-lose.
3. Bugs fixed
Ha. Ha. Ha.
That’s a joke, right?
I think Dilbert can sum up the problem, just in case it isn’t clear:
4. Tasks completed
We’re getting a little closer. Many teams–both development teams and otherwise–measure productivity in terms of how much stuff gets done. On the surface, this seems like a perfectly plausible solution.
Of course, what we know is that not all tasks are equal in terms of complexity or work required.
I can do 100 things a day and look super “productive” on paper.
But, I could also avoid any and all forms of meaningful or difficult work. That’s not good.
So, we know that simple measuring tasks completed isn’t a meaningful way to understand productivity. We need a better system.
Better Ways to Understand Developer Productivity
The unfortunate truth is that there is probably no one-size-fits-all solution to measuring developer productivity (sorry). But, you can develop the right strategy for your specific team–or for specific team members.
Define the right metrics
So, how should developer productivity be measured?
It generally comes down to pinpointing productivity based on two types of metrics:
- Measurement of work completed
- Measurement of quality or importance
Taken together, these two figures can spotlight both how much work is being done and also what level of work is being done.
There’s no definitive metric here that’s the right fit for every team. Development methodology, team structure, and other specifics will all come into play.
But there’s also another consideration to take into account—the type of work that developers are doing.
Not All Metrics Have a Clear “North”
Be careful when choosing the metrics that you use to pinpoint productivity.
In some cases, metrics that seem to be “good”–i.e., you want the number to be higher–may actually be “bad”.
For instance, some teams try to measure productivity as a function of tasks completed and technical debt created. This may seem like a good way to ensure that developers are completing as much work as possible without sacrificing code quality.
But, is technical debt always a bad thing?
If your team is in the midst of a testing phase that involves iterating quickly on as many ideas as possible, it may actually be desirable–and necessary–for developers to introduce additional technical debt.
The point here is that there are a lot of ways to measure productivity using different metrics. But no one system is guaranteed to work all the time.
The best metrics for measuring productivity are likely to change depending on the type of work that people are doing.
This means that teams should either be extra cautious about defining metrics that always have the same orientation. Or, it may mean that the metrics used to measure productivity need to change to accurately gauge work being done during different phases or on different types of projects.
Time Tracking and Developer Productivity
We’ve written extensively about the role of time tracking software teams.
But you may have noticed that I didn’t explicitly state time tracking as way to measure productivity (other than a non-productive way to measure).
But time is important—for a number of reasons.
Hours and minutes are a static frame of reference. It’s how we understand the amount of work gets done over what period. In other words, it measure efficiency.
Now it can be tempting for development managers to jump on this measure to try to drive more work in less time. But, time tracking is best used as a tool for individual developers to understand their own abilities.
If they maintain a steady level of output (e.g., productivity), then the time that it takes to accomplish that work should decrease as they improve and grow in their craft.
This is a different measurement and it’s important not to conflate efficiency or expediency with what’s actually getting accomplished. As a development manager or executive, you should be focused on giving the team the right tools and information to get the most amount of work done. Then motivate and empower developers to meet or exceed those goals as efficiently as possible.
Measuring productivity can be difficult. But using the wrong metrics makes it impossible.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.
Top comments (0)