Continuous Delivery is the practice of automating your release pipeline. From code commit to releasing. Without it, shipping fast is difficult and time-consuming, if not impossible. Unfortunately, it is one of those dreams that teams often keep postponing by doing it “manually one more time”. Or management doesn’t want to invest because it would take time away from delivering more features, forgetting that each manual release already costs the team valuable time.
When the promise of Continuous Delivery doesn’t convince others to invest in it, one thing that can help is to turn that promise into something quantifiable. How much money and time can actually be saved by automating your deployment pipeline? This experiment is a great example of how Scrum Masters can use transparency to drive inspection and adaptation.
“How much money and time can actually be saved by automating your deployment pipeline?”
Required skill
This experiment requires some preparation, calculation, and research on the current and desired state of Continuous Delivery.
Impact on survival
Nothing shocks zombies out of their slumber as confronting them with the financial consequences of their decisions.
When the promise of Continuous Delivery doesn’t convince others to invest in it, one thing that can help is to turn that promise into something quantifiable. How much money and time can actually be saved by automating your deployment pipeline?
Steps
To try this experiment, do the following:
- For a typical release, map out your current deployment process on a timeline — both inside and outside your team. Make sure to consider the entire process up to the point when users can interact with it. Which manual tasks does it involve? For example: “Writing release notes”, “Going through the pre-release test procedure”, “Creating a deployment package”, “Performing a backup before deployment” or “Installing packages on the server”. You can either prepare this on your own or do it with the Scrum team.
- If you have the opportunity, time the actual hours that each manual task requires for a few releases. This gives you the most reliable data. Otherwise, ask people to estimate how much time they typically spend on each task.
- Based on the data you collected, calculate the hours that each step takes on average. If more than one person is involved, sum up their hours. Also, sum the total amount of time that is spent on all the manual tasks of a single release. You now have a metric that tells you how much time is potentially wasted on manual work per release.
- When you have data from an actual release, you can also include the time it took to fix bugs, perform rollbacks, and address the re-work that resulted from the release.
- Determine the hourly rate of developers in your organization. If you don’t have access to this information, use an online calculator to translate an average salary to an hourly rate. For most Western countries, an example would be $30/hour. Multiply the hourly rate with the total time of each task as well as the entire release to calculate how much it costs.
- You now have the cost of all the manual work involved in a single release, as well as the time it takes everyone involved. For example, it might take 200 hours to release a new version to production. Or $6.000,- dollars if you use a $30 hourly rate. If your organization releases twelve times a year, this becomes a whopping $72.000,-.
- With the Product Owner, consider the total time spent on manual tasks. Very roughly, how much value could have been delivered if people were able to spend that amount of time on implementing more work from the Product Backlog?
- Convene the people involved and ask them where automation can both reduce the manual effort on the one hand, while also creating time to get more valuable work done. The purpose here is not to automate everything, but to start where the team thinks it is possible and where the gain is the most substantial. Obviously, automating tasks requires investment. And you can now offset that with how much the organization stands to benefit from making that investment.
Our findings
- One knee-jerk response to the high costs of releasing may be to do it less frequently. You can counter this by emphasizing that bundling releases only makes them more risky and expensive as the number of changes — the complexity — increases. By automating parts of your process, you’re effectively enabling your organization to decrease the risk and cost of each subsequent release. That makes automation an investment in your future.
- A side-effect of tedious manual work is that people tend to forego it even though it’s necessary or use shortcuts that lead to additional unintended work. Automated processes don’t get bored and don’t suffer from this limitation. To add this dimension to your calculation, you can estimate how much time is spent after each release on fixing issues that would’ve been prevented if the manual steps were performed as they should.
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.
