Ive found this book very helpful and we have implemented the learnings form it in our organisation.
I particularly like how it "redefines" dev-ops. Many associate it with being able to stand up servers or use new and modern CI tools. But all it really is, is a set of practices that allow devs to operate their systems. Create automated test, easy to deploy and maintain systems, develop the tools to manage those systems, and plug them together. So even a specialised person in the team might be undertaking the tasks of setting up those tools, is the whole team that benefit from it, provided they also do their part (coding, testing, etc).
I also like how it moves away from "vanity metrics" like code coverage for example. What matters is how often you break things, how long it takes you to recover from it, etc.
We had a great experience so far. We noticed a great improvement in the failure rate for example.
We have gone quite far in terms of shaping our processes. We basically shaped a Lean process that meet our needs.
We start with a Roadmap that maps our Product Strategy.
Each Roadmap Item (RMI) is a Feature or Improvement, that we shape and define in terms of what we want to achieve with it.
We then give this RMI to a team member to lead the solution design for it, and we team up to implement it, test it, deploy it, and operate it. We have an end-to-end approach in our team involvement with the work required. No handover across silos (Designer -> Dev -> QA -> Ops), we are all involved the whole time.
This means we have effectively shifted left, or built quality into our process, which reduced the failure rate, and also improved our recovery time.
In terms of release frequency and delivery lead time, we follow a Kanban plus "Release Train" approach. We have a weekly release cycle, that works well for us with the -ever growing- level of test automation. This means that features, fixes, or any work is released within a week of being "ready".
Being "ready" means it is coded correctly, covered by automated test, and most importantly, solves the problem it set to tackle.
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.
Ive found this book very helpful and we have implemented the learnings form it in our organisation.
I particularly like how it "redefines" dev-ops. Many associate it with being able to stand up servers or use new and modern CI tools. But all it really is, is a set of practices that allow devs to operate their systems. Create automated test, easy to deploy and maintain systems, develop the tools to manage those systems, and plug them together. So even a specialised person in the team might be undertaking the tasks of setting up those tools, is the whole team that benefit from it, provided they also do their part (coding, testing, etc).
I also like how it moves away from "vanity metrics" like code coverage for example. What matters is how often you break things, how long it takes you to recover from it, etc.
We are in the process of implementing those, how has been your experience? Have you noticed (or measured) an improvement?
We had a great experience so far. We noticed a great improvement in the failure rate for example.
We have gone quite far in terms of shaping our processes. We basically shaped a Lean process that meet our needs.
We start with a Roadmap that maps our Product Strategy.
Each Roadmap Item (RMI) is a Feature or Improvement, that we shape and define in terms of what we want to achieve with it.
We then give this RMI to a team member to lead the solution design for it, and we team up to implement it, test it, deploy it, and operate it. We have an end-to-end approach in our team involvement with the work required. No handover across silos (Designer -> Dev -> QA -> Ops), we are all involved the whole time.
This means we have effectively shifted left, or built quality into our process, which reduced the failure rate, and also improved our recovery time.
In terms of release frequency and delivery lead time, we follow a Kanban plus "Release Train" approach. We have a weekly release cycle, that works well for us with the -ever growing- level of test automation. This means that features, fixes, or any work is released within a week of being "ready".
Being "ready" means it is coded correctly, covered by automated test, and most importantly, solves the problem it set to tackle.
Hope this helps
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