Digital Transformation and Organisational Dysfunctions

  1. A gap between strategy and delivery – we know what we want to do, and we have the people and tools to do it, but we can’t seem to do it. We end up building something different to what we intended in the strategy. This may be a sign of weak strategy, or it may be a product ownership problem – translating business strategy into the products and services to be delivered.
  2. A gap between desire for pace of delivery and ability to deliver. We want to go at 100mph, but we can only go at 30mph. The pace of delivery may be constrained by capability, tooling, process, constraints, or simply capacity. It’s usually not actually a capacity problem, however. In technological domains, this is the realm of DevOps transformations and the practices that enable value to be delivered at high velocity whilst maintaining reliability and quality.
  3. A lack of organisational observability that results in poor understanding of value flows across the organisation, poor awareness of sociotechnical aspects of the system as a whole, resulting in problems that are known by teams taking leadership by surprise, if they ever become aware of them. A lack of systems thinking, combined with poor psychological safety across the organisation, results in executives only being told what they want to hear, or information becoming diluted as it flows “up”.
  4. Short termism – poor incentive structures (indeed, most incentives) or cultures mean that people are focused on immediate short term wins rather than long term value and outcomes. This is also manifested by an adherence to project methodologies where the delivery of value has a start and, specifically, an end date, instead of a long-lived product approach that provides people with greater ownership of outcomes, longer lived teams, lower technical and operational debt, and higher quality products and services.
  5. Quality issues. We can build the right things, but we can’t do it well. Conflicts of interest or capability issues mean that products and services are delivered, but they suffer from reliability, consistency or architectural problems. Technical and operational debt is high, and teams feel like they are always firefighting and dealing with unplanned work. An approach of late inspection rather than building quality in to the process is often part of the cause of this dysfunction.
  6. Poor organisational ability to learn. Systems, cultures and processes hinder people’s (and groups of people, such as teams or business units) ability to learn from failures and successes. The same mistakes are made repeatedly, and when successes do get made, the valuable learning from them is not institutionalised. Psychological safety, along with rituals such as retrospectives, may be lacking in this organisation.
  7. An excessive inward focus. Focussing too much on “what we do” rather than looking out at the world for challenges, opportunities, and a changing landscape means that opportunities are wasted and challenges can present existential threats to the organisation through a lack of capability to become aware of them, let alone adapt to them. A strong organisational cultural identity, whilst a powerful and valuable aspect of an organisation, can result in this dysfunction.
  8. An excessive outward focus. A focus only on the external means that market and environmental opportunities and threats are detected, but threats to performance or opportunities for improvement arising from inside the organisation are not detected, mitigated or exploited.
  9. A bimodal approach to value where the products and services delivered to customers far exceed the quality and features of those delivered to people within the organisation who are expected to use those services to do their job. We wouldn’t provide surgeons with blunt scalpels and expect a great result for the “customer”, but many organisations provide poor quality services and tools to employees whilst expecting high quality outcomes.
  10. A culture of fear over a culture of experimentation. An organisation that enforces behaviour or strives towards goals based on the consequences of failure or divergence from the norms, will move much slower and gradually grind to a halt. In these organisations, the safest thing to do is to comply with rules and take as few risks as possible, rather than suggest ideas, try (and risk failure), or admit mistakes.

The Accelerate State of DevOps Report 2021 – A Summary

The 2 state of DevOps reports each year aggregate the current state of technology organisations globally in respect to our collective transformation towards delivering value faster and more reliably. Or as Jonathan Smart puts it, “Sooner. Safer, Happier”.

The DevOps shift has been in progress for over a decade now, and whilst DevOps was always really about culture, the most recent reports are now emphasising the importance of culture, progressive leadership, inclusion, and diversity more than ever before.

Last year, in 2020, the core findings of the State of DevOps Report focussed on:

  1. The technology industry in general still had a long way to go and there remained significant areas for improvement across all sectors.
  2. Internal platforms and platform teams are a key enabler of performance, and more organisations were starting to adopt this approach.
  3. Adopting a long-term product approach over short-term project-oriented improves performance and facilitates improved adoption of DevOps cultures and practices.
  4. Lean, automated, and people-oriented change management processes improve velocity and performance over traditional gated approaches.

 

