Accelerate: A Principle-based DevOps Framework
Here's some of what other, higher-performing DevOps teams might be doing better than yours.
Join the DZone community and get the full member experience.Join For Free
You may also enjoy: Accelerate: Building and Scaling High-Performing Technology Organizations [Review]
Framework #2: Accelerate's Technical and Management Practices of High-Performing DevOps Teams
In Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, authors Nicole Forsgren, Jez Humble, and Gene Kim present research that surfaces the key technical and management practices that high-performing DevOps teams have adopted and continue to refine.
According to Accelerate authors, the technical practices used by high-performing DevOps teams are focused in three key areas:
The Accelerate authors chose to combine several different practices, each important on its own as a discipline, under the umbrella of continuous delivery (CD). Although CD itself is its own principle, keep in mind that high-performing DevOps teams are doing all of these things in concert with one another to achieve a truly exemplary continuous delivery model:
- Version Control
- Deployment automation
- Continuous integration (CI)
- Trunk-based development
- Test automation
- Test data management
- Shift left on security (DevSecOps)
- Continuous delivery (CD)
When it comes to DevOps architecture considerations, the characteristics that most high-performing teams were likely to agree with were the following:
- "We can do most of our testing without requiring an integrated environment."
- "We can and do deploy or release our application independently of other applications/services it depends on."
The Accelerate authors are quick to mention that the type of technology used, no matter how popular, is no guarantee of high performance:
"...employing the latest whizzy microservices architecture deployed on containers is no guarantee of higher performance if you ignore these characteristics."
In fact, the characteristics described above — testability and deployability — are achieved by implementing the following two architectural technical principles of high-performing DevOps teams, as Accelerate authors explain:
- Loosely coupled architecture. “The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams.”
- Empowered teams. “When teams can decide what tools they use, it contributes to software delivery performance, and, in turn, organizational performance.”
Product and Process
High-performing DevOps teams have also embedded the following key principles into their product management processes:
- Customer feedback. Product teams seek out customer feedback early and often throughout the development process.
- Value stream. Product teams understand that continual optimization of their process delivers value to customers faster.
- Working in small batches. Smaller batches of work allows delivering of MVPs, features, and bug fixes sooner, which also helps enable the customer feedback loop above.
- Team experimentation. Teams perform better when they’re allowed to test out new ideas and theories without outside approval.
According to Accelerate authors, the management practices used by high-performing DevOps teams are focused in two key areas:
- Lean Management and Monitoring
Lean Management and Monitoring
In our Why DevOps? article, we discussed how Lean grew out of the need to deliver value to customers faster by identifying and removing waste from a manufacturing process, or (put another way) by reducing lead times through optimization of the value stream.
Some of the key management practices of Lean management and monitoring include:
- Lightweight change approval processes. “Teams that reported no approval process or used peer review achieved higher software delivery performance…teams that required approval by an external body achieved lower performance.” (Accelerate)
- Monitoring. Use data from monitoring tools used for applications and infrastructure to inform daily decision-making.
- Work in Progress (WIP) limits. Keep teams efficient and focused, increasing throughput, by minimizing the different projects in process for a particular team at a given time.
- Visualizing work. Make use of a Kanban board or similar method to show work moving through development stages.
Accelerate authors discuss Westrum's generative (performance-based) organizational culture as one where "information flows unimpeded and drives better software delivery performance and, ultimately, organizational performance."
Some of the key management practices around culture include:
- Supporting learning. Leaders should “set the tone” for a learning culture in the organization and build it into the day-to-day tasks.
- Collaboration among teams. Encouraging cross-functional teams and collaborative projects and methods will help foster that “all in this together” cultural shift.
- Job satisfaction. Providing your teams with the right tools and resources to do their work is key to job satisfaction among employees, as well as minimizing the inevitable burnout from complicated deployments and manual tasks.
- Transformational leadership. Having a vision, communicating in a motivating and inspiring way, enabling intellectual stimulation, embodying supportive leadership, and providing personal recognition are all characteristics of a transformational leader.
Next, we'll look at The CALMS (Culture, Automation, Lean, Measurement, Sharing) framework for assessing DevOps.This post was originally published as aSonatype Guide, a part of our Sonatype Community. The Sonatype Community is a place where you can ask questions to other Nexus users and the Sonatype team. It also provides content and learning paths from a team of experts that help make using Nexus even easier. If you haven't spent time there, I definitely recommend it.
Published at DZone with permission of Ember DeBoer, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.