I was talking with a developer at an event the other day, who was cursing the “cult of DevOps”. Quite rightly pointing out that many of the practices that are touted as “new” and “cool” were in fact things he was doing 15 years ago.
Or at least trying to do.
I agreed with him that much of what is spoken about is not new. And together we also agreed that there was in fact a perfect storm of “new” or improved technologies and practices that had come together, providing “new” opportunities, and of course new and increased business demands. That expectations have changed as much, or indeed more, than the technology itself. Certainly, automation seems to be following as much as leading the new way of working – for enterprise organisations at least.
So we were basically in tune on the technology and opportunity side of things in the IT world. Where it all fell down was when I broached the tricky subject of how services still needed to be run and supported. Clearly his experience in this area was not positive and the whole concept of “RUN” was a nightmare perpetrated by jobsworth “run-book morons” who could only follow instructions (badly), without insight, knowledge, or any level of “common sense” creativity.
I noted that we did have some of these people in Operations, but that I’ve spent the last 25 years or so trying to avoid and remove this problem, often with some success, only to be foiled by some intransigence and lack of co-operation from technical and development teams.
Ah. That didn’t go down well at all…
Anyway, by steering the conversation a little we managed to concur in the end by blaming it all on poor management, lack of leadership, and negligible governance. Which of course ultimately is a fair point – we need leadership and positive guidance on bringing teams and people together, if we’re ever going to get away from the operations/development divide.
Which brings us to DevOps
I dislike the term “DevOps” – it’s internally focussed and doesn’t really mean much to business people. “BizDevOps” has a better focus and is more correct as an approach, however, again it’s clunky and a bit introspective. Some of the focus in the current “movement” can get a bit bogged down by trying to pull everything together when it’s not actually needed.
What’s wrong with Dev and Ops being different things?
Development (R+D) and Operations are actually perfectly reasonable and well understood terms in wider (non-IT) business. We shouldn’t worry too much about trying to completely merge them. Train engineers and drivers do different things – part of the same industry. We don’t need to invent ‘Drive-eneers’!?
We all do Dev and Ops to some extent
And of course the value and objective of the DevOps “approach” is to foster collaboration and more close working; to avoid unnecessary waste and delay that is purely caused by people and process; and to improve productivity and speed through a focus on common aims and metrics, with the explicit goal of achieving business success and outcomes.
The fact is that we can do these things collaboratively but we can also do them in our own teams – in fact many of us in service management have been doing a lot of this stuff for years. We just need to call it out more and recognise that we may already be “doing DevOps”. I.e. if we’re trying to be more efficient, removing unnecessary time delays or blockages that can be by-passed to improve customer experience, or dealing with issues (problems) strategically and quickly, and eliminating backlog or technical debt.
The real challenge in making DevOps work is of course how to move from a culture of process and control, to a more flexible and open way of working. This doesn’t happen easily or quickly and we shouldn’t beat ourselves up expecting to completely change overnight.
How about we start doing “Incremental DevOps”, where we look at flow, use visualisation, use business metrics, become more open, use automation where we can, improve our approach to testing, and tackle out backlog – all of these are “DevOps” activities that we can do now without a major programme.
Barclay Rae
Barclay Rae has extensive experience as a consultant, analyst and subject matter expert in IT Service Management. He is the Lead Editor of ITIL 4 Create Deliver Support (CDS) Managing Professional guide, a member of the ITIL 4 Architect team and a co-author of ITIL Practitioner.
He also has considerable business and management experience in the industry, both as a consultancy vendor and also working with industry bodies and vendors such as SDI, AXELOS, APMG, and Axios. He brings industry and subject knowledge to ITSMF UK's strategic direction, as well as practical experience and commercial skills in running a small business organisation.
