Who is driving your DevOps strategy?

Within an organisation, there are many candidates who can be the driving force behind the adoption of DevOps. Typically this comes from the bottom up; development, testing or operations who want to do away with tedious and repetitive manual tasks and automate stuff, using the latest cool tools and frameworks. However, over the past couple of years more and more C-Level execs are showing an interest in DevOps; I can bet that if you look into the bios of CIO.com Top 100, the majority will reference some sort of movement toward DevOps usually through an Azure or AWS programme.

It may be that the tooling vendors are driving your DevOps vision within your organisation...

Looking back over the past 10 years or so, when you think about agile transformation, there were and are many reference points which usually form the core of a target operating model such as the Agile Manifesto, SAFe, LeSS etc. If these didn't exist, would you have expected an agile transformation or operating model to be based on the functionality of Jira, VSTS or a HP or IBM toolchain? I don't think so. Jira has progressed a long-way yet it can still be a highly complex mess, VSTS will push you down the road towards a full Microsoft stack and HP and IBM, well....

Fast forward to 2019, and there are not many reference points for DevOps aside from a couple of interesting books and the 'Spotify model'. This is probably as DevOps means different things to different people and organisations e.g. "it's about automating an end-to-end pipeline", "it's about bringing our infrastructure and dev teams together", "it's about bringing our service desk teams and developers together", "it's about having self-service infrastructure" etc. etc.

However, one common theme across many of the organisations we engage with is that it seems that most DevOps strategies/roadmaps are heavily influenced by a selection of vendor tools such as Terraform, Docker, Azure DevOps etc. The conversation flow usually goes "what's your vision for DevOps?" and the response will be something like "we are using Terraform, Kubernetes...and here is our pipeline architecture"

Whilst these tools may seem great (and hey, we are official partners to them!), they are just tools.

So, who should own the DevOps strategy and vision?

The main analyst firms suggest that any company who wants to survive the next decade, should be re-inventing themselves as a technology company or face disruption or annihilation by a 'new kid on the block'. Therefore, the DevOps strategy should be an exec level initiative as it is a critical factor for any digital/agile transformation and delivery success, not just a geeky technology buzzword.

I like the top two points raised in this article: https://searchcloudcomputing.techtarget.com/tip/Seven-deadly-DevOps-strategy-sins-and-how-to-avoid-them

1. Failing to plan. Attempting to adopt a DevOps transformation without a clear plan for success will almost guarantee failure. A very common mistake that occurs is that a bunch of smart people start to experiment with pieces of the DevOps universe and quickly get way out in front of their organization. Unfortunately, these pioneers are at risk for career pain without the commitment and support of the organization and senior leadership.

2. Failing to fund. A client once quipped, "Strategy without a budget is just a dream." These words are particularly true of a transformational program like DevOps. The other side of the DevOps initiative is flush with benefits, including lower costs, higher agility and better quality. However, you don't get to the other side without a serious level of investment in people, process and technology.

Your DevOps strategy should be directly linked with business goals

My advice would be to align your strategic business goals with your DevOps capability, taking a context-driven approach to both legacy and greenfield projects. DevOps is meant to provide the optimal way to develop experiments, gain feedback and iterate, whilst also provide the capability rapidly change direction at any time based on the needs of the customer. This means that by linking it with your business goals you can focus on building the 'right thing' at the 'right time' and reduce the waste spent on dead-end projects or missed deadlines.

I don't know many organisations who would say their business strategy depends on a set of vendor solutions, so don't do the same with your engineering capabilities.

A more appropriate answer to "what's your vision for DevOps" should be something like "we want to bring transparency, speed, security, quality, repeatability and scalability to how we design, develop, support and measure the impact of ideas".