Removing the common barriers that impact an organisation's DevOps practices is relatively simple, but simple is not the same thing as easy. Achieving this level of simplicity often requires considered consultation with credible, trusted technology partners, coupled with genuine diagnosis into the individual organisation’s type and magnitude of pain points. Doing so will begin to direct cultural perspectives and behaviours in such a direction that embraces reliable, technology-enabled productivity gains. Ultimately, this is a matter of organisational change and (the very common) resistance to it.
When it comes to treating the status quo and vision barriers, change management fundamentals are typically overlooked, particularly in the design stages before implementation. Our experience has found that the alignment of operational goals with strategic vision is one such commonly overlooked aspect of this change management. By addressing the status quo and vision barriers, the awareness and business case barriers can be much more easily addressed. We have observed that organisations who take the following steps greatly increase the probability of achieving their desired outcomes with DevOps.
DevOps Barrier Buster #1: Change diagnosis
An organisation is likely to be lagging on the DevOps maturity scale if key stakeholders are not aware of or have not completely bought into their DevOps practices. Technology events, white papers, industry reports, and related collateral by tier-one and niche consultancies are beneficial in overcoming this awareness barrier, and once this has been done the change diagnosis can begin. Jade recommends an audit of material suppliers to ensure that DevOps practices are evolving to benefit customers, which should address two key questions:
- Is the business attempting to solve the right problem?
- Has the case for change been appropriately articulated and validated?
These two questions are foundational in growing a business’s DevOps maturity, as they put greater emphasis on the customer rather than on the intuition of influential leaders. Regardless of experience, our innate cognitive aptitude for pattern recognition can bias our decisions, due to apparent similarity with previous contexts.
In aiding our clients to improve or transform the operation of their technology function, Jade uses a qualitative and quantitative assessment model that verifies stakeholder interviews with direct technical assessment. The findings are then mapped out to understand the current state of the organisation across three dimensions:
- People: What problems and opportunities are being reported by people, and are these consistent with observable infrastructure and systems development lifecycle?
- Technology platform and tools: Are the available technical tools fit for purpose and compatible with each other?
- Processes: Is there clear accountability and clarity; configuration and adoption of available tools/technology to match and enable workflows and processes?
While the technical execution of more intuitive approaches may yield some benefit, having everyone onboard will likely lead to achieving desired outcomes faster.
DevOps Barrier Buster #2: Organisational buy-in
While every would-be change agent understands the importance of buy-in, two key activities are consistently overlooked by technology leaders:
Broad internal communications
Most organisational changes, technology or otherwise, are let down by the mistaken assumption that everybody knows and understands what is going on – even if this assumption is coupled with the belief that the changes have been over communicated. A programme of wide communication across various mediums helps to address two key questions:
- Why are we making this change? This is where solid change diagnosis really helps to inform and get people onboard. More broadly, the ‘why’ of change is crucial to adult learning. Once people understand the why, the how, what, where, etc. typically falls into place.
- What’s in it for me? Iteratively helping people understand how they will be positively impacted by change is fundamental to achieving strong, lasting buy-in during times of uncertainty.
It is essential that internal communications are two-way, so affected people have the opportunity and feel encouraged to ask questions and provide input on the impending change. Providing both private and public forums for this is essential too.
Many change agents are tempted to resist this step due to the reasonable concern that critical feedback could derail or fragment the momentum of the planned change. The consistently observed reality is that forging ahead without conversing via online surveys, corporate chat channels, or townhall meetings invariably leads to poor change adoption.
Note that feedback may not even need to be acted upon either. Just acknowledging and responding to the main feedback themes regarding the change rationale can be sufficient for the internal community to feel heard and mitigate active detraction. But if themes are strong enough, concessions should be made to encourage people to submit feedback with future projects. Win the war, not the battle.
While feedback from a range of roles and seniority is best, there are two particular types of employee whose feedback holds particular weight:
- Formal decision makers throughout the business, even if they don’t have direct accountability for impacted areas of the organisation.
- Influencers in the business who are prominent in what change expert Egan (1994) calls ‘the shadow side’ of the organisational power. These people operate separately, though not at odds, from the legitimate or coercive power of the official org chart.
DevOps barrier buster #3: Find and quantify the benefits
Managers can find it challenging to quantify the value that will be unlocked by changing current practices from an operable (albeit sub-optimal) base. This challenge still exists even when there’s a broad base of support throughout the technology function that ‘these changes need to be made’.
While the type of value and benefits on offer will vary between organisations, common examples delivered by DevOps and DevSecOps evolution include:
- Mean time to recover (MTTR) from high severity incidents: To be more compelling, a rationale assignment of a dollar value (lost sales revenue, SLA failure rebates to clients/partners, incident management costs) for each minute a system is offline can make for a stronger case.
- Package build time: Associating the time to build a code package with the administrative labour to do so can make the business cost more compelling, particularly when compared to existing build times.
- Release automation: Again, non-production and production environment releases require some coordination, but in lower performing teams they will consume a significant amount of labour effort to execute and verify. Automating release processes and regression test coverage will deliver huge mid and long-term productivity gains, with the option of labour cost savings.
PhoenixNAP offers a concise but comprehensive list of DevOps metrics to consider when articulating the value of intended changes. However, it is important to infer the most tangible possible business benefits to be realised from improvements in those metrics, so that funding and broad support can be secured.
For the more DevOps-adept organisations, pursuing DevSecOps to embed security practices into development planning may rely on evaluating the cost of any historical breaches, or the cost of initiatives that have been shelved or re-worked based on late involvement of security experts. Shifting expertise and input left (up the development value chain) does not occur without cost, so quantifying where the dividend will be paid is important.
DevOps barrier buster #4: Emergent drivers
Despite the importance of assigning a dollar value to MTTR, regression test coverage, build process, deploy effort, and unplanned work, the business case may also have room for less well-evidenced rationale.
Unpredictable disruptions to value chains such as 2020’s pandemic tend to be harder to quantify and less probable to reoccur over the long-term. However, during such times of disruption, hypersensitive organisational risks can be leveraged to enhance a business case, providing managers consult with internal risk experts and articulate the concern simply.
Is your DevOps programme reaching it's potential?
