At some point in their careers, all engineering managers, leads, and CTOs have wondered how to measure and improve developer productivity. This is because developer productivity plays a role in the software delivery pipeline, which drives business performance.
However, before improving developer productivity, you need to measure current productivity levels. To do this, most leads will keep an eye on the version control graph, use the wrong metrics, or guess their way through it. When none of these work, leads can get frustrated and accidentally kill the team's morale.
Luckily, this doesn't have to be the case because there's a better way to measure developer productivity.
In this post, we'll dive into what developer productivity is and how to measure and improve it.
What Is Developer Productivity?
We all have a picture that comes to mind whenever we hear the term "developer productivity," and we've probably seen various definitions on the internet. But for this article, here's mine: Developer productivity is the measure of how efficiently a developer or the software engineering team can handle software development operations within a given time frame. The operation here goes from building to deploying and maintaining the software.
Maximizing developer productivity is crucial because tasks within the software development process will get done faster and more efficiently.
Why Is Developer Productivity Important?
For starters, your developers are building the products or experiences you're selling to your users. Without them, revenue goals and business operations would deteriorate.
Measuring developer productivity gives you an idea of where the bottlenecks are and what needs to be improved. It lets you evaluate progress over time and improve the operational efficiency of the engineering team. Remember, you can't improve what isn't measured.
Besides the business goals, developer productivity also helps you determine how to increase your developers' velocity.
What Is Developer Velocity?
The term "developer velocity" can be traced to a 2020 report published by McKinsey. The 11-page report discussed developer velocity and how organizational enablement can influence productivity, increase innovation, and outperform your industry market.
Developer velocity is a technique used to improve business performance by empowering your software engineering teams through an enabling environment so they can be more productive. This also entails giving developers the right set of tools to allow them to reach their full potential as developers.
How Not to Measure Developer Productivity
Measuring your developers' productivity comes with many benefits, from products getting launched more quickly to higher revenue.
However, using the wrong metrics or measuring productivity based on inputs and outputs can be detrimental. Let's look at an example:
If you follow Git-based metrics, you'll have a pretty impressive version control graph, high screen time, and busy developers. By Git-based metrics, I mean metrics like the lines of code, number of commits, and pull-request counts.
However, you will discover a problem: your developers are working more, but their commits offer no significant value to the project. This frustrates you, and you might fire a few developers. Now you have an unhappy engineering team in a hostile working environment filled with pressure.
The problem here was that these metrics didn't provide any actionable insights. For example, writing more code (lines of code) or staying late at the office doesn't necessarily mean a better product or productivity.
Instead, these measures prioritize quantity over quality and promote burnout and a poor-quality codebase. A better approach would be to focus more on quality and create a collaborative environment that drives developer velocity.
So How Should Developer Productivity Be Measured?
It is essential to measure developer productivity beyond just the many lines of code a developer can write. This means considering the quality and innovative effort involved in the software development process. One of the ways to measure developer productivity is through metrics.
What Metrics Should You Track?
To measure developer productivity, we'll focus mainly on three industry-leading metrics—DORA, value stream, and flow metrics—which address the software development process and the business value of the process.
DORA Metrics
DORA metrics measure teams based on their throughput, velocity, and quality using four metrics to measure software development regarding business goals.
- Deployment frequency (DF) measures the frequency of successfully deployed codes to production.
- Mean lead time for changes (MLT) talks about how long it takes from committed code to successful code running in production.
- Mean time to recovery (MTTR) captures how long it takes to resolve deployment or system failure.
- Change failure rate (CFR) indicates the percentage of deployment causing failures in production.
Value Stream Metrics
Value stream metrics capture the value and successful delivery of the software to the value it offers the end users. The value here could be an improvement in the existing features, new features, fewer bugs, or even a better UI. Here are the metrics measured:
- Lead time measures how long it takes to deliver a new feature.
- Cycle time states how long it took from the first commit to production. This includes the coding time, pull requests, merges, and deployment.
- Deployment frequency measures how often development cycles are completed.
- Defects look at how often and how many bugs are found in production. This indicates the code quality and effectiveness of the value stream.
Flow Metrics
Flow metrics talk about the value delivery from inception to business outcome. This is used to optimize the value of a product or software from the company to the customer. There are five metrics used to measure flow metrics:
- Flow velocity measures how quickly something is being delivered.
- Flow efficiency captures how much bottleneck, unplanned work, bugs, or patching had to be done during the delivery process.
- Flow time measures the time to market.
- Flow load measures the number of stories or flow items yet to be completed.
- Flow distribution indicates the state of features, defects, risks, and debts in the flow delivery system. This lets you decide what to prioritize and how to make trade-offs.
Measure Team Productivity
Measuring productivity based on an individual's output comes with a specific flaw primarily because nobody works in isolation, and every team member contributes differently. Tasks are often split, and collaboration is crucial to the team's overall growth.
For example, while some of the team handle testing, others work on technical debt. This doesn't suggest that individual metrics are useless, but they don't paint the most accurate picture. However, when you add the team's output, you tend to get a holistic view, from non-engineering activity to core engineering tasks.
How to Improve Developer Productivity
Here are some ways to improve developer productivity.
Using Developer Velocity
Microsoft created a Developer Velocity Assessment tool to calculate a team's developer velocity index (DVI). The DVI score is calculated by reviewing the internal process in four areas—tools, culture, product management, and talent management—that have positively impacted productivity.
The McKinsey research also established that working on these areas boosts developers' productivity and gets developers into the flow state, which is a state of optimal productivity and inspiration.
Overall, simply creating a healthy, collaborative culture around your developers can boost productivity faster than you can imagine.
Developer Productivity Dashboard
The intent of any dashboard is to provide a clear, straightforward view that displays important metrics using the right visual elements in real time. Dashboards focused on developer productivity are no different.
These dashboards enable you to access information on metrics quickly so team leads can take proactive steps. Thus, your metrics must align with your business priorities and customer needs. This can be accomplished using tools like OpsLevel, which provide a comprehensive overview of your metrics and services in one interface without compromising autonomy, speed, resiliency, or accountability.
Is There a One-Size-Fits-All Approach?
Every organization will measure developer productivity differently. Thus, aligning your metrics with your business priorities and customer needs is always best. For example, a large tech giant wouldn't evaluate its developers like a series B company. These two companies would be at different stages and would thus have different business priorities.
Google, for one, uses the goals/signals/metrics (GSM) system to track productivity with goals for products and features. The system requires the engineering lead to set the goal, tie a signal to it, and back it up with measurable, quantitative metrics. Additionally, Google pairs a team of engineering productivity specialists with the core engineering team. This system has proven to be very beneficial. A series B company might not have this many resources and thus can use tools like OpsLevel to get metrics that align with their business and pair it with a developer productivity dashboard.
In a Nutshell
Measuring developer productivity isn't so straightforward. First, to properly measure and improve developer productivity, you need to define your business priorities and use metrics beyond just the lines of codes. Then, to get a comprehensive overview of the software engineering team, you should combine these quality metrics—DORA, value stream, and flow metrics—with a clear framework and a developer productivity dashboard.
To get started on the path of an accountable engineering culture, request an OpsLevel demo today.
This post was written by Ifeanyi Benedict Iheagwara. Ifeanyi is a data analyst and Power Platform developer who is passionate about technical writing, contributing to open source organizations, and building communities. Ifeanyi writes about machine learning, data science, and DevOps, and enjoys contributing to open-source projects and the global ecosystem in any capacity.