Report is available via: https://cloud.google.com/devops/

5% of respondants this year (of n=1000) were from 'Healthcare and Pharmaceuticals'. This TL;DR isn't intended to mitigate the need to read the report, the detail in it is incredible and worth delving into - it's merely to bring out some of the things I think are key in it.

For organizations seeking guidance on how to improve, we point to the only real path forward: Start with foundations, and then adopt a continuous improvement mindset by identifying your unique constraint (or set of constraints). Once those constraints no longer hold you back, repeat the process.

See the Four Key Metrics measures at the bottom of this post to really understand how high performing and low performing teams are measuring themselves - it makes it easier to compare your own local situation.

FURTHER DISCUSSION/LEARNING

There is a whole research section in the back that talks of improving either 'Software Delivery & Operational Performance' or 'Productivity' and there are models to follow with key indicators.

FINDINGS

  • The Four Key Metrics (MTTR, Lead Time, Change Failure Rate, Release Frequency) continue to define and drive the performance in technology transformations
  • Availability (as a fifth metrics) has become important - "At a high level, availability represents an ability for technology teams and organizations to keep promises and assertions about the software they are operating. Notably, availability is about ensuring a product or service is available to and can be accessed by your end users."
  • Key capabilities identified in technical practices, cloud adoption, organisational practices and culture that drive improvement in the four key metrics
  • Quick, reliable and safe software delivery is at the heart of technology transformation and the highest performers are likely to meet or exceed org performance goals
  • Community is key - ongoing communities of practice make orgs more resilient to change
  • Psychological safety is a key finding - "To support productivity, organizations can foster a culture of psychological safety and make smart investments in tooling, information search,and reducing technical debt through flexible, extensible, and viewable systems"
  • Change approval needs to be lightweight - "Heavyweight change approval processes, such as change approval boards, negatively impact speed and stability. In contrast, having a clearly understood process for changes drives speed and stability, as well as reductions in burnout."
  • Inclusion and Diversity is still a problem in our industry - demographics for gender, disability, underrepresented groups certainly see the same issues this year as we did in previous - more clearly needs to be done
  • People are more often working in DevOps teams - though I wonder if there's a confirmation bias here in the 'everything is agile' sense - the word has become conflated, so do all respondees fully embrace the above key findings or do they just have a job title?
  • Velocity is increasing - "Industry velocity is increasing and speed and stability are both possible, with shifts to cloud technologies fueling this acceleration. This reaffirms the importance of technology that enables organization to deliver value to their stakeholders."

Culture is often lauded as the key to DevOps and technology transformations by practitioners and champions who lead efforts in organizations. Indeed, Davis and Daniels cite culture as a key factor in successful and scalable technology efforts in their book Effective DevOps. Our own research has found that an organizational culture that optimizes for information flow, trust, innovation, and risk-sharing is predictive of SDO performance.

Research from a large two-year study at Google found similar results: that high-performing teams need a culture of trust and psychological safety, meaningful work, and clarity. This team environment allows members to take calculated and moderate risks, speak up, and be more creative.

FOUR KEY METRICS MEASURES

Deployment Frequency

  • low performers = deploying between once per month and once per six months
  • normalised = 1,460 deploys per year for highest performers, 7 for low performers
  • elite performers deploy 208 times more frequently than low

Change Lead Time

  • 'time from code commit to deployed to production'
  • elite performers = < 1 day
  • low perfomers = one month >=< six months
  • elite performers 106 times faster at getting value into customers hands

MTTR (Mean time to recovery)

  • elite = < 1hr
  • low performers = one week >=< one month

Change Failure Rate

  • elite = 0-15%
  • low performers = 46-60%