Developer productivity management:
a complete guide
How to build productive software development teams and track their progress
How to build productive software development teams and track their progress
With the ongoing digitization across all industries, it's fair to say that most companies are becoming software companies. However, with this reliance on software to take companies to the next level comes a reliance on the people and the processes that build it. Because of this, developer productivity is becoming more and more central to business success.
But, what even is "developer productivity," and how can we encourage, measure, analyze, and manage it? In this guide, we'll examine what the software development community believes developer productivity is and how we can gain insight into and better manage our team's productivity.
Alright, let's get started!
In everyday language, "productivity" is the ability to produce. In software development, developer productivity refers to a team's ability to achieve outlined business objectives through developing, improving, and maintaining software.
We surveyed developers to understand better how they viewed the concept of productivity in the context of software development. The overwhelming majority agreed that it is a "combination of processes and tools and people and skills."1 Despite this, the most common method of measuring productivity, and for a surprising amount of teams, the only method, is throughput (i.e., amount of units of work completed). There seems to be a discrepancy between how we define a developer’s productivity and how we measure it.
To better understand how we can measure and define dev productivity more comprehensively, let's examine what productivity experts call the SPACE framework.
In the world of software development, the SPACE framework is one of the most referenced frameworks for understanding what productivity in software development consists of and how to measure it. Developed by researchers at GitHub, Microsoft Research, and the University of Victoria, the SPACE framework suggests that there are 5 key elements we can use to guide, assess and measure dev productivity.2
When we think of "productivity," it’s easy to think of humans as "cogs in the machine" that need to produce. This myth of "hustling" and burning yourself out at a job to be more productive has long been debunked. It turns out productivity and job satisfaction are strongly correlated – in our survey, 94% of respondents rated how important job happiness was to their productivity over an 8 out of 10.3
In other words, developers are people, not resources. They have needs and natural ebbs and flows in their productivity and shouldn’t just be milked for everything they’ve got – this can lead to burnout. Because of this, it's important to measure and encourage developer satisfaction and prevent developer burnout as a part of managing your team's productivity.
Here are some questions you can ask to determine developer satisfaction:
The “performance” aspect of the SPACE framework refers to the development team’s ability to produce outcomes that provide value to the customers and the business. According to our survey, the #1 benefit of improved productivity is the ability to write quality code. In other words, are developers doing “meaningful and quality work”? Two elements make up performance:
Quality pertains to the work meeting a standard that the business, the customers, or both set. Quality-related metrics differ based on what the business objectives are. These are some examples of quality-related metrics that may define a team's productivity:
“Impact” refers to the impact the work the development team completed has on the customers and the business. Some examples of metrics that may define the value a release has provided customers are:
Some examples of metrics that may define the impact the development team has on the business are:
Quantity and speed
Quantity and speed refer to a certain amount of completed items in a specified time. Examples of business objectives measured by quantity completed include:
A team’s ability to communicate and collaborate together effectively greatly impacts its ability to stay productive. However, much of the work that goes into smooth collaboration and communication goes unnoticed and underappreciated.
Here are some quantitative and qualitative ways of measuring how effective your team’s collaboration and communications are:
Tooling also plays a big role in how satisfied developers are with their team's communication and collaboration. In fact, 36% of developers who sought productivity tools for communications reported they were extremely satisfied with their jobs. In addition to looking at the above metrics to measure the quality of collaboration and communication, we also recommend surveying your team to see if they are satisfied with the tools they use to facilitate it.
The final element of the SPACE framework is efficiency and flow. Developers struggle to be productive without the ability to "get in the flow" and work distraction-free. This final element includes tools that help minimize distractions, tools that allow information to flow efficiently, and other processes that promote flow (like agile project management).
Efficiency and flow can be measured and understood by:
Now that we’ve covered what developer productivity is and what it entails, let's discuss how to manage productivity on software teams.
Productivity management is the process of implementing and tracking tactics meant to enhance a team’s productivity. Tech leaders can use the SPACE framework outlined above to identify areas to enhance and measure the productivity of developers.
To address all elements listed in the SPACE framework, there are many tactics for managing a team’s productivity – from project management to goal setting and tracking, to process automation, to formal retrospectives – all of which can fit under the umbrella of “productivity management.”
At Zenhub, we’ve identified 3 key tactical areas for managing software development productivity:
Processes and project management contribute largely to the “performance” and “collaboration” part of the SPACE framework as they help teams collaborate efficiently and prioritize tasks by level of impact on the business. In fact, in our survey, developers rated “poor planning” as the #1 obstacle to productivity.4
While project management plays a key role in productivity, it can be a productivity drain when it relies on inefficient processes. Because of this, back in 2001, a team of software engineers developed the “agile manifesto,” a project management methodology that focuses on working on only the most impactful work.
Below is a chart of some of the most popular variations of agile project management and the productivity Pros and Cons of each method. It should be noted that most teams do not follow agile frameworks to a tee. Learn about agile realists vs. purists here.
The second part of using project management as a way to become more productive is preventing it from becoming a productivity drain itself. Sometimes, agile processes can result in a lot of time-consuming admin work. This is where the tactical approach of automation comes in.
Handoffs and workflows
Typically, in agile environments, handoffs are something that we try to reduce or eliminate entirely. Still, for most teams, this is a regular part of collaboration. Minimize the impact this has on efficiency by setting up automation, such as automatically moving issues as their status changes from one team or individual to another. Having an agreed-upon issue template with requirements can also help reduce issues with knowledge transfer.
Sprints are a regularly occurring item in an agile environment, so naturally, they can be automated. Consider automating the creation of a new sprint in your team’s regular cadence and automating the movement of issues from one sprint to the next to save your devs time.
Some aspects of agile estimation can be automated using a digital story point estimation tool like planning poker. For example, you can have planning poker automatically notify team members when an issue needs estimation.
A big benefit of agile project management is its emphasis on reporting. However, reporting can be time-consuming if not automated. Automated reporting typically involves either having an agile tool that has reporting built-in, like Zenhub, or integrating your tools with a tool for reporting.
Manual QA work can be monotonous and slow teams down. To combat this, one dev we surveyed said they were using automated testing to improve their team’s efficiency: “More automated testing allows developers to detect problems early in their development cycle, rather than at the end of the sprint when they've handed it off for QA validation.”5
To learn more about agile project management and improving the productivity of agile processes, visit our blog.
As the SPACE framework makes it clear, how one measures developer productivity is a debatable and broad subject. There are many factors involved in developer productivity, not all of which are easy to measure. Despite this, most of the developers we surveyed say they engage in some type of productivity measurement.
However, the most common and quantifiable metrics are usually those found in agile methodology. Because of this, we’ll focus mostly on agile metrics in the section below.
In the simplest terms, velocity calculates the average amount of work completed by a single team during a software development sprint. Velocity is a good metric to track, not only to see how productive a team is in a single sprint but also to estimate productivity using historical data to more accurately estimate release dates.
Tracked using: Velocity chartLearn more about Zenhub velocity charts here.
According to our survey, throughput is the most popular method of measuring developer productivity. Throughput measures the total number of units of work (often represented as issues or story points) completed by a team in a given period. As one dev we surveyed puts it, “We measure productivity during sprint planning and retrospectives. Productivity is measured based on story points completed in a given sprint.”6
In agile development, units of work are typically represented by “# of story points,” but you may also choose to calculate it by # of issues or any other terminology that represents a unit of work.
Tracked using: Various reporting tools – cumulative flow charts and burndown charts often display this data or you can also use what some teams call a “throughput histogram.” If your team hasn’t generated any of these reports, you can get instant throughput metrics using our free GitHub analytics tool.
Learn more about tracking throughput using Zenhub here.
Work left in a sprint (“Burndown”)
In agile, “burndown” refers to the amount of work left before the end of a sprint. Calculating burndown allows you to see progress in real-time, identifying possible obstacles to completion.
Tracked using: Burndown chartLearn more about burndown charts in Zenhub here.
Epic and release burndown
Epic and release burndown charts are very similar to the sprint burndown, however, they calculate the burndown for an individual epic or release. These can be useful when measuring progress and identifying blockers in an individual project rather than just in a sprint.
Tracked using: Burndown chart
Learn more about burndown charts in Zenhub here.
Cycle time is the amount of time a team spends working on a product, from planning to release. This includes both time waiting between stages and time working on a product. Cycle time is used for calculating production and can be useful in communicating with stakeholders about how much lead time a team requires to complete a product.
Tracked using: Cycle time scatterplot chart
Learn more about cycle time in Zenhub here.
Time issues spend in each pipeline (cumulative flow)
Tracking “cumulative flow” is just a fancy way of saying that you’re tracking the average number of issues in each pipeline. If you take a look at a cumulative flow chart, the chart used to visualize how much time each issue spends in a pipeline, you may notice some common blockers in your team. This can be really helpful information for project planners to know in order to address frequently occuring bottlenecks.
Tracked using: Cumulative flow chart
Learn more about cumulative flow chart in Zenhub here.
Why track productivity at the team level: We generally advise tracking productivity at the team level because how a team works together is usually a more accurate indicator of productivity since software development is collaborative. The reporting options for group tracking (i.e. velocity reports, cumulative flow, etc.) are also much more useful for project planning and stakeholder management, whereas individual metrics have few applications beyond performance reviews.
Why track it at the individual level: The main instance in which it's recommended to track individual productivity is if you are an engineering firm that requires individual tracking for billing purposes. In this case, time-tracking software can be used to generate invoices based on billed hours.
Individual developers who want more data points to quantify their contribution to their team for when they're building a portfolio or going into a review may use individual productivity markers
Amount of time spent coding: When it comes to time spent coding, quality over quantity is always the best measure of meaningful work. It's difficult to benchmark exactly how much time should be spent coding, and, with team members all at different levels, it would be counterintuitive to measure their effectiveness by “time spent coding.”
The number of lines of code: Once again, quality over quantity. Measuring your developer’s productivity based on “lines of code” is a very quick way to reduce the quality of the code your team produces and lower team morale.
Measuring developer productivity is a nuanced subject. Learn more about measuring developer productivity here.
See how productive your team is based on your actual GitHub project data, and learn how that compares to the top 100 of GitHub's most starred, forked, and active repos.
The final tactical approach for managing developer productivity is implementing the right tools. There are many categories of productivity tools – here are a few most common for development teams:
Measurement tools track your progress and/or create reports based on your team’s productivity over time and the metrics they are interested in tracking.
“Time-saving tools” can be anything that saves your team time, regardless of which process/task it's enhancing. Most time-saving tools automate or replace tasks, or simplify processes.
Tools for project management keep teams productive by keeping them aligned on priorities and enabling easy (and usually remote) collaboration so they can work on only the most impactful tasks.
Get more ideas on tools you can use for developer productivity here.
Developer productivity is so much more than output. It involves people – their skills and well-being; processes – their effectiveness and ability to not "get in the way"; quality assurance – not allowing fast production to hinder performance; and insight – constantly learning from past sprints. Tactically, there is so much that teams can do to manage their productivity, from automating processes to adopting detailed reporting to trying out new tools meant to make everyday tasks more efficient. We hope some of the insights you've learned from this guide can help you manage your team's ongoing productivity optimization. For more productivity tips, visit our blog.
Zenhub is used by 8000+ of the most innovative software companies in the world. Join them with a Zenhub free trial.