- The choice of metrics (Key Performance Indicators) to measure the success and results of a remote tech team requires considerable reflection and care to be in tune with the company’s specific objectives (Objectives and Key Results ).
- There are at least fifteen objective metrics that you should continually monitor on your remote tech team to improve production processes and productive environments.
- Improvements to process metrics, security metrics, code quality metrics, and quality testing metrics do not guarantee that your customer satisfaction levels will increase right the way, but they will put you on the right track.
- When we understand each objective’s business value, we can start asking the right questions that will lead us to value-based for improving results.
- However, these metrics are not build to answer questions about how many code lines are written per hour? Or many hours a developer spends on the computer?
- This article focus on the specific metrics that each software development team should start using to improve their performance.
The choice of metrics (Key Performance Indicators) to measure the success of a remote tech team requires considerable reflection and care to be in tune with the company’s specific objectives (Objectives and Key Results ). Metrics must answer questions like: is our software build with quality? Are we meeting the release dates for each project? How many errors are there for every 1000 API invocations? Among others. However, these metrics are not build to answer questions about how many code lines are written per hour? Or how many hours of activity does a developer have in front of the computer?
This article will focus on the specific metrics that each remote tech team should start using to improve their performance.
Recommended read: The Ultimate Guide to Build and Scale a Tech Team in Mexico
Start by measuring the right things.
Here are fifteen objective metrics (bulleted) that you should continually monitor on your remote tech team to improve production processes and productive environments. Improvements to these metrics do not guarantee that your customer satisfaction levels will increase, but they will put you on the right track. In a section at the end of this article, “Putting it all together,” you’ll see why.
Process metrics
For agile and lean processes, the basic metrics are time delivery, cycle time, speed of the equipment, and opening /closing rates. These metrics aid planning and inform decisions about process improvement. While they don’t measure success or value-added and have nothing to do with the software’s objective quality, you should measure them anyway.
- Leadtime: how long it takes to get from idea to delivered software. If you want to respond faster to your customers’ demand, work to reduce your delivery time, generally simplifying decision-making, and reducing waiting time. Delivery time includes cycle time.
- Cycle Time: How long does it take you to change your software system and deliver that change to production. Computers that use continuous delivery can have cycle times measured in minutes or even seconds instead of months.
- Team speed: How many software “units” the team usually completes in one iteration (also known as a “sprint”). This number should only be used to plan iterations. Comparing equipment speeds is meaningless because the metric is based on non-objective estimates. Treating speed as a measure of success is not appropriate, and turning a specific speed into a goal distorts its value for estimation and planning.
- Open / Close Rates: How many production issues are reported and closed within a specified period. The general trend matters more than the specific numbers.
When any of these metrics are outside the expected range or trend in alarming directions, don’t assume a cause. Talk with the remote tech team, get the whole story, then let the team decide if there are any concerns and, if so, how to fix it.
You can’t know or assume the root causes of the numbers, but these metrics give you an idea of where they need attention.
Security Metrics
Security is an aspect of software quality that is often overlooked until later (or too late). Security analysis tools can be used in the construction process and more specialized assessments and stress tests.
Quality metrics are generally related to the number of errors. The full range of security practices and related metrics are more than we can cover today in this article, but like agile process metrics and production metrics, there are a few specific metrics that can go a long way toward overall satisfaction for Your clients.
- Incidents in development: how many incidents occur during the development stage
- Endpoint incidents: how many endpoints (mobile devices, workstations, etc.) have been affected during a given period.
- MTTR (Average Repair Time): for security metrics, this is the time between the discovery of a security breach and an implemented working solution. If the value of MTTR decreases over time, developers become more effective in understanding security issues, such as bugs and how to fix them.
You can find more ways to apply security metrics to software development in the articles Application Security for Agile Projects and Security Threat Models: An Agile Introduction.
Quality Testing Metrics
Quality Testing KPIs demonstrate the maturity and production readiness of the software. It also establishes quality control for the remote tech team minimizing software errors and contributes to high-quality software releases.
- Test Coverage: Test coverage shows the percentage of software requirements covered with test cases. Maintaining high test coverage improves software compliance with requirements specifications.
- Defects found during User Acceptance Testing (UAT): Defects found during UAT reflect the level of software quality before production. If the number of errors discovered during UAT is close to the number of errors found before, the software engineering and testing stages may need improvement.
- Defects found in production: Errors introduced in production can cause loss of revenue by rejecting users from using the software. Therefore, you should make sure to eliminate at least 90% of the errors before launching it.
Code Quality Metrics
Code quality metrics assess the health of the software through automated code reviews. Low KPI values for code quality mean that the code is too complicated and can pose difficulties in expanding functionality and running support activities.
The main code quality metrics are:
- Maintainability index: It is a combination of several parameters, including cyclomatic complexity and average lines of code and computational complexity, based on the Halstead volume function. The maintainability index is a value between 1 and 100.
- Cyclomatic complexity: represents the number of different routes through its code. More simply, it is the number of “if” statements, loops, and change cases in your code. Code with high cyclomatic complexity can be challenging to test and maintain, as there are several different routes through the code that need to be tested. For Cyclomatic Complexity, a low value is good, and a high value is inadequate.
- Inheritance Depth: Indicates the number of different classes that inherit from each other, up to the base class. The higher the number, the greater the depth of inheritance and the higher chance of significantly changing your code by modifying a base class. For inheritance depth, a low value is good, and a high value is defective.
- Class coupling: is a measure of the dependencies that a class has on other classes. The higher this number, the more likely a change in one class will affect other classes. For class coupling, a low value is good, and a high value is bad.
- Code lines: indicates the number of executable lines of code in a method. As expected, the more lines of code there are in your application, the more code you will have to maintain. For lines of code, a low value is good, and a high value is terrible.
Tools like Microsoft Visual Studio automatically calculate these performance indicators.
Putting it all together: success is the ultimate metric.
Companies have goals. The objectives involve a series of tasks that must be quantified to measure progress towards success.
When we understand each objective’s business value, we can start asking the right questions that will lead us to value-based for improving results.
Question = Key Performance Indicators
Answers = Key Results
For example, to improve a payment process in an online store, we may have reached the conjecture that faster payment will generate more sales. But why do we think that? Do many people abandon their shopping carts during the checkout process? If that is the consensus, then the hypothesis for establishing a KPI maybe “We believe that a faster checkout process will result in lower cart abandonment rates, leading to higher sales and better user experience.”
In other words, metrics should only be used to answer questions and test hypotheses that support a specific business objective. And this only should be done as long as the questions and answers help generate positive change.
In some cases, the assumptions may be incorrect, so we must make changes to our KPIs. In other cases, the hypothesis may be correct, so we continue to drive improvements in this area for years.
Five Tips for Effective Use of Metrics
Conditions are continually changing, so instead of summarizing a formula to follow, here are five general rules, to help you maintain focus and flexibility in measuring progress, which they will help you on your journey to business success:
- Metrics can’t tell you the story; only your team can do that.
- Comparing the incomparable is a waste of time.
- You can measure almost anything, but you can’t pay attention to everything.
- Business success metrics drive software improvements, not the other way around.
- Only measure what matters.
