Continuous Delivery saves the day

Posted by Grace on Jan 6, 2022

Header image source: Superman Movie

This week I read Accelerate: The Science of DevOps, a book by a team that believes deeply in the ability of technology to measure and improve the performance of teams. Through deep research, Dr. Forsgren and Jez Humble have shown specific metrics teams can use to increase their work profitability and important but less tangible metrics like customer satisfaction and efficiency. The authors’ philosophy on Devops was solid and unmistakable. The book repeats the point “go slow to go fast,” which means that Teams should use all of the modern continuous integration tools available to them, including version control (of course), continuous integration, and deployment automation. In addition, trunk-based development, where branches are only open for a day maximum and constantly merge into the main. Furthermore, developers minimize code conflicts by continuously merging into the trunk and won’t be in merge conflict gridlock. Consistent with the 8th Light philosophy, the authors also espouse test automation. However, teams must pay specific attention to test data management to automate tests, which goes hand-in-hand with their suggestion for Continuous Delivery. Continuous Delivery or CD means that code should always be in a deployable state. The authors are strong advocates for an agile model where small slices of work are delivered every week. Teams need to be allowed to choose the tools that work best for them. The authors believe that empowered teams work faster and better than management unilaterally imposing tech stack choices upon the developers. Enabling development teams to choose their tech stack also supports their management philosophy to support a “generative culture.” A hallmark of the desired culture is where all team members feel safe speaking honestly, expressing their opinions, and cooperating with other team members. The author believes that a loosely coupled architecture on the software will reduce dependency between teams. There will be a more relaxed and friendly company culture when teams no longer frantically chase each other down to get unblocked on tasks. It’s also essential to the authors that employees not get burned out, which is the social equivalent of a server crashing - hugely disruptive and catastrophic to productivity. The authors also espouse using modern technology such as work visualization and dashboards to help developers and managers understand where they seek their goals and communicate with customers more clearly. There are multiple benefits when the workflow is legible to everyone involved and measured with clear metrics. Teams can be proactive about monitoring the health of their software. They can make business decisions using these metrics. They can also use these more granular metrics to keep the amount of works-in-progress low (to avoid future complexity). These efforts are part of the Lean Delivery philosophy. Overall, this book is a well-researched and comprehensive vision of how organizations elevate their results. By combining a turnkey automated approach to architecture and high-trust, positive employee environments, teams can avoid disaster and “go slow to go fast.” The benefits of the techniques in this book are evident and lead to lower stress, happier customers, and faster delivery.