I am especially excited to share with you the next seven blog posts, which are based on seven strategies to measure value and software from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) Of Your Software. You can find the original post that summarizes the seven strategies here https://tobeagile.com/seven-strategies-for-measuring-value-in-software/.
I’m often asked what are the most valuable metrics to track on a team. In my experience, teams either don’t track any metrics or they track way too many metrics and wind up getting overwhelmed with the data.
I find that it’s best just to track 2 to 4 metrics, but which metrics you track really depends upon where your focus is and where your development process is at.
In these next seven blog posts I will propose seven different metrics to track but you don’t have to track them all and if you try it can be an awfully big burden. Instead pick a couple that makes sense and go with that.
The first metric that I’d like to discuss I feel is the most important. If you’re going to track something then track this because it is most representative of the value that a software development team creates. It’s where you’ll see the biggest impact for improvements.
The metric that I’m referring to is time-to-value. What I mean by time-to-value is how long does it take from the time a feature is requested to when that feature is delivered and the customer is deriving value from it. For some teams it makes more sense to measure time-to-value as how long did it take from the time we started to develop the feature until the customer was deriving value from it. The former way of measuring time-to-value includes the time it takes for a request in the system two be started. Some organizations find this valuable to track while others have inflexible requirements processes and they’re more interested in focusing on just the development process so they measure time-to-value based on when a feature is started in development to when the customer begins to derive value from it.
Time-to-value, regardless of how you define it, avoids the major trap when collecting performance data, which is local optimization. Focusing on optimizing just a part of our software development process is often useless in the long run if it doesn’t speed up the entire process. If there are five sequential steps in a process and step three is optimized but step four is not designed to handle the additional flow from step three then the overall workflow has not been improved.
Local optimizations seemed good on paper but they end up providing very little value. I would say this is the number one trap that I see managers get into when they look at ways of improving their software development process. We have to find ways of improving the overall process in order for us to derive value out of individual process improvements. Focusing on time-to-value helps us focus on the right things, which is the overall flow of our development process. When we can find ways of improving this then we see big results come out.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Why Practice 2: Build in Small Batches
Next Post: Measure Time Spent Coding »