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.
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:
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:
While the technical execution of more intuitive approaches may yield some benefit, having everyone onboard will likely lead to achieving desired outcomes faster.
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:
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:
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:
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.
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?