Top 3 (Avoidable) DevOps Implementation Mistakes

Rachel Seaniger and Chris Morrison call-out the most frequent mistakes made with DevOps implementations – offering tips on how to avoid them

As part of recent work developing our paper – Accelerating digital transformation through implementing a DevOps capability, we combined our experience and analysed insights from various project retrospectives.

In general, we have observed some common gaps in either methodology or approach – and sometimes a combination of the two – which lead to negative consequences and/or failures.

In our experience, it’s less a matter of resources and more about developing specific capabilities, but we acknowledge one depends on the other. In most cases, many IT organisations simply don’t understand and appreciate the implications of their pursuit of DevOps, and hence the benefits remain elusive.

More specifically, below are 3 avoidable implementation mistakes:

1. Not Understanding ‘The Four Types of Work’ in IT Operations

As a generalisation, a typical mainstream IT organisation in 2016 might have the following attributes:

  • some over-formalised ITIL processes implemented
  • a chunky SDLC process
  • a not-quite-agile project management capability
  • have lost-sight strategically of the quality of the citizen or customer’s experience
  • allocated some resources to introduce some ‘DevOps-inspired’ principles, and may even be aspiring to moving from quarterly (or longer) releases to monthly releases

In this scenario, IT Operations is expected to basically react to everything, and restore services when they break.

The result is a lack of coordination and integration of resources and capabilities, and despite heroic efforts intend to keep all the balls juggling, sometimes the one is dropped, badly. And more often than not, the business will tolerate it.

This scenario can be avoided through clearly defining what exactly ‘work’ is for IT Operations, according to 4 categories:

  • Business projects: business initiatives, of which most development projects encompass
  • Internal IT projects: infrastructure or IT operations projects that business projects may spawn, and internal improvement projects
  • Changes: any modification to the status of any component that could impact the business, and often generated from the above two types of work, tracked in a ticketing system
  • Unplanned Work (aka recovery work): operational incidents and problems, often caused by the above three types of work and always come at the expense of other planned work commitments.

This seems pretty obvious when placed in front of us but how many organisations plan and design themselves to optimise delivery of all four types of work?

Until there is understanding of the volume and resource impact of each type of work (yes that means planning for unplanned work!) chaos and fire-fighting reigns.

As demonstrated so well in The Phoenix Project, we often find one or two key resources that are a bottle neck to the flow of work.

2. Acting On Flawed Assumptions

Many typical implementation shortfalls can actually be mapped back to flawed stakeholder assumptions, permitted by a lack of trust and transparency amongst the stakeholder group. Here are some of the most common:

  • “DevOps is just about automating everything using smart tools”
  • “Changing our culture is critical. That’s why we’ve payed for all staff to attend a two-hour ‘culture change’ seminar”
  • “DevOps is just about getting IT Operations staff to sit next to/meet regularly with developers”
  • “DevOps is just modernising the SDLC”
  • “DevOps is just next-generation ITIL/ITSM”
  • “Our existing deployment pipeline seems sufficient, and we’re too busy with incidents and projects to undertake such a transformation”
  • “DevOps is just for unicorns – it’s politically impossible here”

It’s unfortunately common that implementations are conceived, planned, approved and executed according to fundamentally flawed assumptions. In the haste to over-simplify, inherent organisational complexity is underestimated and the need for a holistic perspective is lost in the wake of the industry hype.

DevOps implementations must test such dangerous assumptions to avoid burning resources and the reputations of IT organisations.

3. Not Putting Culture First

The discussion on assumptions segue us into the heart of DevOps – changing organisational culture.

The number one reason change initiatives fail is because the change did not include a change in culture. Based on our experience, we’d expand that statement to include – and where a change in culture was attempted, it was under-estimated and poorly implemented.

Actual organisational values – the way the organisation’s people actually treat each other day-to-day - as opposed to those that are published by Human Resources, are what really matter. There’s always a delta!

They are in fact what drive an employee behaviour over the long-term, but they can be difficult to see and identify.

Some example assumptions might be “we solve complex problems through individual expertise” and “confident and authoritative direction is the best method of communication and building teams”. In this example, these conflict with the principle of collaboration, and yet everyone describes themselves as a collaborative person. As a generalisation, cultural assumptions are most visible through observing: a) who gets rewarded; b) who gets promoted; or c) who gets let go.

Whether it’s DevOps, or any other change within an organisation, when leaders try to change these assumptions, they run into significant resistance – both overt and passive.

The Jedi Master of culture, Edgar Schein, articulated exactly why this is so intrinsically difficult for both leaders and staff: “because the re-examination of basic assumptions temporarily destabilises our cognitive and interpersonal world, releasing large quantities of basic anxiety.”

We’re always scared of what we don’t understand. Learning increases understanding, reduces anxiety and increases our openness and level of commitment to new ideas.

From learning how to work the new coffee machine in the kitchen, to transforming an organisation, anxiety is where fear and resistance comes from.

Organisational change and learning are inseparable, and hence why The Phoenix Project defines ‘the third way’ as a culture that fosters continual experimentation, taking risks and learning from failure. That is how we can accelerate digital transformation using DevOps.

Want to learn more? Download our DevOps White Paper

In our recent paper Accelerate digital transformation through implementing a DevOps capability, we build on these insights and share our integrated capability model and implementation approach for successfully implementing DevOps.

Further Reading

About the Authors

Rachel Seaniger is a Principal Consultant and the ITSM Practice Lead at UXC Consulting. She has 16 years’ experience in senior service delivery roles including Queensland Police Service and Queensland Health.

Chris Morrison is a Senior Consultant at UXC Consulting. A Business Transformation and IT Service Management specialist, he has over 14 years of experience in the Federal Government central services sector.