Are you too busy to improve?
It is interesting that we human beings won’t be happy if the life is same every day, but we are afraid of the changes too. And when a change is introduced, resistance comes in many ways — lack of time, it won’t work here are a few examples of the same.
I’ve heard similar responses when spoken about anything related to Continuous Delivery such as Automated Testing, Test Driven Development, Pairing, Mainline Development etc. I do agree that at times we can read the response as the idea is great, but the current problems may not be resolved with this. Yes, that's true you don’t have to introduce something just because it is great.
This is true for starting with anything habits, say exercising, doesn’t give you instant gratification. Power of Habit talks about the same and Hooked talks about how to apply the psychology of habits to product design.
Persistence and Perseverance
Jez Humble has spoken the topic Continuous Delivery Sounds Great but it Won’t Work Here at multiple conferences. According to Jez, the fundamental reason for not adopting Continuous Delivery is either because of the culture in the organization or because of the rigid architecture.
Fixing either, the culture and/or the architecture, requires persistence and perseverance, the two pillars of continuous improvement. Because the results will be seen only in the long term. So how do you fix it?
Measurement and feedback
The way to make these long term endeavors work is by taking small steps. Similar to how we slice releases and milestones for product development, we need to take small steps towards such improvements. And to persist and persevere on this path, we need enough measurements to give us feedback to see the impact of these small steps.
In case of Continuous Delivery the metrics what need to be measured are:
- Deployment Frequency
- Lead time [from commit to production]
- Mean time to Recovery (MTTR)
- Change Failure Rate
The first two are the throughput metrics and the last two are the stability metrics. That means:
- Optimise for frequent and faster deploys by helping the code move in a smooth fashion through the build pipeline
- Optimise for fixing things faster when something goes wrong in production and also reduce the number of failures due to the changes introduced
It means that the team always tries to move faster because they are confident about fixing things when something goes wrong.
Measuring Continuous Delivery by Steve Smith talks about how do you create enough feedback systems to measure the impact of Continuous Delivery.
But again, it is not easy. All these require focus and hard work, but things are not easier if we don’t do it. Take small steps, measure on a consistent basis, say in every week or so. Don’t expect huge improvements immediately, but eventually these will have a huge impact.
So where do you start? Start by looking at the flow of your product delivery. Where does it get stuck or slows down and why? Ideate and work as a team on how to improve the same, implement it and monitor and move to the next one. A never ending cycle of simple steps.