This year (2021), there are a number of key findings in the Accelerate State of DevOps Report, building on previous iterations:

  1. The “highest performers” continue to improve the velocity of delivery, through practices that enable teams to continually identify improvements to tooling, technology and process.
  2. Adoption of SRE practices improves wider organisational performance. Teams that prioritise both delivery and operational excellence report the highest organisational performance. Reliability is as important, if not more so, than short lead time for changes.
  3. Adoption of cloud technology accelerates software delivery and organisational performance, and enables the five capabilities of cloud native technology. Multi-cloud adoption is increasing, so that teams can utilise the strengths of each provider and improve resilience against risk of a single provider failure.
  4. Secure Software Supply Chains that integrate security practices into pipelines and processes enable teams to deliver secure software quickly, safely and reliably.
  5. Documentation is important. Teams that create and maintain high quality documentation are more able to implement technical practices, make changes, and recover from incidents. 
  6. Inclusive and generative team cultures improve resilience and performance. Teams with psychologically safe and inclusive cultures suffered less from burnout during the Covid-19 pandemic.

devops and documentation

View the entire 2021 Accelerate State of DevOps report here.

View the 2021 Puppet State of DevOps Report summary here.

And read here a summary of all the State of DevOps reports since 2013!

180 Factors of Organisational and Digital Transformation

The below is a simple but extensive (though non-exhaustive and growing) list of factors to address and discover when working on organisational and digital transformations.

I’ve used this list as a helpful reminder when carrying out discovery sessions with clients, and you can too! If you’d like to suggest additions or changes, please let me know!

Organisation

  • Line of business
  • Risk register / immediate risks
  • Risk appetite
  • Public / private / shareholding / equity holding
  • Impediments and current challenge
  • Tracking up or tracking down
  • Industry volatility and disruption
  • Competitors
  • Urgency
  • Cost of delays
  • Cost of changes
  • Regulatory compliance needs
  • Locations
  • Time zones
  • Organisation size
  • Organisation age
  • Diversity of business lines/units
  • Purpose and values
  • Mission statement
  • History and folklore
  • Past mergers and acquisitions
  • Organisation identity in the world
  • Public or private
  • Short term pressure / long term pressure
  • Heterogeneity of leadership / board
  • Finances – cash, P&L, share price, turnover, EBITDA
  • Cost sensitivity
  • Preference for opex vs capex
  • Exit strategy

 

People

  • Organisational culture
  • Heterogeneity of culture across the organisation
  • Leadership buy-in to transformation
  • Key stakeholders
  • Prior transformation attempts
  • Psychological safety (org-wide / in-team)
  • Customer expectations
  • Customer base (business, consumer, public, other)
  • Ease of customer feedback
  • Diversity
  • Equality, gender pay gap visibility
  • National identity and culture
  • Survival anxiety
  • Team member churn rate / length of tenure
  • Organisational structure, reporting lines, matrix, hierarchies
  • Geographical distribution
  • Permanent teams vs outsourced teams
  • Skill and mastery level
  • Tacit knowledge in the organisation
  • Capabilities and gaps
  • Promotions, recognitions and awards
  • Pay scales
  • Orthodoxies
  • Defined roles
  • Cross-teaming
  • Training, coaching, mentoring, support
  • Career paths
  • Physical working environment
  • Communities of Practice
  • Remote vs on-prem (degrees of remoteness)
  • Longevity of teams
  • Centres of Excellence / Enablement
  • Stream aligned teams / function-aligned teams / hybrid
  • Known rituals
  • Facilities, office design, open vs closed offices, physical space
  • Exposure to “business” information such as cashflow, profit, turnover, and granularity.

 

 

Process

  • Operating model
  • Policies
  • Standards
  • Processes
  • Regulation of process
  • Standardisation appetite
  • Finance process
  • Budget cycle
  • Business case requirement
  • Hiring process
  • Procurement process and duration
  • Adherence to frameworks
  • International & national standards
  • Audit frequency and type
  • Governance, risk, compliance processes
  • Product vs project
  • ITIL / COBIT / other frameworks
  • Environment provisioning
  • Preference for waterfall vs agile
  • Handoffs
  • WIP limits
  • Communications cadences and expectations
  • Current methodologies and practices
  • Security clearances
  • Natural / habitual cadences
  • Agile adoption
  • Scrum adoption
  • Methodologies at scale (SAFe, LESS, etc)
  • Statistical Process Control – level of automation and adoption

 

