alphaspirit - Fotolia

Get started Bring yourself up to speed with our introductory content.

DevOps Research and Assessment team dispels maturity model myths

'Accelerate: The Science of DevOps' examines the hard data to see how current development methodology is really performing. In this excerpt, the focus is on capabilities, not maturity.

In a new book, " Accelerate: The Science of DevOps -- Building and Scaling High Performing Technology Organizations," the DevOps Research and Assessment (DORA) team of Dr. Nicole Forsgren, Jez Humble, and Gene Kim apply their data-driven approach to software development methodology as it currently works. "Accelerate" represents four years of research into how to measure a software team's performance. Dr. Forsgren was the lead researcher for the project and it's the second collaboration between Kim and Humble -- following "The DevOps Handbook."

In this first of two excerpts, the authors examine the disconnect between actual performance and perceived performance and conclude the focus should be on a team's capabilities, rather than how long a company has been attempting DevOps.

Although many organizations have achieved great success with their technology transformations (notable examples include webscale tech giants such as Netflix, Amazon, Google, and Facebook, as well as more traditional large organizations including Capital One, Target, and the US Federal Government's Technology Transformation Service and US Digital Service), there is still a lot of work to be done -- both in the broader industry and within individual organizations. A recent Forrester (Stroud et al. 2017) report found that 31% of the industry is not using practices and principles that are widely considered to be necessary for accelerating technology transformations, such as continuous integration and continuous delivery, Lean practices, and a collaborative culture (i.e., capabilities championed by the DevOps movement). However, we also know that technology and software transformations are imperative in organizations today. A recent Gartner study found that 47% of CEOs face pressure from their board to digitally transform (Panetta 2017).

Jez HumbleJez Humble

Within organizations, technology transformation journeys are at different stages, and reports suggest there is more work to be done than many of us currently believe. Another Forrester report states that DevOps is accelerating technology, but that organizations often overestimate their progress (Klavens et al. 2017). Furthermore, the report points out that executives are especially prone to overestimating their progress when compared to those who are actually doing the work.

These findings about the disconnect between executive and practitioner estimates of DevOps maturity highlight two considerations that are often missed by leaders. First, if we assume the estimates of DevOps maturity or capabilities from practitioners are more accurate -- because they are closer to the work -- the potential for value delivery and growth within organizations is much greater than executives currently realize. Second, the disconnect makes clear the need to measure DevOps capabilities accurately and to communicate these measurement results to leaders, who can use them to make decisions and inform strategy about their organization's technology posture.

Focus on capabilities, not maturity

Nicole ForsgrenDr. Nicole Forsgren

Technology leaders need to deliver software quickly and reliably to win in the market. For many companies, this requires significant changes to the way we deliver software. The key to successful change is measuring and understanding the right things with a focus on capabilities -- not on maturity.

While maturity models are very popular in the industry, we cannot stress enough that maturity models are not the appropriate tool to use or mindset to have. Instead, shifting to a capabilities model of measurement is essential for organizations wanting to accelerate software delivery. This is due to four factors.

First, maturity models focus on helping an organization "arrive" at a mature state and then declare themselves done with their journey, whereas technology transformations should follow a continuous improvement paradigm. Alternatively, capability models focus on helping an organization continually improve and progress, realizing that the technological and business landscape is everchanging. The most innovative companies and highest-performing organizations are always striving to be better and never consider themselves "mature" or "done" with their improvement or transformation journey -- and we see this in our research .

Shifting to a capabilities model of measurement is essential for organizations wanting to accelerate software delivery.

Second , maturity models are quite often a "lock-step" or linear formula, prescribing a similar set of technologies, tooling, or capabilities for every set of teams and organizations to progress through. Maturity models assume that "Level 1" and "Level 2" look the same across all teams and organizations, but those of us who work in technology know this is not the case. In contrast, capability models are multidimensional and dynamic, allowing different parts of the organization to take a customized approach to improvement, and focus on capabilities that will give them the most benefit based on their current context and their short- and long-term goals. Teams have their own context, their own systems, their own goals, and their own constraints, and what we should focus on next to accelerate our transformation depends on those things.

Third, capability models focus on key outcomes and how the capabilities, or levers, drive improvement in those outcomes -- that is, they are outcome based. This provides technical leadership with clear direction and strategy on high-level goals (with a focus on capabilities to improve key outcomes). It also enables team leaders and individual contributors to set improvement goals related to the capabilities their team is focusing on for the current time period. Most maturity models simply measure the technical proficiency or tooling install base in an organization without tying it to outcomes. These end up being vanity metrics: while they can be relatively easy to measure, they don't tell us anything about the impact they have on the business.

Fourth, maturity models define a static level of technological, process, and organizational abilities to achieve. They do not take into account the ever-changing nature of the technology and business landscape. Our own research and data have confirmed that the industry is changing: what is good enough and even " highperforming " today is no longer good enough in the next year. In contrast, capability models allow for dynamically changing environments and allow teams and organizations to focus on developing the skills and capabilities needed to remain competitive.

By focusing on a capabilities paradigm, organizations can continuously drive improvement. And by focusing on the right capabilities, organizations can drive improvements in their outcomes, allowing them to develop and deliver software with improved speed and stability. In fact, we see that the highest performers do exactly this, continually reaching for gains year over year and never settling for yesterday's accomplishments.

Download the remainder of the "Accelerate" excerpt.

This was last published in March 2018

Dig Deeper on DevOps and software development

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

The title of this article has a serious typo, so I thought I'd provide the corrected version. A new Nicole Forsgren book on DevOps dispels maturity model myths. There, I fixed it.
Cancel
Why is there a DevOps disconnect between capabilities and maturity?
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchITOperations

SearchMicroservices

TheServerSide.com

SearchDataCenter

Close