I wrote some early thoughts on this on twitter, but there was a great blog post written from a recent DevOpsDays conference that got me thinking.

The original post is here - https://www.darkcoding.net/software/a-developer-goes-to-a-devops-conference/

Graham very ably represents what he got from the day, and has given much feedback on it as a positive experience (certainly my findings on DevOpsDays conferences too). The overall feedback had me wondering though - 'What is DevOps'?

Wikipedia to the rescue, and it gives us:

“DevOps is a set of software development practices that combine software development (Dev) and information-technology operations (Ops) to shorten the systems-development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.”

Which summarises nicely, though the wikipedia article is also quick to highlight "Academics and practitioners have not developed a unique definition for the term "DevOps.""

Should we jump to the approach in The Phoenix Project that talks of 'The Three Ways'? Should we look at the CALMS (Culture, Automation, Lean, Measurement, Sharing) model? Should we look at maturity models?

Where does SRE fit in? What about when you add in 'things' to DevOps - 'DevSecOps' for example?

Ultimately, I think DevOps falls into the same space as Agile (deliberate capital A) in that it is a 'One term, a million definitions'. As someone put it on twitter in my thoughts 'does it matter?' and to some senses, it doesn't. But DevOps, like Agile is becoming a snake oil sales term to some. There is DevOps certification, many jobs have the word DevOps in them, and when the use of a term becomes more ubiquitous, having a shared understanding of that word really can help. What it's called and how it is represented may not seem greatly important, but if we're talking with audiences wider than just tech, words matter.

How do we fully understand what DevOps (or Agile) mean if they have many definitions?

This comes to the heart of some of the models really - the 'C' and 'S' in the CALMS model above, some of the thinking in the agile/lean space. Have a conversation!

Start to understand the 'what' behind the term for each person or org that you engage with.

If you see an advert for a DevOps Engineer (for example), that gives you an indication of some things that that company will likely care about.

  • They will care about moving fast.
  • They are likely to have a customer focus and care about the delivery of value to that customer.
  • They are likely to measure a lot of what they do so they can continually improve.
  • They will likely favour automation through that delivery of value (so automated testing, automated infrastructure, automated 'all the things')
  • They will be likely to follow some form of agile/lean or lightweight process
  • They will likely collaborate with the people involved in delivery of value
  • They will likely have 'shifted left' on quality and security
  • They will likely have thought about and solved some of the cultural drivers around the space and not just the tooling
  • They will likely be experimenting and learning as part of their role
  • They will likely have a healthy view on 'failure'

Will DevOps teams manifest all of these? Of course not. They may do some of these to greater or lesser degrees, and they may well do significantly different things.

The important thing here is the conversation. When someone uses the word DevOps in a conversation, delve into the 'what'.

'That term gets used a lot, I wonder if you could help me understand what it means to you in this context?'

Does it matter what the outcome of that conversation is? Of course not.

How do I know if their DevOps is good DevOps?

The State of DevOps report is a great source of truth for some of the behaviours that highly effective teams have in this space. It's really worth a read, and a read of the book that looks at this longitudinal study of data - Accelerate by Fosgren, Humble and Kim. Dig into the data, and understand what the best are doing, what practices they are following, what their ways of working are. You will then readily be able to have that conversation about the what.

Is the misconception of DevOps across the industry a problem?

I draw back to another great success story - the rise (and rise!) of Agile. The word itself conjures many different views in many different people - what it is to 'be agile' (some people will even 'do agile' I hear!)

This is nothing more than an indicator of success. If you look at the use of the word 'agile' it has risen consistently since google started trending (though be careful, as you will see on the link, it seems you can't talk about agile without talking about waterfall!)

DevOps has really seen that hockey stick uptick in popularity since about mid 2013. It's only getting more popular. It's in loads of job titles, companies are blogging about it, it's getting a massive amount of air time.

It doesn't matter that the term is broadening (perhaps a better term than misconceived) to include many more practices and many more approaches. Ultimately what is important is the alignment with you - and for that, you have to understand the 'what' when someone uses the term (be that Agile or DevOps) and see if it fits your expectations.

As with Agile though - beware the snake oil peddlers who'll attempt to lead you into a costly adoption pathway. The explosion of the term and the wider understanding of it means that it's far easier now to become 'DevOps Certified' or have some formal qualification in it. Thar be dragons!

A rose by any other name really does smell as sweet, and with DevOps (as with Agile) a term that is growning into itself isn't a bad thing - just be sure to talk about it and arrive at a shared understanding to leave no ambiguity.