Data and Tools

  • Wall space or digital tools – information radiators
  • Data-driven insights capability
  • Communication tools – asynchronous vs synchronous
  • Silos of information
  • Data feedback loops
  • Dataviz and analytic tools
  • Degree of tool integration
  • SSO
  • “Shadow” IT
  • Degree of autonomy / lockdown of machines
  • AI/ML
  • Volume of data
  • Information availability, default to open/closed
  • Data treated as asset or liability
  • Default information openness
  • Dashboarding and reporting

 

Products

  • Number and characteristics of key products
  • Criticality (life/death or just for fun)
  • Cost of delay for features
  • Level of planning expectation
  • Estimates and deadlines required
  • Risk appetite
  • Reliability requirements
  • Scaling requirements
  • Quality requirements
  • Degree of coupling
  • Degree of cohesion
  • Current lead time
  • Current flow / wait time
  • Current quality
  • Internal regulation
  • Unplanned vs planned work
  • Product lifespan
  • Feature lifespan
  • Marketing approach and capabilities

 

Technology

  • Satisfaction of technical capability
  • Common platform?
  • Architecture – monolithic vs microservices / APIs
  • Potential fracture planes
  • Team topology
  • Corporate network (MPLS, VPNs, hybrid, SDN, etc)
  • Cloud usage (production) – private/hybrid/public
  • Edge and IoT technology
  • Preferred technologies and codebase
  • Build and Deployment pipelines
  • Deployment strategies – canary, blue/green, rolling, A/B
  • Engineering skills
  • Engineering practices
  • Service Desk?
  • Infra as code
  • Containerisation
  • Test and QA approach
  • Work definition approach – user stories, MoSCoW etc
  • Rate, predictability and volume of work requests
  • Where does work come from?
  • Environments
  • Monitoring and observability
  • Degree of automation
  • Branching strategies
  • Existing reliability
  • Existing rate of change
  • Accelerate metrics
  • Technical debt
  • Pair programming, mob programming practices
  • Ratio of junior to senior engineers
  • Dev workstations and tooling
  • Dev / Ops teams & handovers
  • On-call culture and process
  • Infosec team / function and interactions

Please feel free to use this however you’d like, and if you think something needs adding to this list of organisational transformation factors, please let me know!

Summary of all State of DevOps Reports since 2013

It’s not that easy to find all the annual state of DevOps reports, partly because they forked in 2017 between Puppet and Google/DORA. Below I’ve listed each report by year, and I’m in the process of listing all the key findings from each report. Some reports provide greater insights than others.

The first report was in 2013, and showed quite clearly that adopting DevOps practices resulted in technological and business improvements. Along the way, Puppet and Google / DORA joined forces, parted ways, and now (as of writing in 2021) there are two State of DevOps Reports, and the focus has broadened to SRE, Organisational Culture, Security, and even Documentation.

2013 – Puppet:

  1. Respondents from organisations that implemented DevOps reported improved software deployment quality and more frequent software releases.
  2. DevOps enables high performance by increasing agility and reliability. High performing organisations ship code 30x faster and complete those deployments 8,000 times faster than their peers. They also have 50% fewer failures and restore service 12 times faster than their peers.
  3. Organisations that have implemented DevOps practices are up to five times more likely to be high-performing than those that have not. In fact, the longer organisations have been using DevOps practices, the better their performance: The best are getting better.

2014 – Puppet and DORA –

  1. Strong IT performance is a competitive advantage. Firms with high-performing IT organisations were twice as likely to exceed their profitability, market share and productivity goals.
  2. DevOps practices improve IT performance. IT performance strongly correlates with well-known DevOps practices such as use of version control and continuous delivery.
  3. Organizational culture matters. Organizational culture is one of the strongest predictors of both IT performance and overall performance of the organisation. High-trust organisations encourage good information flow, cross-functional collaboration, shared responsibilities, learning from failures and new ideas; they are also the most likely to perform at a high level.
  4. Job satisfaction is the No. 1 predictor of organisational performance. Job satisfaction includes doing work that’s challenging and meaningful, and being empowered to exercise skills and judgment. Where there is job satisfaction, employees bring the best of themselves to work: their engagement, their creativity and their strongest thinking.

