For anyone working with a product, it is very simple to understand that both discovery and delivery are two essential steps to success. Defining the success of discovery is complex, but many times we are so immersed on a daily basis that we can feel and know if it’s healthy or how to improve. But not every product person understands how programming works and whether their team is having a healthy delivery.

For this, it is necessary to start from the point of defining, what is healthy? There is a very famous phrase in management that says:

“You can’t manage what you don’t measure.” — Peter Drucker

Based on this principle, it is clear that being “healthy” is something that needs to be measurable. It doesn’t have to be a yes or no, but one or more metrics that help pinpoint where we’re going wrong.

What should I follow in the day-to-day of a development team?

In the Software Development area, we see a continuous difficulty in defining which numbers to analyze and which will best represent the performance of a team.

In general, most of these metrics focus on superficial productivity, and they have two drawbacks. First, they focus on what the team does rather than the result the team generates. Second, they focus on individual measures rather than teams or areas. Three examples of bad metrics are: lines of code produced, speed, or tickets resolved.

DevOps Culture

In order to get which metrics you should look at, more than just setting new numbers we need to change the basis of software management culture.

At this point, another culture that contributes a lot to solving these problems comes in, DevOps.

A composite of Dev (development) and Ops (operations), DevOps is the bringing together of people, processes, and technologies to continually deliver value to customers.

What does DevOps mean to teams? DevOps enables previously isolated functions — development, IT operations, quality engineering, and security — to act in a coordinated and collaborative way to deliver better, more reliable products. By embracing a DevOps culture in conjunction with DevOps tools and practices, teams gain the ability to better respond to customer needs, increase confidence in the applications they build, and meet business goals faster.

Along with cultural change, there is a huge movement in the market that is changing the way we look at development practices. One of the books that best details this evolution is Accelerate from Nicole Forsgren.

4 Metrics You Must Track

Cycle Time
Cycle Time is the time between the moment the task is considered “in progress” until the moment it enters its final state.

Both Cycle Time and Lead Time are key Lean metrics and represent the time it takes for something to go through your development process and be put into production. Not only the total, but the parts of Cycle Time are important to point out in each team what is the biggest bottleneck.

In addition, a shorter Cycle Time allows us to receive earlier feedback on what we are building and analyze if there is a need to change the focus of the product.

Deployment Frequency
One of the keys to high performance in the Toyota Production system is the ability to reduce the batch (batch) of what is being worked, thus reducing cycle time, flow variability, speeding up feedback, and reducing risks. However, in software, the batch size is complex to measure as there is no visible inventory.

That’s why we use a proxy metric, which indicates that we are storing small “commits batches”, in this case, the Deploy Frequency. The higher the deployment frequency, the lower the chance of “storing” an improvement or correction, and the sooner we send what is already developed to the client.

Time to Merge
Once there is a PR (Pull Request) stalled, very possibly we have a fix or improvement that could be in a user’s hand and that is stalled waiting for someone to revise it and then merge or return for a fix.

Therefore, although it can be inferred based on Cycle Time, we prefer to closely monitor the performance of each team.

Code Coverage
Up to this point, we’ve discussed three metrics linked to productivity. However, one of the biggest failures of teams is to increase their productivity at the expense of quality. In the end, this does more harm than good, as you’ll have to fix it after launch.

Healthy code coverage will prevent so much decrease in productivity that fixes will be made after any functionality is released. But it also brings security to each release thus avoiding risks to customer satisfaction or support bottlenecks.

NOTE: Each of these metrics needs to be analyzed based on the temporal evolution of a squad. Each team works at different seniority levels and possibly with a different codebase, so this is not a tool to compare Squad A with Squad B.

Other metrics that you can use

There are other metrics that can be used to measure the quality of the software that has been produced. I personally don’t use them in order not to overload the team with several metrics and make it clearer what we are constantly following.

However, they are an indication if you are looking for other ways to analyze software quality.

1. Mean Time to Recovery — Mean time to recovery from an incident
2. Change failure rate — Failure rate per deploy