What the wrong KPIs could do to your software team

KPIs (key performance indicators) are essential to measure performance and ultimately, improve it. But how do you quantify excellent software code? Today, many software engineering KPIs focus purely on quantity: lines of code written, hours worked, and the number of bugs reported. In many cases, these KPIs can be doing more harm than good. The purpose of the KPIs should be to drive sustained improvements in the software team.

For example, say a development team is successfully hitting their KPI of under 50 bug reports a month. Is that because the KPI is driving them to write better code? Or is it just deterring them from reporting software bugs or launching new features? Bad metrics are easily gamed as they encourage a team to take action to make the metrics look good. It’s wise to remember Goodhart’s Law:

When a measure becomes a target, it ceases to be a good measure.

Sets of KPIs offer a “scorecard” on performance that an engineering leader can use to target actions to ensure tangible improvements. When used correctly, they capture precisely how a software development team is performing. 

But, a creative skill like software engineering can’t be summed up in terms of hours and lines of code–especially given the developing nature of Agile and iterative coding. Software engineering team leaders may need to rethink the KPIs to be a true measure of the fluid progress of software development. Ultimately, they could focus on encouraging constant, consistent improvement throughout the lifespan of a product by assessing the quality and team performance. Good metrics are invaluable, but bad metrics can make a team’s life miserable.

The Qualities of a Good KPI:

A good KPI should have the following qualities:

• Specific: A KPI should be a detailed yet simple, and clear description of what the actual goal is. For example, “Improve customer satisfaction” is too broad. A better KPI is, “Improve customer satisfaction ratings by 10% by the end of Q3.”
• Measurable: As demonstrated in the example above, KPIs should be quantifiable to establish an exact definition of success. When thinking about ways to measure, one could consider percentages, time, or raw numbers. 
• Achievable: KPIs should be ambitious yet attainable within reason. This ensures individuals working toward them are motivated and challenged but don’t burn out. It also helps set realistic expectations with stakeholders and company leadership. Conversely, a metric that cannot be acted upon is simply a vanity metric.
• Relevant: KPIs should help advance the key business objective(s) of the team. For example, if someone is on a client success team that falls under the company’s marketing organisation, their KPI should align with marketing objectives.
• Time-bound: A company could select an ambitious yet realistic amount of time in which progress towards a KPI can be measured. 
• Evaluate: Regularly examining KPIs is a great way to ensure that the team/business is still working toward the right objectives. During this evaluation one may question, Is this KPI still relevant? What are the main blockers to success? Do we have the right budget, tools, talent, and support? After this KPI period is complete, what should be measured next?
• Re-evaluate/Readjust: Consider re-evaluating your KPIs at specific periods—perhaps halfway through the KPI timeframe and again at the end. This could be the right time to determine whether it's necessary to make changes to the KPIs so they’re up to date, achievable, relevant, and in line with company objectives.

Applying these KPIs to Software Engineering:

KPIs and metrics are so valuable because they’re precise measurements that you can understand quickly and track over time. Here are four examples of software engineering KPIs that fit these criteria and allow businesses to gain a real understanding and encourage the real improvement of a software team’s performance

1. Time from first commitment to the deployment

Lead time in DevOps measures how much time has elapsed between committing code and deploying it to production, tracking the time spent on implementing, testing, and delivering changes to the codebase.

This is the easiest way to measure the whole development flow of a product. The git log command can be used to list commits in reverse chronological order (most recent first) and one can easily use git’s commits history to track the time it takes for each commit to reach production. This is more accurate than using User Story Lead Time on Kanban.

This KPI can be used to focus on improving the development flow by decreasing time to market, reducing rework and waste, optimising engineering efficiency, and cutting the costs associated with delays. Lead time in software development is also one of the four key metrics used by the DevOps Research and Assessment (DORA) team to identify how well a software development team performs.

2. Deployment frequency

Deployment frequency is how often a software engineering team pushes code into production.

This KPI is a good indicator of productivity–a low deployment frequency may mean a team isn’t getting enough value into customers’ hands. However, business goals are more abstract than just delivering a certain number of features, so rather than using deployment frequency to measure productivity, it could be used to evaluate other metrics like the responsiveness to failures triggered by bugs, the time to market and the speed at which security vulnerabilities are detected and fixed.

Long deployment times are often caused because only senior members of the software engineering team are allowed to merge code into production. Whilst well-intentioned this can slow the deployment frequency.

3. Team velocity

This is an agile metric that measures how much work a software development team accomplishes during a set period or sprint, usually in hours worked or story points. The higher the velocity, the more work a team achieves. The most common tool to keep track of the story points completed is a sprint burndown chart. Tracking team velocity can be very useful for forecasting, planning future sprints, and assessing the effectiveness of process changes.

Engineering teams can use it to get an idea of how much they can get done in the next sprint, whereas product owners can use it to predict how fast a team can work through their backlog. But one must resist the temptation to compare velocity across teams–especially when they’re first getting to grips with the Agile methodology. This is because work is a subjective term.

Never use development velocity by itself. Always combine it with metrics that will ensure the quality of the software code is not deteriorating.

4. Cumulative workflow

Cumulative workflow tracks the status of different tasks over time. This can most easily be visualised by using charts with dates on the x-axis and story points or work items on the y-axis, with different colour bands for the stage each task is at (waiting in line, in progress, ready for review, etc.) 

Colour bands progressing in parallel indicate a stable flow with about the same number of tasks coming in and going out. A widening band means tasks are coming in faster than the team can process them, and a narrowing band means the opposite: they don’t have enough to do. 
So, a cumulative workflow can be used to spot and smooth out inconsistent workflows and bottlenecks. Also, one could spot and deal with backlogs of tasks or see the average cycle time by looking at the width of each band. This can help you Identify when a project is falling behind.

If these KPIs are implemented, they could result in better code, more deadlines hit, shorter time to market, and better-quality products. But one shouldn’t get too fixated on them and make sure to have regular meetings with the software team to discuss and adjust them, welcome feedback, and encourage the team to take ownership of their goals.

How can Redline help in achieving your targets?

Redline Group’s mission is to enable high-technology companies to build world-class teams through knowledge-led recruitment to achieve their business goals. We have provided exceptional professional talent for the European Technology industries since 1982. Our team includes engineers themselves and recruitment professionals with many years’ experience in software engineering, meaning we’re able to provide the knowledge, contacts and support you need.

If you would like to find out more about recruiting contract and permanent software engineers,  software developers, or other electronics and technology roles, contact us today. Also, keep reading our news & insights for more blog articles.