Developer productivity – how to measure it

Human beings are cognitive misers by nature, and we tend to solve complex problems in the simplest way with the least amount of effort. This is how we've been measuring "developer productivity" by taking the simplest method available.

What’s the first thing that comes to mind when you hear “developer productivity”?

I bet this is negative, and there is no doubt that this is almost a taboo among development teams, as leaders are often afraid that talking about this issue will make the team think they are being micromanaged or lack trust. Two reasons: The

1. approach to developer productivity is abused by engineering leaders, and as we call it.

2. "Developer Productivity" is not a formula and we don't thrive in uncertainty, so we choose to either take the easiest path or stay away from it.

Just think about it: With billions of dollars spent on development teams every year, if there was a one-size-fits-all way to measure developer productivity, would it still be a mystery? Or will you read this blog?

PS: If you are reading this blog with the intention of measuring your most productive developers or getting a number that will help you promote and fire developers, turn away because you will be disappointed.

So should we try to measure developer productivity?

Yes, that’s right! ! Because developer productivity isn't just about improving engineering results, it's also about ensuring the satisfaction and well-being of the team. Often, productivity metrics also help identify bottlenecks in the development process and challenges with the team's work environment and culture.

Phil Jackson, one of the most successful basketball coaches, put it beautifully:

“The strength of a team is in each member. The strength of each member is the team The power of.” — Phil Jackson

In the context of a development team, the success of every team depends on each developer bringing their best and continually contributing to the team’s success.

Okay, now how should I measure developer productivity?

Two fundamental pillars maximize your chances of success in measuring developer productivity.

1. Never reduce productivity to a single metric

Measuring developer productivity is difficult because we are trying to measure people involved in both logical and creative tasks. And we, as cognitive misers, try to reduce productivity to a metric – let me be clear, this model will fail.

Instead, try to capture productivity across multiple dimensions and leverage something like the SPACE framework (S-Satisfaction and Happiness, P-Performance, A-Activities, C-Communication and Collaboration, E-Efficiency and processes) can help developer teams measure developer productivity in the right way.

2. Communicate with the team

There is a very common misunderstanding: Developer productivity is only suitable for managers. This couldn't be further from the truth. Research shows that there are significant differences between developers and managers’ perceptions of developer productivity. Most developers associate higher productivity with higher activity, while most managers associate productivity with performance and efficiency.

This apparent gap in perception can only be eliminated when development teams discuss what productivity means to them and what their true intentions are in tracking productivity . This helps clarify why this is important and how we should measure it, and also removes the reservations that most development teams have. Is this the number that determines our rating? Or are we doing this because leadership doesn’t believe we can get the job done?

Things to do

1. Use the SPACE framework to track developer productivity across multiple dimensions.
2. Communicate intentions to the entire team.
3. Use productivity metrics to identify areas for improvement and eliminate bottlenecks.

What not to do

1. Reduce productivity to a single metric.
2. Develop secret measures to track productivity.
3. Use metrics as the sole metric for determining evaluation.

Developer Productivity Metrics

Now let’s look at some developer productivity metrics tracked across spatial dimensions.

Developer Productivity Metrics:

Satisfaction and Happiness

A highly satisfied team is a highly productive team. This is one of the biggest indicators of a healthy team and work culture. However, satisfaction is an abstract concept, and if someone asks you "How satisfied are you?" forget about measurement. I'm sure you'll think for a few minutes before answering this question, what satisfaction means to you and how to quantify this. We know that capturing this aspect numerically is extremely difficult. So what you see here are proxy metrics that try to best capture different aspects of developer satisfaction and happiness.

• Job Complete: Whenever we complete a task, our brain releases dopamine, which makes us feel satisfied and motivated immediately after the task is completed. Therefore, a high rate of work completion compared to the work promised will make the developer feel very satisfied as he/she is able to complete the work promised in a timely manner and contribute to the success of the team.
• Overtime: Overtime ≠ higher productivity; in fact, the opposite is true, overtime is one of the biggest contributors to developer burnout and harms their well-being. Tracking extra work hours, such as on weekends or late at night, can help you understand whether your developers are happy and performing well in their current work environment.
  • Business is not a means to achievement, but an obstacle to achievement
    ——Alex Soojung-Kim Pang
    
• Disengagement: Dissatisfaction and Burnout The most common indicators are disengagement from the team and team activity. One way to measure developer engagement is to measure changes in a developer's general response time to team activities such as code reviews, or a decrease in interaction or attendance in team meetings.
• Developer Surveys: Often, when it comes to determining the best productivity metrics, we forget the most obvious way, which is to question your team and understand the sentiment of your team by running and analyzing a developer satisfaction survey. Ask questions like "Are you satisfied?" (Rating 1-5)" is the worst way to understand this. However, there may be other questions that can help you capture similar information in different ways and dimensions.
• Tenure: Tracking overall team satisfaction A good way to measure this is to look at the average tenure of members on your development team. Considering the nature of developer trends, a suitable tenure range could be between 12 and 18 months. Anything lower would definitely cause concern.

Performance

The best way to measure the performance of developers and development teams is to measure results rather than output. These metrics help us capture the quality aspects of the work developers do. For any For developers, the ideal outcome is "developing features with minimal rework, ensuring timely delivery and maximum customer satisfaction."

