Software metrics that actually work!

What is missing?

If you are like me, then you may have the feeling that something is missing between software development teams and the rest of the business. You may feel the pressure from different departments with different deadlines, metrics, and KPIs. The feeling of always lagging behind, and often having to cut corners in the development process.

As a product owner, project manager, or Scrum master you may have encountered the inevitable conflict between upper management’s need for reports and software metrics and the nature of agile and iterative software development.

Complexity for complexities own sake

I have often encountered that the attempt to add software metrics and KPIs for software development ends up with useless KPIs. They are not updated, and they are only there to satisfy a requirement from upper management. The real focus for the team is the development and the features ahead with deadlines that we are notoriously not meeting. When things go well then we deliver the features in a sprint. But we still have a gap between the reality of agile development teams and the rest of the company.

A whole other chapter is what we, in software development, call legacy code. That is code that is introduced due to multiple factors but often time pressure. Most developers will know that if we continue down the path of legacy then we will end up in a dead-end where the only solution is to start over. But how do we find the right balance between new features and securing progress in the project while you take care of the legacy in time?

All these examples are symptoms of a bigger gap between business and software development. We need a common language that will connect business processes with agile software development. We need software metrics that can show if we are blocked by legacy or if we have other bottlenecks. More on that later, but let’s first take a look at the root cause of this problem.

Connecting business and development

For years most companies had an IT department that took care of all IT-related matters. This has grown to an extent where some IT departments are doing it all. They are both fixing computers, making sure networks are working, and taking care of all internal software development. Furthermore, the need for software solutions has skyrocketed. Many companies are now delivering IT services along with whatever other products they are selling.

What used to be a fairly simple landscape with a few people is now large departments dealing with complex solutions. Both you and I know, that the complexity of software development is the reason many chose to switch to more agile and iterative processes.

So why is it interesting to take a look at what was? Well, it has to do with why there is a discrepancy between IT and traditional software metrics and the rest of the organization.

Management demand software metrics

With many, more solutions come many more stakeholders. And with IT becoming a big part of what’s being sold so increases the focus on IT for upper management. When IT makes its way into strategic company planning then it’s natural to see that upper management gets more involved. They are much more aware of the development and rather certain projects are on track or not.

I can’t give you any magic sauce that solves the problem and immediately bridges the gap between IT and business. What I can give you is a way that will connect the agile world with the more traditional business. The goal is to make communication between stakeholders much easier. The solution is, in my opinion, based on a practice that has been used in medicine for years and what is now known as evidence-based. In this case, we call it Evidence-Based management (EBM). If you stick with me through this blog post then I promise you some software metrics that will make a lot more sense. We will try to connect business and IT in a way that I at least haven’t been used to before.

Let’s start with the common ground between all employees in the company – creating value.

What is value and how is that connected to software metrics?

“Well hold on a second” you may say. Creating value is great, but what is value, and is my definition the same as the users, the product owners, the salespersons, and so on?

I’m glad you are pointing this out. Value is dependent on the eyes who see it. But what matters most, in the end, is what value we can create and what value we are already creating that makes the users happy. For a software product, the end-user should always be the one in focus. This requires that our goals and software metrics are also focused on that. And as an added benefit then that will make upper management and most stakeholders happy as well.

EBM defines value by four areas called key-value areas. The four areas a grouped into Market Value and Organizational Ability. More on that in a moment.

Let’s have a look at the value our software products generate.

Market Value

At the core, we only need to look at what EBM calls “Market Value”. This is the value your product is creating in the market. This is the reason your customer chooses you and not your competitors. The reason they stick with you and the reason they may come back and buy even more. I know what you are thinking – value is a very soft area and dependent on the user’s perception. How on earth would we find good software metrics in this area?

Luckily EBM has tried to come up with a solution for that. They split value into the value we haven’t realized yet and the current value we are providing for the customers/users.

Source: https://www.scrum.org/resources/evidence-based-management-guide

Current Value

This value is the value already provided to users and stakeholders. It makes sense to measure what makes the users happy with the current product/service and what their current satisfaction level is.

Organizational Capability

This chapter contains the two value areas Ability to Innovate and Time to Market. The area describes how effective the organization is at delivering the value measured in the previous chapter. Who doesn’t want to be innovative? So, let’s start with that.

Source: https://www.scrum.org/resources/evidence-based-management-guide

Time to Market

Time to market is not to be confused with the ability to innovate even though they are related. The time to market software metrics shows how long it takes to respond to new changes. This could be due to bottlenecks in testing, very long release cycles, or a complicated deployment process. Even the release itself may be causing some delays or adding a lot of time to the time to market.

How do I implement those new software metrics?

This is, in my experience, a new mindset in many organizations and we need to respect, that changes in mindset may take a while. When that is said though, then getting started with measuring some of these KPIs may not be as hard as you may think.

A lot of data related to customer satisfaction is already measured. Market share may also be something that is already in focus. Other things like time to market can be measured by utilizing data from a project management tool like Jira or Azure DevOps. The most valuable features can be found by looking at what gets used the most in the system along with some interviews.

Collecting all this data in a single place that is easily accessible for both the agile teams and upper management is crucial. That along with a fast update frequency on the data is important.

And how do you do this you may ask? Well, you’ve come to the website of a company that is experts in just that. Take a look around the website to explore some of the cool features we have in Cobraid Deploy. Also, don’t be afraid to reach out to me if you have any questions. I’ll be happy to help you, customer or not.

Endnote

And with that, we came to the end of this very long blog post. Thank you for sticking to the end. I hope you learned something from it.

If you want to dive even further into this topic then definitely check out scrum.org. I’ve learned a lot from their Evidence-Based Management Guide. You can download it here for free.

I also did a podcast on this topic with some very talented people. I’ll recommend that as well if you understand Danish.