If you're aiming to make major improvements to your DevOps and software delivery performance in 2021, I've got a killer recipe for you called The 4x4 Method.
It gives you a step-by-step process to make massive progress with DORA's 4 Key Metrics, by introducing 4 Key Maps that guide your way to better outcomes.
If you've been wondering where to start or how to level up, with a few short workshops in January, the 4x4 Method will set your team into high gear with clarity and confidence.
If you're interested in getting started in the right direction for 2021, book a time to chat through my calendar link: https://zoom.ai/go/visible
Check out the doc attached below or at https://vzbl.io/4x4
Let's start 2021 strong!
It gives you a step-by-step process to make massive progress with DORA's 4 Key Metrics, by introducing 4 Key Maps that guide your way to better outcomes.
If you've been wondering where to start or how to level up, with a few short workshops in January, the 4x4 Method will set your team into high gear with clarity and confidence.
If you're interested in getting started in the right direction for 2021, book a time to chat through my calendar link: https://zoom.ai/go/visible
Check out the doc attached below or at https://vzbl.io/4x4
Let's start 2021 strong!
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 ?