Wow! Congrats for the transformation. Your story is really inspiring!
If you don't mind me asking, how to do you measure "Delivery Lead Time"? Do you look at git commit dates? Do you look at jira/github issue open/close dates?
Thats probably the hardest one to measure. I thought about using git dates for it, but then I realised something.
In the definition it says: how long it takes for code that is "ready" to reach production. And that's the key, when its "ready".
As I mention we work on a Kanban flow with weekly Release Trains. Which means that when the code is "ready" to be released (not necessarily when its written) it will have less than a week before it reaches production.
And since we all work together in a cross functional fashion (ie: no handover of tasks from dev to qa for testing), there usually is no much lead time from when the dev considers its work done until is merged and in the next release train
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow! Congrats for the transformation. Your story is really inspiring!
If you don't mind me asking, how to do you measure "Delivery Lead Time"? Do you look at git commit dates? Do you look at jira/github issue open/close dates?
Thats probably the hardest one to measure. I thought about using git dates for it, but then I realised something.
In the definition it says: how long it takes for code that is "ready" to reach production. And that's the key, when its "ready".
As I mention we work on a Kanban flow with weekly Release Trains. Which means that when the code is "ready" to be released (not necessarily when its written) it will have less than a week before it reaches production.
And since we all work together in a cross functional fashion (ie: no handover of tasks from dev to qa for testing), there usually is no much lead time from when the dev considers its work done until is merged and in the next release train