2015 – Puppet and DORA:

  1. High-performing IT organisations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster. Failures are unavoidable, but how quickly you detect and recover from failure can mean the difference between leading the market and struggling to catch up with the competition.
  2. Lean management and continuous delivery practices create the conditions for delivering value faster, sustainably.  This results in higher quality, shorter cycle times with quicker feedback loops, and lower costs. These practices also contribute to creating a culture of learning and continuous improvement.
  3. High performance is achievable whether your apps are greenfield, brownfield or legacy. As long as systems are architected with testability and deployability in mind, high performance is achievable.
  4. IT managers play a critical role in any DevOps transformation. Managers can do a lot to improve their team’s performance by ensuring work is not wasted
    and by investing in developing the capabilities of their people.
  5. Diversity matters. Research shows that teams with more women members have higher collective intelligence and achieve better business outcomes.
  6. Deployment pain can tell you a lot about your IT performance. Where code deployments are most painful, you’ll find the poorest IT performance, organisational performance and culture.
  7. Burnout can be prevented, and DevOps can help. Burnout is associated with pathological cultures and unproductive, wasteful work.

2016 – Puppet and DORA:

  1. High-performing organisations are decisively outperforming their lower-performing peers in terms of throughput. High performers deploy 200 times more frequently than low performers, with 2,555 times faster lead times. They also continue to significantly outperform low performers, with 24 times faster recovery times and three times lower change failure rates.
  2. High performers have better employee loyalty, as measured by employee Net Promoter Score (eNPS). Employees in high-performing organisations were 2.2 times more likely to recommend their organisation to a friend as a great place to work, and 1.8 times more likely to recommend their team to a friend as a great working environment. Other studies have shown that this is correlated with better business outcomes.
  3. Improving quality is everyone’s job. High-performing organisations spend 22 percent less time on unplanned work and rework. As a result, they are able to spend 29 percent more time on new work, such as new features or code. They are able to do this because they build quality into each stage of the development process through the use of continuous delivery practices, instead of retrofitting quality at the end of a development cycle.
  4. High performers spend 50 percent less time remediating security issues than low performers. Through better integrating information security objectives into daily work, teams achieve higher levels of IT performance and build more secure systems. less time on unplanned work and rework.
  5. Taking an experimental approach to product development can improve your IT and organisational performance. The product development cycle starts long before a developer starts coding. Your product team’s ability to decompose products and features into small batches; provide visibility into the flow of work from idea to production; and gather customer feedback to iterate and improve will predict both IT performance and deployment pain.

2017 – Puppet and DORA:

  1. Transformational leaders share five common characteristics that significantly shape an organisation’s culture and practices, leading to high performance. The characteristics of transformational leadership — vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition — are highly correlated with IT performance.
  2. High-performing teams continue to achieve both faster throughput and better stability. The gap between high and low performers narrowed for throughput measures, as low performers reported improved deployment frequency and lead time for changes, compared to last year. However, the low performers reported slower recovery times and higher failure rates. It’s possible that pressure to deploy faster and more often causes lower performers to pay insufficient attention to building in quality.
  3. Automation is a huge boon to organisations. High performers automate significantly more of their configuration management, testing, deployments and change approval processes than other teams. The result is more time for innovation and a faster feedback cycle.
  4. Loosely coupled architectures and teams are the strongest predictor of continuous delivery. If you want to achieve higher IT performance, start shifting to loosely coupled services — services that can be developed and released independently of each other — and loosely coupled teams, which are empowered to make changes.
  5. Lean product management drives higher organisational performance. Lean product management practices help teams ship features that customers actually want, more frequently. This faster delivery cycle lets teams experiment, creating a feedback loop with customers.

2018 – Puppet:

  1. DevOps drives business growth – maintaining a robust software delivery and operability function increases productivity, profitability, and market share.
  2. Cloud technology correlates with business performance – this is enabled by reliable and sustainable cloud infrastructure, utilised via cloud native patterns.
  3. Open source software improves performance – high-performing IT teams are 1.75 times more likely to use open-source applications.
  4. Functional outsourcing can be detrimental to software performance, and Elite Performers are rarely using it.
  5. Technical practices such as monitoring and observability, continuous testing, database change management, and the early integration of security in software development all enable organisational performance.
  6. DORA identified high-performing organisations in a range of profit, not-for-profit, regulated, and non-regulated industries. The industry you’re in doesn’t affect your ability to perform.
  7. Diversity in tech is poor, but improving, and teams with improved diversity demonstrate higher performance than those that don’t.

