Is the gap between high & low performing IT teams getting wider?

Is the gap between “high performing” and “low performing” IT teams getting wider or narrower?

In my role as CTO at DevOpsGuys I get to meet with a wide range of people from a wide range of companies, at DevOps events and conferences, at business meetings, and in online communities.

One thing that has become very apparent in the 4.5 years since DevOpsGuys was started is that my “gut feeling” of where the average for IT performance is across the industry is wrong — it seems to be a lot worse than what I thought. Having spent 27 years in the IT industry, in a wide range of organisations covering both the private and public sector, this came as a bit of a shock.

Over that time I have seen an explosion in the availability of information on IT best practice, and more importantly the immediacy of that information. When I started in the industry best practice came in the form of printed books that for obvious reasons lagged behind the latest thinking. Later, this moved onto CD formats (like Microsoft TechNet CD library), and eventually online to the amazing wealth of resources and online communities we have today (like www.stackexchange.com).

Given this wide availability of best practice guidance, why isn’t every organisation getting better and better?

Is this in fact the key problem that the DevOps movement is trying to solve, to create a revolution in IT patterns, practices and culture to try and be the “rising tide that lifts all boats”?

In order to find out more my first port of call was the team at DORA, the DevOps Research and Assessment team, to see if they had any hard numbers to back up my anecdotal assessment.

Their findings, based on the 27,000 survey responses gathered for the PuppetLabs State of DevOps Report, make for a mixed picture.

Based on the 4 key metrics they recommend to assess IT performance, focused on the concept of “speed + stability”, 2 are narrowing, and 2 are widening.

  • deployment frequency — gap narrowing
  • change lead time — gap narrowing
  • MTTR — gap widening
  • change failure rate — gap widening
“When compared to the 2016 results, the gap between high and low performers narrowed for throughput (deployment frequency and change lead time), and widened for stability (mean time to recover and change failure rate). We speculate that this is due to low- performing teams working to increase speed, but not investing enough in building quality into the process. The result is larger failures, and more time to restore service. High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in, they get both.” — State of DevOps report, page 21.

The DORA findings seem to indicate that for many organisations undergoing Agile & DevOps Transformation focusing solely on speed rather than both speed + stability can lead to a (hopefully temporary) reduction in performance. This is born out in the ING Agile to DevOps case study where they saw an increase in change failure rate prior to a wider DevOps re-alignment and adoption of the full range of DevOps practices (see figure 4 change failure rate here https://www.infoq.com/news/2014/06/ing-transtition-to-devops).

However, the DORA data is drawn from a self-reported sample of survey respondents i.e. those people that know that the State of DevOps Report exists and complete the survey, and hence is biased towards organisations that have started on their DevOps journey.

It, understandably, has nothing to say about those organisations that don’t contribute to the survey i.e. those organisations who are not part of the DevOps Community and are still most likely following “traditional” IT patterns & practices (e.g. Prince 2, ITIL, CMMI etc).

It’s those organisations that I’m most concerned about.

I’m not saying everyone has to rush out and adopt DevOps methods willy-nilly (although we’d love to be your guides on a structured DevOps Transformation, naturally!) but I am saying that not acknowledging that there is a significant change in what it means to be a high-performing IT organisation taking place right now and that you need to respond to those changes puts your organisation at risk.

So if, in 2017, your organisation:

  • isn’t focused on delivering business value over adherence to a plan
  • is still following waterfall software development practices
  • is not using continuous integration, test automation and other CI/CD techniques
  • doesn’t yet have a cloud strategy (even if it’s hybrid or private cloud)
  • Isn’t utilising automation techniques like software-defined config management
  • isn’t actively nurturing a positive, collaborative, team culture

then how do you intend to continue to compete when other organisations are embracing these methods and reaping the rewards?

I will let the State of DevOps report have the final word on the benefits to your organisation of having a high-performing IT team:

We found that high performers were more than twice as likely to achieve or exceed the following objectives:
Quantity of products or services.
Operating efficiency.
Customer satisfaction.
Quality of products or services provided.
Achieving organizational and mission goals.
Measures that demonstrate to external parties whether or not
the organization is achieving intended results.
A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.