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”.
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%. :)
In short, aim for:
- Continuous deployment on the testing environment
- Continuous delivery on the staging environment
- Continuous delivery on the production environment