Being Good at DevOps

Based on experience, four years of research and analysis of 23,000 survey responses, Nicole Forsgren, Jez Humble and Gene Kim deliver practical insights and clear steps in this road map to high performance software delivery. Their evidence and insight cover grooming leaders, using popular methods, like Lean, in software development, and the latitude that DevOps teams need in prioritizing software features. Solid templates, diagrams and vignettes make this manual indispensable for DevOps leaders.

Forsgren, a DevOps entrepreneur, does research and strategy at Google Cloud. Humble, also a researcher, co-wrote The DevOps Handbook, Lean Enterprise, and Continuous Delivery. Gene Kim is an award-winning CTO, researcher and co-author of The Phoenix Project, Beyond The Phoenix Project and The Visible Ops Handbook, and a co-author of The DevOps Handbook. He hosts the DevOps Enterprise Summit conferences.

These three experts believe technical and managerial practices account for how firms fare, although leaders tend to overestimate their firms’ DevOps maturity – the degree of effectiveness in developing and delivering software. In other words, you may not be as good at DevOps as you think you are. Leaders tend to exaggerate their software development capabilities. And, as the authors clarify, even organizations whose core business is not software development rely greatly on technology and software.

Software delivery performance is affected by many factors, including leadership, tools, automation, and a culture of continuous learning and improvement. Nicole Forsgren, Jez Humble and Gene Kim

Like most people, most firms rate themselves above average, which is how reviewers saw this enduring book, as clearly a cut above. Ryn Daniels, author of Effective DevOps, says, “Accelerate does a fantastic job of explaining not only what changes organizations should make to improve their software delivery performance, but also the why, enabling people at all levels to truly understand how to level up their organizations.”

Nevertheless, you might wonder whether the authors should distinguish more between organizations that rely on technology and software versus those whose core business is creating it. This is a meaningful distinction given the ways the whole process of software development and DevOps has changed.

Large labor-intensive, complex projects with long time frames, big budgets and huge teams have given way to quick, small and more manageable development chunks. Small teams – no larger, as Amazon’s Jeff Bezos famously says, than you can feed with two pizzas – stay in close contact with their stakeholders, including customers and end users. 

These teams calibrate their output in response to user feedback. Without these practices – and a corresponding culture of speed, quality, openness, trust and excellent people-management values – software developers can’t compete effectively. This probably holds true for organizations that build software for clients. However, the authors may overstate the importance of trending software development practices in firms that may only adapt off-the-shelf software to suit their needs.

Assessing DevOps Teams

The authors advise against relying on software development “maturity models” as gauges of your progress. After all, when you hit the highest level, you plateau, leaving nothing to improve. Assess your capabilities in terms of continuous improvement, learning and agility.

The key to successful change is measuring and understanding the right things with a focus on capabilities.Forsgren, Humble and Kim

Start by emphasizing and recognizing the right measures. Unless you want inelegant software, don’t measure developers by the number of lines of code they produce. Instead, measure four factors: the lead time it takes to design and deliver a feature; your “deployment frequency,” the pace at which you release new versions of your code; your “mean time to restore,” the time it takes to fix an outage, bug or service break; and your “change fail percentage,” the ratio of the changes you make that need fixing.

The four measures work everywhere, but the authors pose an important caveat: Their metrics work only within an open culture that doesn’t leverage fear or repercussions – a culture that welcomes experimentation and incremental learning. If your culture emphasizes power and fear, your teams won’t provide truthful data with which to measure their work.

Assessing Culture 

Forsgren, Humble and Kim acknowledge the intangible nature of culture and the difficulties in measuring it. They offer the framework for a simple survey and recommend using the Likert scale in conjunction with Westrum’s theory – a model based on cultures with sound information flow. With it, you can determine the degree to which your culture supports excellent DevOps and whether it’s suitable for assessment with the four measures. Westrum’s culture model predicts the quality of DevOps and the overall performance you can expect across the firm. The authors give the impression that virtually every organization must work on its culture before it can start measuring its teams against the four preferred factors. They’re probably right.

Technical Practices 

Build a process of continuous DevOps delivery by emphasizing quality and small, fast chunks of development. The authors suggest automating routine tasks, instituting a Lean or Kata-type process of continuous improvement and adopting universal accountability. Forsgren, Humble and Kim suggest practicing rigorous version control, integrating any new code each day and implementing and automating continuous testing. These changes, say the authors, will lead to a stronger culture imbued with speed, quality, accountability and employee engagement and will produce better software.

Software delivery performance is affected by many factors, including leadership, tools, automation, and a culture of continuous learning and improvement.Forsgren, Humble and Kim

The authors find it matters if your teams can test and implement their own part of the system without relying on any other team or software component. They advise you to make each team and the modules it affects discrete and nondependent. Teams should collaborate, but your system architecture should eliminate dependencies among teams for testing and deployment. They urge you to integrate internal security and other requirements into the daily development process, instead of waiting for pre-implementation reviews. Such practices, the authors promise, will energize your team and help you scale with speed if your other practices are equally professional, including goal setting, modular architecture design, continuous delivery and stellar leadership.

People-Centric Practices

Forsgren, Humble and Kim advise adapting standard software development methods to your particular circumstances and needs. Start by using Lean and agile processes for product development. The authors fear many organizations don’t understand Lean processes even when they adopt them. For example, they fail to build the spirit of Lean into their culture; they might use it in software development while taking months to approve projects. 

The best Lean practices – the hallmarks of top performers – include dividing big projects into short sprints, experimenting with prototypes, gathering customer feedback, making changes and improving all the time. Sprint teams with the latitude to make decisions about what to build – based on customer feedback and experimentation – have better quality user results and speed than teams who must take direction from higher-ups.

Excellent Leadership

The authors acknowledge the critical role of people management in successful DevOps and software development. Their research reveals, for example, that you should choose leaders who create an inclusive, respectful culture; who take the time to attach meaning to work; and who listen to suggestions. Leaders should invest in their employees’ skills and learning, grant them freedom to experiment, and give them wide autonomy with clear accountabilities. Find and encourage leaders who help employees link their own values to those of the firm.

For people to bring their best to work…they need complete faith that their leaders value them.Forsgren, Humble and Kim

Accordingly, Forsgren, Humble and Kim suggest that you help your employees understand and align with the firm’s objectives, mission and values and involve them and their ideas. Diversity without inclusion means nothing. Make sure they understand the bigger picture in how their work reaches customers. Link client feedback to their work. Trust them and give them autonomy and purpose. Commit to, invest in and extend autonomy and trust to your employees. 

Transform Your Capabilities

The authors’ research, data and years of experience suggest that when great technology and technical processes combine with people-centric management tailored to your organization, you win. Don’t try to take a process – whether Lean, Kata or otherwise – off the shelf and drop it into your situation. Apply proven methods and practices as described, and then gradually modify them to your circumstances, industry and culture.

The authors warn against hiring an external consulting firm to manage and lead change for you. Encourage change incrementally, through experimenting and blending processes and best practices. This will reveal the elements of each method that best suit your culture. You’ll benefit along the way as more advanced technology and people practices deliver gain after gain, while continuous learning and improvement set you apart from your competition.