2018 – DORA  (Accelerate):

  1. SDO (Software Delivery Organisation – i.e. development teams) performance unlocks competitive advantages. Those include increased profitability, productivity, market share, customer satisfaction, and the ability to achieve organisation and mission goals.
  2. How you implement cloud infrastructure matters. Proper (effective) usage of the public cloud improves software delivery performance and teams that leverage all of cloud computing’s essential characteristics are 23 times more likely to be high performers.
  3. Open source software improves performance. Open source software is 1.75 times more likely to be extensively used by the highest performers.
  4. Outsourcing by function is rarely adopted by elite performers and hurts performance. While outsourcing can save money, low-performing teams are almost 4 times as likely to outsource whole functions such as testing or operations than their highest-performing counterparts.
  5. Key technical practices drive high performance. These include monitoring and observability, continuous testing, database change management, and integrating security earlier in the SDLC.
  6. Industry doesn’t matter when it comes to achieving high performance for software delivery. High performers exist in both non-regulated and highly regulated industries alike.

2019 – Puppet:

  1. Doing DevOps well enables you to do security well.
  2. Integrating security deeply into the software delivery lifecycle makes teams more than twice as confident of their security posture.
  3. Integrating security throughout the software delivery lifecycle leads to positive outcomes.
  4. Security integration is messy, especially in the middle stages of evolution.

2019 – Google:

  1. The industry continues to improve, particularly among the elite performers.
  2. The best strategies for scaling DevOps in organisations focus on structural solutions that build community, including Communities of Practice.
  3. Cloud continues to be a differentiator for elite performers and drives high performance.
  4. To support productivity, organisations 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.
  5. 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.

2020 – Puppet:

  1. The industry still has a long way to go and there remain significant areas for improvement across all sectors.
  2. Internal platforms and platform teams are a key enabler of performance, and more organisations are adopting this approach.
  3. Adopting a product approach over project-oriented improves performance and facilitates improved adoption of DevOps cultures and practices.
  4. Lean, automated, and people-oriented change management processes improve velocity and performance.

2021 – Puppet:

  1. Organisational dynamics must be considered crucial to transformation.
  2. Cloud-native approaches are critical. It is no good to simply move traditional workloads to the cloud.
  3. Shift security, compliance and change governance left, and include security stakeholders in all stages of value delivery.
  4. Culture change is key, and must be promoted from the very “top” as well as delivered from the “bottom”. Psychological safety is at the core of digital and cultural transformations.

2021 – Accelerate:

  1. The “highest performers” continue to improve the velocity of delivery.
  2. Adoption of SRE practices improves wider organisational performance.
  3. Adoption of cloud technology accelerates software delivery and organisational performance. Multi-cloud adoption is also on the increase.
  4. Secure Software Supply Chains enable teams to deliver secure software quickly, safely and reliably.
  5. Documentation is important to being able to implement technical practices, make changes, and recover from incidents. 
  6. Inclusive and generative team cultures improve resilience and performance.

2022 – Google / DORA:

  1. Generative Cultures are indicators of higher performance.
  2. Less experienced teams who implemented trunk-based development actually show less positive results than teams who do not use trunk-based development.
  3. Healthy, high-performing teams also tend to have good security practices broadly established.
  4. Software delivery performance alone does not predict organisational success. Excellent software delivery combined with high reliability (high DORA Metrics in this case) correlate with organisational success.

The Puppet State of DevOps Report 2021 – A Summary

I get a bit confused every year about who is writing the State of DevOps Report, and how that gets decided, and in the past it’s been Puppet, Google, DORA and others, but this year, 2021, it was definitely Puppet.

[Edit: apparently there are two State of DevOps reports now… I’m staying out of that particular argument though!]

The state of DevOps report each year attempts to synthesise and aggregate the current state of the technology industry across the world in respect to our collective transformation towards delivering value faster and more reliably. Or as Jonathan Smart puts it, “Sooner. Safer, Happier”. The DevOps shift has been in progress for over a decade now, and whilst DevOps was always really about culture, the most recent reports are now emphasising the importance of culture, progressive leadership, inclusion, and diversity more than ever before.

Last year, in 2020, the core findings of the State of DevOps Report focussed on:

  1. The technology industry in general still had a long way to go and there remained significant areas for improvement across all sectors.
  2. Internal platforms and platform teams are a key enabler of performance, and more organisations were starting to adopt this approach.
  3. Adopting a long-term product approach over short-term project-oriented improves performance and facilitates improved adoption of DevOps cultures and practices.
  4. Lean, automated, and people-oriented change management processes improve velocity and performance over traditional gated approaches.

