How to reduce Change Lead Time

Table of contents
Text Link
October 9, 2021
|
DORA Metrics

How to reduce Change Lead Time

Go from zero to one hundred deploys a day.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

How to reduce Change Lead Time

October 9, 2021
|
3:33
DORA Metrics

Start by setting Sleuth up to track your team's DORA metrics. If you don't know how, watch this video. The investigation starts with the change lead time graph. The first thing to notice is Sleuth is always comparing one period against the previous period. By default, this is 14 days, but we can change it to something else. However, I think for the purpose of this, I'm going to keep it at 14 days, because when I look at this graph, I already see a huge bump, and I want to know why.

If I look up at the top, I can see that the change lead time has gotten worse by 78% over the previous period. That's worth looking into. So, I see this bump, and Sleuth goes beyond just telling me the values but actually breaking it down into buckets. So, I can see that the biggest component of my change lead time is actually my review time. And in fact, it's 134% worse than the previous period. So, let's click on that, and Sleuth will now just graph that bucket over time. And yep, sure enough, the big bump still exists. So, I'm going to zoom in on this big bump to understand what makes it up.

Sleuth will take a look at my deployments and will now order them by which one's contributed to this bump. So, already I can see that the number one contributor to this increased time for review is this change, fix all kinds of rollback and health issues. Well, if that doesn't sound like a big bucket of changes, I don't know what is. And so, my guess is it's a big, messy thing that took a long time to review and sure enough, it seems like it. Sixteen commits, one author, 36 files changed. That's pretty big, so a lot of things happened.

Sleuth take the issue, and all these commits, and put it into a timeline so I can understand how it came to be. The issue was created pretty quickly, a bunch of commits, commits, commits, commits, pull request created, and then commits, commits, commits, until finally it was merged and deployed. So, now I have the context to understand what's making my change lead time the way it is, and I can go talk to the developer about it. Maybe the problem is that we're not breaking tickets down enough. Maybe that we're not putting the right reviewers on the review, or maybe it's just a one off thing that's going to happen. Either way, I now have the context so I can go reach out to that developer and we can work together to try to find a solution.

But let's say you don't want to go through all of that. You want to just go straight to the insight. Well, Sleuth can help you there as well. Instead of going through this whole investigation process, Sleuth also brings out highlights. So, for example, I can see down here under these insights, my review time is higher than my previous period by 134%. Right, let's take a look at that, and boom, there are the deployments that are the biggest contributors and you can see over 500% increase on these ones. It looks like it wasn't just the one from before. Looks like some other ones might be worth taking a look at as well. These insights can be emailed to you on a periodic basis, so you can keep tabs on things without even needing to go to Sleuth.

If you've heard enough and want to know how to set up Sleuth for your team in just about a minute, watch this video. If you want to know what other metrics Sleuth covers, try this video.Does it feel like your team is taking way too long to get a change into production? Where is all the time going? Well, Sleuth can help you find the answers, and I'll show you how.

Go from zero to one hundred deploys a day.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.