Software development is quite a volatile job that requires constant efforts from the entire team in order to succeed. There is tremendous competition in the industry and all development teams are working rigorously to outperform their competitors. In such a dynamic and competitive environment, how do you accurately measure and improve the software productivity? We spoke to experts from the industry and have compiled a list of key metrics to measure developer productivity. Before we discuss the metrics, let’s first understand the term productivity in the context of software development.
Defining developer productivity
In general terms, productivity is defined as an individual’s ability to produce goods or services. But when it comes to software development, the word ‘productivity’ encompasses much more than that. Each part of the process of software development must be taken into account to reflect the effectiveness of the team.
Besides the developers, a modern-day software development team often involves personnel such as business analysts and front-end graphic designers. Thus, a team with a multi-disciplinary skillset requires a progressive guideline, must be flexible, and have an open mind. This dynamic complicates the decision of defining a universal metric or KPI that accurately represents productivity.
However, it is a common notion that the success of a business is defined by its customers. In that sense, a software project is successful when the product is ultimately approved and appraised by the targeted audience or users.
Therefore, your team is productive when:
- It can recognize the progress made and determine where it stands at a given point of time during a project.
- It delivers performance in accordance with the expected result for a user or a customer.
Challenges in measuring developer productivity
The world is not a perfect place and the pieces don’t just fall into the right places, at the right time. Working on a software development project can be very challenging and sophisticated.
While some project management tools are of great benefit for the successful completion of projects, they don’t necessarily provide insights into the individual developer’s productivity. This raises some serious concerns while trying to estimate the working efficiency of developers. Some of the issues are as follows:
Sometimes the developers are handed a substandard specification of the project in question. This raises a bunch of questions in the mind of the developers and they are often confused about the design and build phase. They’re left with no other option but to work things out on their own and refine the requirements.
In such a situation, the overall build phase takes a longer time than expected, forcing the developers to cause a delay in other projects.
There are some projects that require developers to create interfaces for trading information across multiple environments. For such assignments, it becomes essential to configure firewalls and supply credentials. Since the developers have to wait for several permissions, they are unable to start working immediately. This adversely affects overall productivity.
Many development teams are globally distributed
With the kind of advanced technology available, it has become very easy for businesses to outsource their work across different continents. However, this particular business model makes it harder to measure developer productivity. This is because of the developers operating in different time-zones and with distinct user stories.
A developer may successfully execute functionality that has been tested and works perfectly in their developer environment. But it further needs to be integrated with another developers’ class library or functionality.
An enterprise-level implementation can be particularly complex and drawn-out. The sheer volume of conference calls, emails, or instant messaging sessions, carried out to clear the doubts and put forward suggestions, can shrink overall morale.
Key metrics to measure the productivity of your software development team
The aforementioned challenges infer that a single metric cannot cover all the aspects of measuring developer productivity. Each developer has unique talents and skill sets and it will be unfair to judge all developers on one common parameter. However, we still need to track how things are going in a particular format.
“As dev leaders, we spend most of our time translating between two groups of people in two parallel universes. Most CEOs and board members come from the business side (sales, marketing, finance) and while they enjoy the outcomes of engineering, they don’t fully understand how we work. At the same time, many engineers don’t fully understand the business side of the organization. This is the background of most dev leaders. The right software metrics can help provide a common language between dev leaders and business executives.”
- Dan Lines, COO, LinearB
Thus, despite the limitations of rigid metrics, software development teams do need metrics to make data-driven decisions. So what are the ideal metrics that you should use to measure a development team’s effectiveness or productivity?
“As an engineering leader myself, I've come up with the formula that's been working well for a long time: reasonable goals multiplied by the team's overall happiness equal a productive and efficient development process. Thus, the most powerful software metrics to track revolve around the cycle time and the way your team collaborates.”
- Alex Sokolov, Senior Software Engineering Manager, iTechArt Group
Having said that, there are certain key metrics that can be used to assess the effectiveness and productivity of developers:
These reports are a key element in the agile scrum methodology. In software development terminology, sprints are time-boxed periods (1 week – 1 month) during which developers have to work on and complete planned projects. At the end of a sprint, developers update the manager with the progress they have made.
Using this data, the managers create a sprint burndown report that reflects the performance of each team member. These reports offer important insights such as:
- Consistent early sprint finishes indicate that the work allocated to the team members is less than the acceptable standard.
- Constantly missed deadlines signify that the workload allocated is too much as compared to the given time frame.
A gradual reduction in the ‘remaining values’ is better than a dramatic drop as the latter phenomenon shows that the work was not assigned in granular pieces.
The team velocity metric tracks the ‘amount’ of work completed during a specified sprint. It is calculated in terms of story points or hours. This metric is extremely useful for the estimation and planning of work for future sprints. It helps the managers in:
- Setting realistic sprint forecasts and delivery expectations.
- Point out unforeseen challenges that were unknown during the planning phase.
- Evaluate if the changes in the process have produced any results (stable/increased velocity)
This metric is used to track the exact number of tasks completed during a sprint. In other words, it measures the total value-added work output of the team in a given time period. It is crucial to align the results of this metric with the business goals as it shows the real-time performance of the team. Throughput metric assists in:
- Detecting whenever the team is blocked.
- Learning if the team is overloaded. This can be done by comparing the average throughput with the current workload.
4. Cycle Time
Cycle Time refers to the total time taken by the team for the completion of a task. It also helps in estimating the speed with which a team can deliver new features to the users and whether it can manage multiple issues.
Consistently recording and analyzing the cycle time helps in identifying the bottlenecks in the process and setting more accurate user expectations.
5. Bug Rates
This metric is used to track the number of bugs generated as new features are deployed. A developer team may release a product or an update quickly, but it is good-for-nothing if the code is bug-ridden.
Bug Rates metric helps you in determining whether a product is of value or not.
You can measure bugs in two aspects: (a) Severity of the bug (b) The number of bugs. A team can record the number of bugs shipped during each sprint and set a limit for acceptable bugs. Also, the severity of bugs should not be in the range of Medium to High.
Using developer productivity metrics the right way
How do you make the best out of these metrics and what are some of the mistakes team leads, project managers and CTOs should avoid? Let’s hear what these experts have to say.
Learn the art and science of software estimation
“The metrics we use are based on estimation. Software estimation is both an art and a science. On any project, developers provide estimates for building a software application. These estimates are then tracked to determine how well a team and team member are doing against an estimate. When tasks require more than the estimated time, developers request more time and provide a reason. Ideally, in retrospect, you would go through all the tasks and see what can be learned from the tasks that went over budget to use for the next estimation effort.”
- Michael Daoud, Founder & CEO, Visus LLC
Not all metrics apply to each team
“Different teams have different goals, and it doesn't work to try to force one productivity metric on everyone. Instead, let each team come up with the measures they want to be evaluated on. A team that builds a website might want to be measured on fast turnaround time. A team that builds critical backend systems might want to be measured on high availability and low bug count. The only thing the leader needs to do is to ensure that every measure has a counterbalancing measure to avoid the risk of a team gaming the system. If a low bug count is the only measure, the team might never deliver any new functionality. Once you have agreed with each team on their measures, challenge them to improve them, and agree on a reward for a given improvement.”
- Sten Vesterli, IT Consultant, More Than Code
Learn from the insights and keep adapting
“Enforcing these metrics at a management level is not enough. The team has to adapt and use it as well. These metrics can provide great insights into the efficiency of the team but are of no use if you don’t understand where the process is lacking and make the necessary adjustments. This isn’t a unilateral process. You need to have a discussion with the team to figure out the best way to implement those changes.”
- Deepu Prakash, SVP - Process & Technology Innovation, Fingent
Don’t let numbers deceive you
“The most common mistake done by managers is to measure work done in absolute numbers. Depending on your task, you may take days to figure out how to even get started. Although doing highly valuable work, it is misrepresented on your git log and might even affect how your developer does things, with the mindset that thinking = working.”
- Mauricio Giordano, CTO, InEvent
How to improve the performance of a software development team
As we have mentioned earlier in this post, the insights you get from these metrics will serve as a cue as to what needs to be improved.
In addition to that, certain basic measures like providing developers with a noise-free, pleasant workstation and conducting regular training sessions go a long way in enhancing productivity.
Lastly, clarity in objectives, motivation, and boosting developer expertise are keys to improving your development team’s productivity.
Encourage them to keep learning
“You can help your team be productive by supporting and boosting their expertise. Give them a chance to use their skills to improve their performance. Guide them to learn new techniques that will provide desirable results.”
- Dennis Bell, Founder & CEO, Byblos Coffee
Have your own definition of performance
“It’s key to define what performance means to you and your team. For us, it is developing what the user actually needs. Doing that in a high-quality manner, and as fast as possible - while keeping our automation up to date. Then you'd need to set up specific goals & key results and create an environment to help your teams focus on those goals. As soon as the goal is not clear enough, or there is too much noise with other stuff - it gets difficult to achieve it.”
- Atanas Georgiev, CTO, Enterprise League
Don’t ignore the importance of code reviews
“If you deploy often, a risk is not QA'ing the code properly, which could lead to lots of bugs and time spent fixing them. If the goal is to reduce that time, that pushes the team to automate testing, integrate QA effectively, and set up monitoring that rapidly pinpoints issues. Combined, we believe this creates a rapid and high performing team that has the side benefit of being very productive.”
- Neal Taparia, CEO, Solitaired
Daily reports are the key to long term growth
“I request regular reports from a team on progress. I want to physically see what they have accomplished or changed and what problems have come up since our last check-in. Keep the communication open. Trust your team enough to allow them to work as independently as possible but be there as back up for when they need you."
- Sarah Franklin, Co-founder, Blue Tree AI
The Bottom Line
In a nutshell, improving your development team’s productivity first requires you to define productivity and performance for your team. Even though metrics won’t necessarily give you the most accurate insights for individual developers, you need this data for a collective understanding of how things are going at your organization. When it comes to improving your team’s productivity, motivation, one on one meetings and relevant training sessions can do wonders for you.