You lose 20% of budget through a lack of continuous deployment.

There is a book called Accelerate: The Science of Lean Software and DevOps, which outlines a several-year-old study of DevOps culture, analyzing 23,000 surveys from over 2000 organizations. It clusters organizations into categories of high-, mid-, and low-performers.

If you are a large firm that is not supported by the technologies highlighted in this report, you are likely to fail.

How to be the fastest?

In 2017, the DORA research team found that high performers executed 46 times more code deployments, and had a lead time, from commit to deploy, that was 440 times faster. The mean time to recover from downtime that was 170 times faster and the change failure rate was 5 times lower.

Continuous deployment is a scenario in which everything that appears in the branch master is immediately deployed to production. For the purposes of this article, we can assume that everything from the branch master/develop goes to the test environment. This technique is particularly significant for non-technical topics, including project management.

The research discusses several points, including:

Software delivery has a key influence on the organizational culture of non-IT firms (our clients!)
Without Lean, Agile, and DevOps we are out in the field
CD increases the motivation of development teams (e.g. more regular gratification from successes)
It increases co-operation within the team (e.g. the need to maintain a “deployed” standard of the branch master/develop)
It lowers the risk of future deployments, so-called “deployment pain” a seminal DevOps presentation from 2009 declares “let’s deploy 10 times a day”).

This seminal DevOps presentation by John Allspaw and Paul Hammond from 2009 declares “let’s deploy 10 times a day”.

John Allspaw and Paul Hammond speaking at Velocity 09

What happens if you don’t have continuous deployment in the test environment?

Motivation and feelings of responsibility among project specialists will be significantly lower
It creates a risk that you develop an annual project for 6 months and then nothing works
It negatively influences budgets, as we can estimate that a large project costs 20% more without continuous deployment
You have to take developers at their word when they say “the code is okay”
What’s worse, developers have to trust their leader when he says “the code is okay”
Going live is a real challenge

Insights from the book ‘Accelerate’ for PMs

If your team is spending more than one hour per week on deployments, that is a bad result
If you deploy more rarely than once a week, that is a really bad result
If you don’t know the techniques outlined in Accelerate, you don’t know how to program in 2020.

What does continuous deployment in a test environment give you as a PM?

You’ll be able to enter the test environment and get a handle on the status of the project at any given moment
You reduce the budget for development, testing, and deployment
You increase the motivation and responsibility of your Development Team

Where does the +20% of budget figure come from?

Lean has 8 areas of wastage. In the software development world, waste can be manually moving a new version of an application to production or a testing environment. If we don’t have continuous delivery/deployment, specialists will have to perform such tasks manually, each and every time. This means that:

Testers wait longer for a usable testing version
Programmers are forced to communicate times/days/hours/resources for deployment. And there will be the inevitable questions about if and when things are being released
A non-automated deployment process, with manual deployments, leads to errors
We most likely decide to deploy less often, meaning that cycle time is longer and client feedback is rarely received. It takes more time to find out about issues and errors
There is a greater probability that our main repository branch code will not be maintained to a “developer’s” level and we will need to periodically remove the accumulated errors
The people responsible for deployment become knowledge silos for that activity. It creates the so-called “bus factor” in which one piece of knowledge is not spread among several people
The WAITING FOR DEPLOYMENT column on the kanban board becomes a bottleneck upon which we most probably do not set a work-in-progress limit
The IN PROGRESS task list grows as a result of the queue for deployment, creating a need to return to such tasks when we come to perform deployment. The cost of switching between contexts as we undertake different tasks therefore grows

Imagine all of this on a weekly basis and it is easy to see how costs can increase by +20%. :)