This year (2021), there are a number of key findings building on previous DevOps reports:

1. Well defined and architected Team Topologies improve flow.

Clear organisational dynamics including well-defined boundaries, responsibilities, and interactions, are critical to achieve fast flow of of value. Whilst last year highlighted the importance of internal platforms, this report emphasises the importance of Conway’s Law, and shows that well defined team structures and interactions, such as platform teams (which scale out the benefits of DevOps transformations across multiple teams), cross-functional value-stream aligned teams, and enabling teams strongly influence the architecture and performance of the technology they build. Team “Interaction Modes” as seen in the diagram below are also critical to define, in the same way that we would define API specifications.

DevOps and Team Topologies

The book Team Topologies expands upon this concept in great detail, and Matthew and Manuel, the authors, also provide excellent training in order to apply these concepts to your contexts.

Clear team responsibilities

What is also clear from the State of DevOps Report this, and has been for some time, is that siloing DevOps practices into separate “DevOps teams” is an antipattern to success in most cases. And there should still be no such thing as a “DevOps Engineer”.

2. Use of cloud technology remains immature in many organisations.

Whilst the majority of organisations are now using cloud technology such as IaaS (infrastructure-as-a-service), most organisations are still using it in ways that are analogous to the ways we used to manage on-premise or datacentre technology. High performers are adopting “cloud-native” technologies and ways of working, including the NIST (National Institute of Standards and Technology)essential characteristics of cloud computing: “on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service.” How these are implemented is very context-specific, but includes the principles of platform(s) as a product or service, and high competencies in monitoring and alerting and SRE (Site Reliability Engineering) capabilities, whether as SRE teams, or SRE roles in cross-functional teams.

Cloud native capabilities and devops

3. Security is shifting left.

High performers in the technology space integrate security requirements early in the value chain, including security stakeholders into the design phase and build phases rather than just at deploy, or even worse, run, phases. Traditional “inspection” approaches to security, governance and compliance significantly impact flow and quality, resulting in higher risk and lower reliability. Applying DevOps principles and practices to include change management, security and compliance improves flow, reliability, performance, and keeps the auditors off your back.

DevSecOps transformation

Whilst some call this DevSecOps, many would simply call it DevOps the way it was always intended to be.

4. DevOps and Digital Transformation must be delivered from the bottom-up, and empowered from the top-down.

Culture is the reflection of what we do, the behaviours we manifest, the practices we perform, the way we interact and what we believe. Culture change is never successfully implemented only from the top-down, and must be driven and engaged with by those expected to actually change their behaviours and practices.

DevOps transformation promotion

Cultural barriers to change include unclear responsibilities (enter Team Topologies), insufficient feedback loops, fear of change and a low prioritisation for fast flow, and most importantly, a lack of psychological safety.

Psychological safety and risk

A lot of these findings, unsurprisingly, echo the findings from Google’s 2013 Project Aristotle, which showed that psychological safety, clarity, dependability, meaning and impact were crucial for high performance in teams.

Extra note on “Legacy” workloads.

The report highlighted the “dragging” effect that legacy workloads can have on flow and change rate, as an effect of their architecture, codebase, or infrastructure, or the fact that nobody in the organisation understands it any longer. Rather than leave alone your legacy workloads, invest in them “so that they’re no longer an inhibitor of progress”. This could be as simple as virtualisation of physical hardware, or decomposing part of the system and moving certain components to cloud-native platforms such as Kubernetes or OpenShift. Even if you have to do something a bit “ugly” such as creating 18GB containers, it’s still a step forward.

TL;DR

  1. Organisational dynamics must be considered crucial to transformation.
  2. Cloud-native approaches are critical. It is no good to simply move traditional workloads to the cloud.
  3. Shift security, compliance and change governance left, and include security stakeholders in all stages of value delivery.
  4. Culture change is key, and must be promoted from the very “top” as well as delivered from the “bottom”. Psychological safety is at the core of digital and cultural transformations.

If you’re interested in finding out more about DevOps and Digital Transformations, Psychological Safety, or Cloud Native approaches, please get in touch.

Thanks to Nigel Kersten, Kate McCarthy, Michael Stahnke and Caitlyn O’Connell for working on the 2021 State of DevOps Report and providing us with these insights.

View the 2021 Accelerate State of DevOps Report summary here.