Delivering Value, Not Just Code: The Right Measures for Success

To measure success and productivity lot of us use the following techniques

1.??????? Measuring productivity by lines of code

2.??????? Measuring productivity by velocity

As a leader, we should focus on outcomes, not outputs.

Measuring performance based on lines of code produces bloated software which is hard to maintain in future. Once developers know that the number of lines a criteria to measure their success, they will write excessive comments, extensive defensive statements, and unwarranted condition checking which will increase the cyclomatic complexity of the code.

A developer’s mind is trained to fix something by writing some additional lines of code. However looking at the broader picture, why it can’t be fixed by removing some lines of code or how can other systems or component can change their behaviour?

Let me give you an example, during a code review I found that the developer had introduced a piece of code to reduce the size of images. When I asked the reason for it, developer’s response was that during batch processing an image processing failed because it was in MBs.

We discussed this with the PO during our standup and the client agreed that this was their mistake and they will ensure that we always get compressed images. On the coding part, we made sure that if image processing failed, we logged it with sufficient data and moved to the next item.

This is not a developer’s fault, but it requires a cultural shift. If the number of lines is a measure of success, this excessive line of codes will always be part of the system.

Measuring performance by Sprint Velocity

The amount of successful work done by the team in a sprint is called sprint velocity. When velocity is used as a productivity measure, teams predictably work to game their velocity. They inflate their estimates and focus on completing as many stories as possible at the expense of collaboration with other teams.

So what are the right measures?

Authors of "ACCELERATE", Nikole Forsegren, Jez and Gene think that we should focus on organizational outcomes, not individual outputs.

Rewarding someone who looks cool but contributes towards completing an organization goal is better than who looks busy the entire day but progresses slowly towards organizational goals.

In software development, there are four verticals, which should be measured.

Lead Time, Deployment Frequency, Mean time to restore and Change fail percentage.

?

Lead time

Lead time is the time it takes to go from a customer requesting the request to being satisfied. There are two parts to it. Design and Delivery. While we have little control over the design part, the delivery part can be expedited. This is where agile rocks and shorter release cycles ensure that we are delivering fast.

Deployment Frequency

In production companies, they use batch sizes but as software is not a material thing, we measure it via deployments. By “deployment” we mean a software deployment to production.

MTTR (Mean time to restore)

In today's software, things are always changing and problems happen. The important thing is how fast we can fix the problem and get things working again. Having a clear plan in place helps us quickly undo the changes that caused the issue.

Change fail percentage

Another important measure to track is how often changes we make to the system cause problems. If something goes wrong, we need to figure out why - was it a setting change (configuration), a change to the underlying system (infrastructure), or something else entirely?

According to JIT. A "good" Change Failure Rate (CFR) depends on various factors, including the size and complexity of the IT system, the level of risk associated with changes, and the company's overall goals and objectives. However, as a general rule, organizations strive to keep their CFR as low as possible, ideally less than 5%.

Summary

Just counting lines of code or how many tasks a team finishes (sprint velocity) isn't the best way to measure success. It can lead to making things more complicated than they need to be. Instead, we should look at the bigger picture and see how our work affects the whole company.

There are better ways to track progress. We can see how long it takes to get things done (lead time), how often we release updates (deployment frequency), how quickly we fix problems (mean time to restore), and how often changes cause issues (change fail percentage). This information helps us find areas for improvement, work together better, and ultimately create software that's not just useful, but also easy to maintain, reliable, and able to grow as needed. By focusing on what we achieve, not just what we produce, we can give our teams the freedom to build great software

?

?Hi, in case we are meeting for the first time, my name is Shantanu and I may have some other good reads for you. Checkout my LinkedIn profile

https://www.dhirubhai.net/pulse/you-overspending-internet-bills-heres-how-find-out-shantanu-shukla/