Hi Steve,
Question on how you understand the 4Key Lead Time metric.

You have a note on the Lead Time metric.
This is not true lead time, rather lead time in the subcontext of software delivery.

The 4keys metric is quite different in my opinion.

Lead Time for changes — the average amount of time it takes from the time code is checked in to the version control system to the point in time where it is deployed to production.

I understand it as an approximation of classic Lead Time, i.e., if you consider a good Scrum team able to deploy to production every Sprint. Let’s say they commit every day of the Sprint and deploy to production at the end of the Sprint. Then their Lead Time for changes is half the sprint duration provided a regular distribution of commits, i.e. a good approximation of classic Lead Time from 'feature' implementation started to being used in production.

But I also understand it as a way to drive Continuous Deployment, i.e., Elite performers deploy to production every day what they just committed. That metric is no longer a good approximation of classic Lead Time because I expect it will take multiple days to assemble and enable a 'feature' in production, i.e. each commit deployed in production is not necessarily providing immediate additional Business Value.

Now my problem, the more the team improves, the less the metric matches classic Lead Time.

I can see the metric works well and is simple to implement but it creates confusion ?

Brice Beard good catch! This is exactly the problem the warning is aimed to address :]

Any definition of lead time that's not true lead time will lead to a micro-optimization and cause a team to miss true constraints.

Much like an incomplete definition of done will lead to gaps in execution or delivery. If you focus on a narrow definition of lead time, you'll drive that metric down and ignore a constraint elsewhere that could be actually exacerbated by your improvements (e.g. classical agile without DevOps).

Steve Pereira, in your experience is the Dora lead time enough to drive improvements ( with the 3 others ). Clearly, it has the advantage of being relatively simple to calculate .. but it does suffer, even considering only "Development Lead Time", from being only an approximation of development work started to used in production.

Brice Beard unfortunately lead time doesn't give you enough information to improve without more data to inspect what's impacting it. It can show you how you're trending over time with sufficient history and seasonality context. It can also show you when assumed 'time to market' isn't reality. Development lead time is even less useful in isolation because it only reveals a portion of the true value stream performance. That being said, if we're not happy with lead time or how it's trending, it can trigger a value stream mapping exercise that will reveal true improvement opportunities.

The fact that it's only an approximation is less of an issue than it may seem in practice. Usually the resolution doesn't affect insight. If we have a lead time of 8 weeks, even if it's a week off, we only need to know enough to dig deeper in the right place. Even once we map the value stream, the resolution detail is only a challenge when we have a tie to break or we suspect we're way off. Usually what happens is you find opportunity A at 2 weeks, and B at 1 week, even if A is really 15 days and B is 10 days, it's still clear that A should be the primary focus.

Thanks Steve Pereira ! Looks like your view is that the fact the 4 Keys 'Lead Time For Change' is an approximation for Development Lead Time is not a major issue by itself. That's my impression as well but I have not seen in practice yet :-)

Brice Beard it's definitely less important than proper outcome definition. Nothing helps define the right measurement than a clear outcome, and then analyzing the related current state.