As technical resources, we get as excited about a new tool or technology as a carpenter does with a shiny new table saw. However, I am less interested in the tools used to build my new cabinet as I am in whether it functions properly and looks good in my bathroom.
Similarly, organizational leaders are more interested in the outcomes driven by DevOps than what is behind the curtain. DevOps has gained momentum because it enables organizations to “build better software, faster”.
And as the culture, principles, and organizational tenants of DevOps are applied across other technology teams – not only software development – this can translate into “build better stuff, faster”.
Measuring Outcomes
If you are looking for metrics by which to measure DevOps outcomes then I highly recommend the book “Accelerate: The Science of Lean Software and DevOps” by Nicole Forsgren PhD et al. The researchers for the “Accelerate State of DevOps Report 2019” share their approach to measuring software delivery performance using rigorous statistical methods. Surprising, they discovered that high-performance can be predicted with only four key metrics:
- Lead Time (length of the development cycle from start to production)
- Deployment Frequency (for software updates)
- Mean Time To Restore (MTTR) (after a service incident or outage)
- Change Fail Percentage (when making a change to production)
While there are certainly other metrics that organizations use, the researchers found a clear correlation between these particular metrics and high performing organizations. And while other metrics may be interesting, they are not needed to prove operational excellence. Conversely, if your organization or team performs poorly on these metrics it does not matter which other metrics you are knocking out of the park, you are probably not where you would like to be.
Even more interestingly, the research also showed that there was no significant correlation between system type and delivery performance – that with the right architectural characteristics (testability and deployability) high performance is possible even for packaged software and “legacy” systems.
DevOps Principles and Practices
Lean and Agile are software development methodologies that you often encounter in DevOps. Lean has a set of principles that originated in manufacturing and focus on reducing waste and optimizing the whole. Agile shares a similar goal (to deliver higher quality software more quickly) and encompasses Lean and additional methodologies and principles. And DevOps encompasses all of these and applies them to the operational aspects of technology as well as software delivery. Therefore, DevOps often incorporates principles and processes originating in these development methodologies, as well as some new ones.
While I am eager to talk about tools and technology – and will in my next post – I first want to draw the connection between a few of the major DevOps Principles and the DevOps Practices these tools support – and to tie these back to the outcomes that we are striving for.
Outcome | Principle | Practice |
Reduce failures and time to recovery | Collaborative Environment | § Shift Left
§ Dev & Ops as one autonomous team § Shared responsibility |
Better quality software and services | Optimize for Quality | § Continuous Integration
§ Continuous Delivery § Incremental Releases |
Faster, more consistent, service delivery | Relentless Automation | § Immutable Infrastructure
§ Automated Provisioning § Test Automation |
Reduce unplanned work, focus on value | Continuous Improvement | § Meaningful Measurement
§ Act on key metrics § Shortened feedback loop |
Deliver customer-centric solutions | Focus on Customer Outcomes | § Service Owner
§ Self-service § Smaller, more frequent updates |
Rapid innovation | Foster Experimentation | § Fail Fast |
The DevOps Loop
The DevOps Loop perfectly illustrates the infinite process of collaboration, iteration, and feedback between the development and operational phases of the software or product lifecycle. This loop is so central to the DevOps philosophy that vendors map their solutions to it, which I will explore when I finally get to talk about technology in the next post.
The DevOps Journey
DevOps is a journey, and few organizations have it all figured out or have applied all of the concepts and processes to all of their teams. Like the DevOps loop itself, adoption will be a set of frequent, iterative changes, measurements, and feedback while your organization and teams determine what works best for them. With the right support from leadership – support for the cultural aspects discussed in DevOps Culture – and encouragement for your teams as they evolve and grow, your teams can break out of the cycle of reactive firefighting, replacing it with a much more positive cycle that builds agility and innovation into the core of everything they do.
Other Posts in this Series:
DevOps #1: Where Are We and How Did We Get Here? | May, 2020 |
DevOps #2: Innovators and Outcomes – The Disrupters | May, 2020 |
DevOps #3: Early Adopters and Outcomes – The Disruptees | June, 2020 |
DevOps #4: Culture – Collaboration, Empowerment, Autonomy | June, 2020 |
DevOps #5: Devopsdays – DevOps Culture Embodied | July, 2020 |
DevOps #6: Principles and Outcomes | August, 2020 |
DevOps #7: Technology – The DevOps Toolchain | August, 2020 |
DevOps #8: Continuous Everything | September, 2020 |