In today’s episode, we apply to software engineering the third concept of directing the rider from the book Switch. We point to the destination.
Continuous delivery is a popular software development practice on agile teams. It is about taking a task that was traditionally done both infrequently and in a highly time and effort consuming manner and making that task happen all the time. By setting a goal to deliver frequently, we incentivize the team to speed up and automate away all the little manual steps that most teams tolerate when delivery is a once-a-year or once-a-month activity.
Making continuous delivery a priority for your team is a great example of pointing to a destination, because you can paint a rich, detailed picture of what the right destination looks like. For continuous delivery, or CD as it is often called, this rich picture is the definition of CD itself, as explained by Jez Humble:
Continuous Delivery – The ability to get changes (features, configuration changes, bug fixes, experiments) into production or into the hands of users safely and quickly in a sustainable way.
A software engineer can picture how CD will help them get changes out to production safely and quickly because they’ve seen how long it takes to get through all the manual, repetitive steps today and they’ve seen how many times bugs have slipped through. They can also picture how CD makes this sustainable – how it eliminates the need for weekend and evening heroics in order to get a release out.
A call to action to deliver continuously also avoids using metrics as destinations. Think of which is more compelling to a software engineering team: a call to improve product build times by 50% or a call to eliminate working evenings due to long code compilation times.
The Heaths recommend that your destination passes the Champagne test. In other words, it should be obvious when it is time to celebrate. For continuous delivery, that day is the day that you can finally turn off the manual approval step because your confidence in your Continuous Delivery system has reached a point where you trust it to not allow bugs to reach production. This doesn’t mean you necessarily deploy every change directly to customers as it gets committed. Your customers may only want new deployments on specific intervals. But eliminating the last manual step means there is no longer any undesired reason not to be able to deploy on every commit.
The Heaths also believe that goals should be expressed in terms of outcomes, not in terms of process. A process goal might be something like a goal to achieve 90% code coverage. This doesn’t motivate as well as an outcome-based goal like “No bugs released to production”.
We also learned about the dangers of wishy-washy goals in the previous episodes and how making goals black and white avoids this problem. Jez Humble describes two golden rules of Continuous Delivery that have this attribute:
- Rule 1: Software (trunk) is always deployable.
- Rule 2: Everyone is checking into trunk daily (at least).
These rules are black and white, all or nothing. Builds that fail mean trunk is not deployable so it is very easy to see when rule 1 is broken. Developers checking into their own private branches and only later delivering to trunk infrequently means rule 2 is being broken.
Setting a goal to get to continuous delivery can point your team to an inspiring destination and can inspire your team’s riders to start trying to figure out how to get there. For some teams, this may be difficult. If you aren’t currently practicing unit testing, integration testing, and code review, you will have a long way to go to reach continuous delivery.
But these are all good habits to develop anyway and the inspiring image of continuous delivery in your team’s future can serve as the destination postcard that motivates the adoption of these habits, which will both get you to the destination and improve your team’s efficiency and effectiveness along the way.
I would love to hear what you thought of the article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.
Pingback: Find The Retro Feeling - The K Guy()