Fusing software development and operations (DevOps) provides organisations with new levels of speed, agility, and quality, resulting in ever-increasing competitive advantages. Across industries, Jade has witnessed a growing maturity towards such technology agility.
While momentum is growing in this way of working, most business and technology managers continue to report their IT function has proved unsatisfactory, particularly since March 2020 in dealing with internal production and customer service changes driven by the pandemic. This has, in part, contributed to a widening gap between high performers and the rest of the pack.
Google, who are well-versed in DevOps methodologies, identified five key metrics for measuring the effectiveness of their IT practices: Lead time, Deployment Frequency, Change fail, Time to restore, and Availability. These metrics span across software development, deployment, and operations.
Google co-published a State of DevOps 2019 report that outlined a DevOps maturity framework, similar to Puppet’s DevOps evolutionary scale. Puppet identified that most organisations find themselves somewhere in the middle of the scale, with laggards becoming a shrinking minority. For those in the middle of the scale, typically more responsive, productive technology organisations that have adopted DevOps methodologies, persistent barriers are still holding them back from realising the full potential of DevOps.
DevOps: Barriers to frequent value delivery
For those organisations in an elite or high stage of DevOps maturity, the operational implications and organisational value of DevOps practices are expected to be self-evident, to the point of being unassailable. But that can belie the transformative efforts that occurred to introduce and embed new approaches and practices across the business
Businesses in earlier stages of DevOps maturity, and more broadly organisational agility, foresee mainly the tough, uncertain road ahead, with nearer term pressures crowding out focus on initiatives that can propel market competitiveness. Across Jade’s Australian and New Zealand customer base, four barriers to enhancing delivery capability periodically recur, which can be summed up as awareness, status quo confidence, making the vision tangible, and building the business case.
Barrier #1: Low awareness of new ways to deliver value faster
Despite what many technology managers may think, there are still a reasonable number of businesses whose technology functions exhibit little awareness or interest in DevOps concepts and practices. This low awareness is a big barrier due to the time and effort required to educate key stakeholders on the need and importance of this new way of working.
Apart from those in the IT industry, small cap organisations are often operating in an environment that requires the transparency of market reporting, high reliance on multiple third parties as material technology vendors, and CapEx constraints that are relatively tighter than larger market participants. As a business’s market cap increases, both the reliance on third parties and CapEx constraints typically diminish.
The combination of these factors, mixed with a focus on digital technology as an enabler of differentiation, minimises awareness of DevOps practices.
Barrier #2: Staying with a status quo confidence
People are ambivalent towards change until it directly impacts them. The time and scope required to envision a more stable, efficient set of practices grates against the implicit confidence in how the current ecosystem functions, regardless of worsening technical debt and scalability risks.
Considering the constant immediate delivery pressures, a fragile technical legacy, and heavy reliance on third parties, the old adage ‘better the devil you know’ can hamstring many organisations depending on the incentives of managers and leaders. Previous experience in ramping up labour or infrastructure assets to deliver new products or meet seasonal peaks in demand can – despite their pain – be perceived as instructive learning experiences, with regards to lead time rather than imperatives to innovate practices.
This barrier is composed of both a time horizon component (short-term focus) as well as complexity. As technology operations leaders often report to Jade: “new ways of working struggle to intersect with the operational reality of compounded technical debt”.
Barrier #3: An intangible vision
The org structure flipside that enables and sustains the status quo confidence is the failure of senior leadership stakeholders to make the vision of new DevOps practices tangible, not applying it to the delivery and availability realities of the here and now.
An enterprise vision that responds to operational inefficiencies and promises reduced re-work, integration, and automation of steps in the software development lifecycle (SDLC) is an attractive panacea. This vision is likely to be met by skepticism at the coal face unless the vision frequently and consistently acknowledges the current operational model. Without this acknowledgement, an organisation’s development community and operational function will be left assuming that any realised vision will be reserved for peripheral greenfield initiatives rather than optimising the core aspects of value creation.
Barrier #4: Insufficient evidence for a business case
Even without the above barriers, and assuming a widespread support for technology practice changes in the organisation, there remains the quantitative reality of creating a compelling business case. The specifics of this barrier vary depending on the DevOps maturity of the organisation.
Immature organisations may seek to acquire new tools, better performers on increased automation and integration of build, test, and deployment pipelines. Top performers may also seek to expand the DevOps ethos to collaborate with the security function (DevSecOps) or enable operational functions to more effectively self-serve.
Whatever the maturity step, the business case needs careful consideration to crystallise expected headache-remedies into clear, quantifiable benefits that are net-present-value positive in a timeframe reasonable to organisational norms.
Is your DevOps programme reaching its potential?