• Rework: When a developer needs to correct their pull request or When tasks are often returned from QA to developers for bug fixes, this is a clear indication that the quality of the work done is not up to the expected standard. Repeatedly, this ultimately leads to extended feature development cycles. The idea is not zero fixes, and rework is often due to Changes in requirements; however, if one developer is facing an unusually high number of issues than others within the same team constraints, then this is definitely a sign of a performance gap.
• Just-In-Time Delivery: Per Project One outcome that business leaders care about is delivery predictability, as many other business decisions communicated by customers often rely on these delivery dates. To have predictability throughout the engineering process, each developer also imbibes this quality is absolutely important. One way to measure this is to look at how many tasks developers submitted during a development sprint/iteration were completed.
• Customer Satisfaction: Agreed, this is what brings value to any organization The most important result, and therefore must be the same for the development team. Customer satisfaction might mean better reviews on the app store, or higher uptime and faster response times for the API service, or for For the platform team, it might mean ease of use and minimal reported bugs for internal libraries used by other teams. While customer satisfaction is driven not just by the engineering team, using it as a performance metric can keep development teams aligned with what they are building. Stay connected with real users of the product and help them focus on the right things.

Activity

The activity dimension itself broadly equates to developer productivity because it is the easiest to track dimensions. However, activity alone can never truly measure developer productivity. Tracking activity metrics in conjunction with other dimensions from different areas of the SDLC process will help you identify real developer bottlenecks and areas for improvement.

• Solved Tasks: Activities in this phase help determine how often and to what extent developers contribute to development tasks. Given that development tasks are always planned as tasks, user stories, or subtasks on the project management tool, looking at the total tasks solved can help understand developer involvement in this part of the development cycle.
• Reviewing pull requests: Usually only the technical lead or the manager of the development team has the responsibility to review changes/pull requests, which is an obvious anti-pattern. Encouraging each developer to review more and more of their peers' code helps eliminate review bottlenecks. This metric would be a great way to determine if a developer is contributing to the team's review load.
• Deployment Frequency: The number of times a team deploys changes to a production system can help you understand the speed aspect of the development process. This is also one of the DORA metrics, which studies show is also highly correlated with customer satisfaction and even the profitability of an organization, making it an excellent measure for tracking the dimensions of productivity activities of a development team.

Communication and Collaboration

In any development team, the end product (whether it is a feature, service, application or enhancement) is always the result of a team effort. Good communication and collaboration are the foundation for building an efficient development team. Incorporating this dimension when measuring developer productivity can promote a culture of transparency and information sharing. Some productivity metrics that help capture this are:

• PR Wait Time and Cycle Time: If the development team has good collaboration, this can be clearly reflected in their review process as this Probably the most bottleneck of the development process as it depends on effective communication between contributors and reviewers and vice versa. A metric that helps track how collaborative a developer is is measuring the time it takes for that developer to start reviewing a pull request after it is assigned. Next, measuring the average cycle time of pull requests can help understand a contributor’s communication skills.
• Number of members working together: Development teams often have knowledge silos and groups of developers who only interact with each other and not with the rest of the team; this is another classic anti-pattern. Measuring how well a developer communicates and communicates with other team members is a good way to measure this dimension.
• Onboarding time for new members: Whenever a new developer joins the team, they go through an initial learning curve, learn about the business environment, become familiar with the technology stack, and often get help with code walkthroughs. The time it takes for a developer to make their first impactful change since joining is an important productivity metric for development team communication. As a team with good documentation practices, developers willing to put in the effort to help new comers will enable new developers to make impactful changes as quickly as possible. A good benchmark to strive for is a new developer's first productive result within the first 30 days.

Efficiency and Process

This is the dimension of "entering the process" that developers often talk about. Metrics here help understand how many interruptions there are in the development cycle and how smoothly a task flows from start to finish. Frequent interruptions not only impact developer productivity but can also lead to increased levels of stress and fatigue.

• Uninterrupted development time: It is absolutely important for developers to have enough uninterrupted time every day to get into the process and invest time in development activities. One of the biggest obstacles is team meetings. Often, to encourage longer development times, teams adopt meeting-free workdays or adopt strict time slots during which team meetings can be scheduled. Longer uninterrupted development time does not necessarily indicate higher developer productivity. However, it is certain that if developers do not have enough uninterrupted time, the process required for development cannot be achieved.
• Commit lead time: More interruptions in the development cycle, more handoffs, and reopening tasks too frequently are indicators of poor development task efficiency and flow. Commit lead time captures this accurately because it measures the total time it takes for a change to have an impact on end users. A relatively high commit lead time (CLT) definitely means a decrease in the efficiency and flow of the development team. CLT is also one of the DORA indicators. More information about this can be found here.
• Average Work in Progress (WIP) Ticket: Context switching is undoubtedly a productivity killer. Doing more things at the same time always means more time is needed to get everything done and can also lead to unnecessary mental exhaustion.
  • Two parallel tasks — 20% lost due to context switch.
  • Three parallel tasks — 40% lost due to context switches.
  • — Gerald M. Weinberg

WIP tickets perfectly record the number of tasks a developer is working on in parallel. Tracking this productivity metric and trying to keep it below three tasks is a good starting practice for your development team.

Change Engagement

When you look at the metrics that improve developer productivity, the actions that will help you drive change will be changes in the development process. Measuring developer engagement in the changes the team is driving can help understand how hard each individual is working to correct team processes. Each process change can have a metric associated with it that captures how well the process is being followed, and leaderboards tracking these metrics can help you gamify and understand which developers are contributing well to your process change initiative .

This is everyone!

We see that developer productivity is often misunderstood as a single metric or an easy-to-track metric, rather than a metric that actually matters. It's absolutely critical that we track developer productivity and take a holistic approach to improving developer productivity, taking inspiration from frameworks like SPACE. It is best to start with a few indicators, but it is important to choose these indicators along at least three dimensions. We’ve discussed the exhaustive list of dimensions and the many metrics within each dimension, now you and your team need to figure out the right dimensions and the right metrics that are most impactful.

The above is the detailed content of Developer productivity – how to measure it. For more information, please follow other related articles on the PHP Chinese website!