DevOps? It is really hand in hand?

Anyone who has ventured into this area in the real world will instantly be struck by the universal usage of the term “DevOps” for areas that are not actually DevOps.

I think we are all in agreement that the use of the term DevOps relates to a mindset to reduce barriers to increase speed. Speed to deploy, continual integration which ever works for you.

The issue comes when you start looking a little deeper. I met a DevOps engineer the other day who said they worked as part of a DevOps team. I had visions of continual integration, speed etc. However turns out that he is actually a Cloud Infrastructure Engineer supporting Cloud Infrastructure and collaboration tools. In my mind not a DevOps Engineer.

The fact is there is probably no such thing. If you look at Agile methodologies such as Scrum the scrum is made up of diverse teams who may well be utilising a DevOps model / approach which incorporates........ wait for it.....

Diverse teams supporting development and operations across applications and infrastructure.

So why when one would think this is actually very simple is the market place riddled with DevOps engineers who actually have nothing to do with DevOps.

It is time the industry got to grips with terminology. The use of DevOps should relate to the mindset that underpins the utilisation of a methodology which can be applied to Development and Operations but even then there remains a stark question.

If you are an Agile proponent please do not get too upset and that is Service Assurance. Most DevOps approaches using diverse teams focus on speed. Whilst there is quality built in to the Development activity the fact is that the focus is on the speed and the deliverable and not the ongoing service, especially when the DevOps approach is being utilised for developing / enhancing an MVP which is in use by end users.

This then raises the conundrum of how to evolve existing Operational governance and expertise without losing the speed. This then leads to questions such as how do I route and prioritise incidents coming from live users into the backlog and into immediate action (possibly impacting a Sprint for example). The current DevOps approach whilst excellent at driving change and speed etc does not address the Ops side of the equation to the same extent as the Development side.

This is an area that is developing and needs to get more focus in terms of organisation and processes but also the use of automation.

One answer is consideration of a hybrid model that leverages the best of approaches like ITIL but also allows the ongoing ceremony that is associated with sprints (for example).

This is not an easy thing to do and is dependent on a number of factors, what is the level 1 setup, is there a triage mechanism that can feed the backlog and route Incidents of a certain type or priority. How does this integrate (ideally automatically) into your collaboration tool (e.g. JIRA). This raises the question of how the next generation of Service Management Tools integrate or are part of a wider DevOps toolset which supports Incidents / Problems and inputs / artifacts / workflow required for Agile methologies.

Whatever the approach  Level 2 / 3 Operations need to be part of the sprint velocity whilst also maintaining the integrity of SLAs / Business KPIs supporting business needs.

The wrapper around DevOps needs to maintains the business and Service focus to allow DevOPs to act for all stakeholders. This will mean the Product Owner has to have a wider remit once the MVP is live and is changing supporting the ongoing Service assurance / performance aspects with the business. Increased speed and value is great but there has to be consistency and quality to the Service being provided.

This also means that the traditional Service Delivery Manager has to change. The traditional ITIL  approach for example needs to change to align to new ways of working and cultural changes. SDMs will need to become the Scrum Master for live Service,  working within ceremonies to drive and maintain the Service agenda. 

This article is the views of the author and not any other party.