April 18, 2017

...Learn TDD with Codemanship

20 Dev Metrics - 1. Lead Time to Delivery

On the Codemanship Twitter account, I've started posting a series of daily 'memes' called 20 Metrics for Dev Teams.

These are based on the health check some clients ask me to do to establish where teams are when I first engage with them as a coach. My focus, as a business, is on sustaining the pace of innovation, so these metrics are designed to build a picture of exactly that.

The first metric is, in my experience, the most important in that regard; how long does it take after a customer asks the team for a change to the software before it's delivered in a usable state? This is often referred to as the "lead time" to software delivery.

Software development's a learning process, and in any learning process, the time lag before we get useful feedback has a big impact on how fast we learn. While others may focus on the value delivered in each drop, the reality is that "value" is very subjective, and impossible to predict i advance. When the customer says "This feature has 10x the value of that feature to my business", it's just an educated guess. We still have to put working software in front of real end users to find out what really has value. Hence, the sooner we can get that feedback, the more we can iterate towards higher value.

This is why Lead Time to Delivery is my number one metric for dev teams.

To measure it, you need to know two things:

1. When did the customer request the change?

2. When did the customer have working software available to use (i.e., tested and deployed) that incorporated the completed change?

Many teams have repositories of completed user stories (e.g., in Jira - yes, I know!) from which this data can be mined historically. Bu the picture can be confusing, as too many teams have woolly definitions of "done". My advice is to start recording these dates explicitly, and to firm up your definition of "done" to mean specifically "successfully in production and in use".

As with weather and climate, what we should be most interested in is the trend of lead time as development progresses.

Sustaining innovation means keep lead times short. The majority of dev teams struggle to achieve this, and as the software grows and the unpaid technical debt piles up, lead times tend to grow. To some extent this is inevitable - entropy gets us all in the end - but our goal is to keep the trend as flat as we can so we can keep delivering and our customer can keep learning their way to success.

Posted 1 week, 2 days ago on April 18, 2017