Agile Reporting for Executives: What to Measure and Manage

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Measuring the performance of a software team is a difficult task. If you lead a software team, it’s likely you’ve run into this issue. That’s even more true when those teams follow agile software principles. Agile reporting often focuses on the wrong kinds of things. Leaders looking for help with agile reporting are usually looking at anti-KPIs like the team’s overall velocity, or how many lines of code they write. When team leaders measure the wrong things, software teams focus on what you measure, not on delivering value to customers. 

In this post, we’re going to talk about what you should and shouldn’t measure with your software teams. We’ll focus on the measurements that benefit your business and your customers. We’ll also highlight metrics that hurt your team, since every metric dumped into the bucket of agile reporting doesn’t provide equal insight. When we’re done, you’ll know the metrics you should focus on, and the ones you should throw out. 

Agile Reporting Metrics You Should Ignore

There’s a unifying attribute of all the metrics on this list: they’re easy to gather. Easy metrics are kind of like the Dark Side in Star Wars. They’re quick shortcuts to reporting on a team. They require very little thought, and they’re often trivial to gather. But they often twist and obscure the real value software provides. As with all metrics, one of the key questions to ask yourself is, Why are we collecting this data? If you can’t easily answer that question about a metric to the team you’re reporting on, you shouldn’t use that metric to make decisions. 

Lines of Code Written

This is one of the easiest software metrics to gather. It’s a sparkly metric for many executives because it’s easy to track week over week and compare between teams. It is also, as any developer will tell you, absolute poison. Using lines of code written as a metric ignores a fundamental truth of software development: it’s impossible to measure the value of a single line of code. That might seem counterintuitive, but code is not like widgets produced in a factory or sales leads. We can quantify the value of an average sales lead by examining the attributes of the customer and comparing them to similar customers we’ve sold to in the past. We know that a lead to a particular customer type tends to convert at a certain rate and deliver a certain dollar value in sales. 

Using lines of code written as a metric ignores a fundamental truth of software development: it's impossible to measure the value of a single line of code

Software isn’t like that. Instead, code syntax is often variable, meaning that there are many ways to express the same thought. Oftentimes, it’s possible to express the same thought or behavior using 2 lines of code and 100 lines of code. If I choose the method that uses 100 lines of code, the extra 98 lines of code often provide negative value. They’re more likely to contain bugs, and make the thought I’m expressing more difficult for other developers to read. In reality, it’s often the case that removing code is the most effective way to achieve a goal in software. 

Velocity

Another common measurement of agile teams is team velocity. Velocity is a measure of the number of “points” of tasks completed in a sprint. It’s one of the most common ways to measure agile team performance. It is also, unfortunately, largely useless. Velocity measures a completely arbitrary value. It’s trivial for a software team to double their velocity in the space of one sprint. They just estimate the complexity of each of their tasks twice as high as they usually would. By the end of the iteration, they’d complete no more work, and deliver no more value to the customer. But they’d double their velocity, making them look great on a metric dashboard. 

Agile Reporting Metrics You Should Focus On

As a leader, it’s important to understand how your metrics change the teams you work with. Observing something people do changes the way they do it. When you’re choosing what to measure about your team’s performance, keep in mind that that decision will change the way they perform. Teams will naturally gravitate toward trying to perform better on public metrics. They will, rightly or wrongly, conclude that their continued employment hinges on how well they perform. They’ll assume that things like bonuses and promotions will depend on their ability to meet metric targets. With that in mind, it’s important to remember the power your metrics have. They will actively reshape your engineering culture. So choose those metrics wisely. 

Demos of Working Software

At the end of the day, this is the single most important thing for your software team: delivering working software that brings value to your customers. Everything else you want to measure about your engineering team is secondary. Can they deliver software that meets your customers’ needs sufficiently? If the answer is yes, you’re leading an effective software engineering team. Unfortunately, that’s something that’s a bit difficult to measure. There are some ways to measure overall platform health with your software, through tools like Net Promoter Score. But that won’t tell you what any individual team is working on at any given time, or how well they’re doing. 

The demo ceremony is one of the most important parts of the agile software life cycle.

One way you can measure a team’s consistency in delivering value is through tracking their software demos. In almost all agile teams, the team gathers with stakeholders at the end of an iteration. They go down the items the team committed to at the start of the iteration. For the things they finished, they present demos of the work. These demos are a cause for celebration and an opportunity for stakeholders to identify new opportunities for iteration in the software. The demo ceremony is one of the most important parts of the agile software life cycle. When you measure demos delivered, you encourage your developers to focus on delivering finished, customer-valued software. That’s exactly what you want out of your teams. 

Cycle Time

This is a more traditional metric, but it’s another one where the focus you bring improves things for your customer. Measuring cycle time means measuring the amount of time that passes between a customer asking for a feature and the software team delivering that feature. This measurement is a good proxy for how satisfied your customers are when they request features from a team. Customers who experience a long lag time between requesting features and working with them are less happy than customers who get features more quickly. Measuring cycle time also empowers you to identify bottlenecks in your software development life cycle. 

Lowering your cycle time means focusing on the highest-value items on your backlog and eliminating bottlenecks. Both of those actions increase customer satisfaction, and happy customers come back to your business. They also bring their friends. When you focus on metrics like cycle time, you’re encouraging software development processes that focus your team on doing what you want them to do: delivering value to customers. 

Choosing the Right Agile Reporting Metrics Is Critical

As we’ve seen here, many teams focus on the wrong agile reporting metrics. This focus harms their team and their business. It focuses developers and leaders on tracking the wrong thing, and modifies behavior in ways that harm the business. Unfortunately, many executives believe that easy, harmful metrics are the only ones they can gather. They think that better metrics are too difficult to gather, but that couldn’t be further from the truth. Tools like LinearB make it easy to gather useful, productive metrics from the tools you already use. When you focus on those better metrics, you unlock the potential of your team and align their work with your business goals. LinearB makes it easy to measure how well your team is performing and boosts that performance to delight your customers.

LinearB Dev Pipeline Acceleration is a developer-first scientific approach for engineering team improvement that provides workflow orchestration for Developers, Pipeline observability for team leaders and Investment allocation for executives. Get started today
Want to improve your engineering processes and cut cycle time? Get started with LinearB today!

More To Explore

Never miss a post

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering and product leaders striving to be better for their teams

Join our community of data-driven dev leaders