In the Principles of DevOps, I claimed DevOps will help you:
- Reduce lead time to value
- Deliver changes correctly and accurately
- Reduce time to detect and repair problems
- Improve employee quality of life and retention
- Enable architectural change
But why do those even matter?
They matter because your organization’s software delivery process determines its software delivery performance. And software delivery performance drives organizational performance. Let me connect the dots for you.
In the First Way of DevOps, Systems Thinking, we work to understand the software delivery process, make it repeatable and safe with robust automation, and optimize it by removing low value work. This is DevOps! These delivery process improvements directly improve the software’s:
- Deployment frequency
- Lead time for changes
- Change failure rate
We also monitor how our software runs in production and use feedback to improve it, the Second Way. The combination of operational and delivery improvements improves the software’s time to repair when a problem does occur.
Those four aspects of software delivery and operations fold into what the DevOps Research and Assessment (DORA) group calls Software Delivery Performance.
DORA’s multi-year study found that improving Software Delivery Performance improves Organizational performance. And elite and high performing software delivery organizations don’t outperform by a little, they outperform by 2x or more against their competition.
Better Software Delivery Performance, Better Organizational Performance
DORA, led by Nicole Forsgren, PhD, conducted a rigorous, multi-year study that found Elite and High-performing Software Delivery Organizations outperform their peer organizations with respect to: profitability, market share, and productivity. These conclusions hold across organization size, industry, and regulatory frameworks. The book Accelerate, describes this study in detail (Forsgren, Humble, Kim 2018). The authors summarized Software Delivery Performance and its relationship to Organizational Performance in the State of DevOps Report 2018. Both Accelerate and the State of DevOps Report help us understand the practices that lead to higher software delivery performance that can generate powerful business outcomes.
DORA used advanced cluster analysis statistics to characterize ‘Software Delivery Performance’ for teams and organizations. This analysis searched through the many aspects of software delivery tracked by the research for those that drove improved business outcomes amongst all the surveyed organizations. The key aspects of Software Delivery Performance are:
- Deployment frequency
- Lead time for changes
- Change failure rate
- Time to restore service
DORA’s analysis goes further and describes those aspects in terms of what they look like at organizations of different performance levels: Elite, High, Medium, and Low. This classification system can help you understand where your own organization ranks relative to others.
When an organization deliver changes with high frequency, low lead time, a high change success rate, and restores service quickly when failures occur, it will out-perform its peers in the marketplace over time. This outperformance looks like (Accelerate, excerpt from Appendix B):
- High performers are twice as likely to exceed organizational performance goals as low performers: profitability, productivity, market share, number of customers
- High performers are twice as likely to exceed noncommercial performance goals as low performers: quantity of products/services, operating efficiency, customer satisfaction, quality of products/services, achieving organizational/mission goals
Additionally, high performing organizations deploy with high frequency and low failure rates – these are not in tension.
DORA’s reviewed research and published analysis on the effectiveness of DevOps is amazing. I highly recommend everyone involved in delivery of technical services read their work, especially managers and engineers on delivery and operations teams.
You can start with the State of DevOps Report 2018 and evaluate your own delivery process against the Software Delivery Performance Framework. This evaluation will help you identify areas you can improve that will yield better outcomes for your organization and team.
Improving employee quality of life and retention
Burnout is a common and serious problem in technical organizations. Burnout’s hallmark symptoms are exhaustion, cynicism, and feelings of ineffectiveness. Burnout causes pain at work and home and may result in people leaving the organization. The leading causes of burnout are (Maslach, Leiter 2016):
- Work overload that prevents people from resting or learning new skills to improve their work
- Lack of control (autonomy) in what and how work is done
- Insufficient financial, institutional or social rewards
- An unsupportive or conflict-filled community
- Unfair decisions and decision making processes
- Conflict between the values of the person doing the job and the values practiced by the organization
Let’s address the first two.
DevOps addresses work overload by understanding and optimizing the flow of change (value) through the system. As part of the First Way, practitioners identify the work required to move changes through the system. This work can now be managed and prioritized as discrete elements. The team can focus on the high value work, identify manual operations that can be replaced with safer, robust automated ones, and eliminate low-value work. Further, the team can adopt practices like work-in-progress limits to maximize throughput and provide backpressure on the infinite stream of requests.
People obtain more control over their daily work as their feedback is incorporated into the plan for the team’s day-to-day work and strategic improvement plan. The planning process should reserve 20% of its time to improve the team’s processes for doing its work (or more, if things are in bad shape). These first steps set a foundation for the team to amplify feedback loops (Second Way) and create a culture of experimentation (Third Way) that provides even more autonomy.
Enable Architectural Change
DevOps enables architectural change in several ways, we’ll touch on two here:
- Reuse of Delivery and Operational processes
- The Easy Path is Well Trodden
The components supporting automated delivery and operations of a single application can often be reused or rebuilt quickly to deliver many more applications. Since deployment automation is software, it is subject to the same economics of reuse as other software.
Once software delivery pipelines are easy to build and able to publish changes in small batches, teams will be able to experiment with and refactor the implementation of existing services with reduced risk. This gives people confidence to make architectural changes incrementally and with feedback from production to complement research and design activities.
The same is true for many of the Operations-focused components that monitor, gather feedback (e.g. A/B testing), or manage incidents for deployed applications.
These value of delivery and operations the reuse capability is magnified when teams have options for new deployment targets. When a new deployment target is available, the team can carve off one function from an existing monolithic service and deploy that function as its own service.
For example, a web-only ecommerce application might extract the pricing functionality to a standalone service with its own delivery pipeline. The development, delivery, and operations of that pricing service is now decoupled from the original ecommerce application for mostly the marginal cost of increased deployment and operational tooling usage. Now the extracted service can be made available for composition into some other application workflow such as a set of mobile applications. The automation and operational maturity that DevOps can bring to your organization are critical to making this architectural change and avoid building things in the wrong place because it’s the only thing your org knows how to deliver and operate.
Once it becomes easier to extract a function from a larger body and operate it somewhere else, people will start to use that approach of their own volition. I have led architectural transformations with approach a number of times and it works. Be ready with guidelines for when it is and is not appropriate to extract a service.
Summary
The practices of DevOps provide value to organizations by enabling them to change quickly and safely. There is a strong and growing body of work that shows high performing software delivery organizations outperform their peers by 2x or more.
If you’ve experienced success (or failure) with these practices or have questions about how you might apply them, please hit reply or email devops@qualimente.com. I’d love to discuss it with you!
Stephen
#NoDrama
