How to (Un)Confuse People: “If It Brings Joy, It Must Be DevOps!”

Credit where credit is due, so let’s start off by admitting that this lovely quote is not mine, but from a man that some of you will surely know: Kaimar Karu. 

The first time I heard it, was when I was working hard to become a trainer for The Phoenix Project, a business simulation game by Gamingworks. But it stayed with me ever since. Both me and some of my colleagues now re-use this phrase quite frequently, ‘stolen with pride’ as it were.

Whenever we are discussing ‘What is DevOps?’, we notice that people can get very confused. They get lost in a vast ocean of terminology and buzzwords, all related to some form or flavour of BizDevTestSecOps, Agile, Safe, Scrum, ITIL, CI/CD, Value Streams, Spotify, Sprints, Value Driven Service Management, Retros, MVPs, SRE, BDD, TDD, Cynefin, Agile Manifesto, Reactive Manifesto and countless countless other.

With so many of these concepts within the same 'eco-system', it can be hard to find your way. Especially since many of them are touching as friendly (or sometimes unfriendly) neighbours, overlapping (at least in some part) or really competing for attention.

So let’s come back to the above mentioned quote, because it works really well as a basis to find some answers.

What also strikes me, running into this question from different angles, is that this confusion seems to be widespread: It's among both IT and non-IT professionals, with varying degrees of maturity and seniority, both very hands-on operational roles and members from strategic leadership teams and across every industry or vertical you can imagine (Finance, Government, Health Care, …).

Whether it’s in Recruiting, Software Development, Finance, Operations, Security, Compliance, Marketing or other still, people in many different departments all seem to be caught on a raft on this wild river of Accelerated Digital Transformation. And while everyone is still trying to look for the map, the oars of their ship or a captain, sometimes it may look as if these “new” methodologies and buzzwords are telling them they may not even need the compass they are used to at all anymore.

So let me try to shed a little bit of light in the darkness. And remember: I’m not a techie. I’m not a developer, a tester, an infra-man or a security person, I’m not even – in the purest essence of the word- a real classical “IT-guy”. Which means I have had many of the same questions and doubts when getting into this stuff myself in the past.

What I have found, over the years, is this:

Firstly, when it comes to these topics, mostly everyone is trying to achieve the same things, albeit sometimes in different ways, at different levels of thinking and with different structures or focus areas.

The core idea, the red line, is that IT (both software and infrastructure) is going to save the world. Or at the very least we have by now understood that it rules or eats the world, so it’s absolutely crucial for most organizations. In trying to keep up with the digital transformation, organizations are therefore looking for ways to deliver more value to their customers (whether those are internal or external), build better software, be innovative, and do those things faster and cheaper. And all of that hopefully in a psychologically safe and empathic way.

Secondly, you need to understand a bit of history: For a long time, the world of IT had very strong divides between different departments. Development, Testing, Security and Operations all had their own way of working and their own areas of responsibility. Through the years, and – this is important - at different moments in time, each of these silos have undergone their own renaissance(s), all of which have brought us to this moment in time where we have all of these concepts available to us at the same time. What you need to realize, is that they are not mutually exclusive. Instead, you can pick and choose what works for you. And if it brings joy, it must be good, right?

Now, here’s my version, in a nutshell. What follows is a brief attempt to simply clarify a few things and unconfuse people. It uses some definitions from specific methodologies, frameworks, organizations, guidelines, best practices etc. which I find useful. So bear with me. And yes, I’m picking only a few, because they happen to be the most common in my current world, and you can’t have everything ;-).

DevOps is a cultural and operational movement that fosters collaboration to enable high-performance IT to achieve business goals. (This is the DASA definition, there are other you may want to look at as well for sure).

So in other words, this is in my personal opinion, an extremely open and welcoming definition, just saying: “If it helps you in achieving what you need, then it’s DevOps”. So DevOps, as per this definition, becomes an overall connector and enabler, harbouring everything good and positive you may want in the world of high performance IT.

Important to understand, is that for your organization to be able to function as a highly-performingt IT organization, you have to focus on 3 things to make this work:

• Culture and mindset on one end
• Proper tooling (to support your Continuous Integration/ Continuous Deployment and Continuous Delivery pipe line) as a second pillar.
• Selecting and applying specific practices which you can apply to make this happen.

These 3 will help you build the right organization, use the right tools, and make it work for you.

Now, a bit more on some of other the terms, practices, frameworks, methodologies and confusing buzzwords

Agile practices and development techniques have sprung from the Agile Manifesto, and involve the discovery of requirements and development of solutions through the collaborative effort of self-organising and cross-functional teams and their customer(s)/end user(s). (Wikipedia)

To my mind, this translates to “Agile focusses on a specific way of building software and a way of thinking, and making sure that you have the right team structure to do it”. (Also note that “Agile” is often put in opposition to “Waterfall”). (For more details on the Agile Manifesto: check https://agilemanifesto.org/).

Then we have - as a bit of a special one- SCRUM, which is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is a lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems. (scrum.org)

Again, let me tell you how my mind translates this: The SCRUM framework advises and guides you on how to do this in reality. It explains a number of roles, which you need in your organization; it describes some events and artefacts, and has a specific set of values (You can read all about it here: https://www.scrum.org/).

Now, from Agile and SCRUM, it is an easy step to things like SAFe, Spotify, LESS and a few other, which are simply nothing more than Frameworks and Organizational models, helping you and providing guidelines, often based on a specific set of their own (slightly deviating) principles. Companies may or may not choose a specific framework, based on their own very specific needs, their own challenges and transformations.

LEAN is also one worth mentioning, simply because it always helps. If you look at the Six Sigma definition, Lean refers to any method, measure or tool that helps in the identification and elimination of waste. And that is always a good thing, whether you are looking at IT, manufacturing, or simply at how you and your colleagues do your job and any processes or activities you and your team are involved in. So this fits quite nicely with all the rest, and it excels at doing just that: removing waste.

And then we come to what - in my humble opinion - has been the missing link: (Value Driven) IT Service Management, with ITIL4 at the heart. ITIL is a framework for IT and digitally enabled services. It provides comprehensive, practical and proven guidance for establishing an effective service management system (Axelos).

In short, it’s pretty simple, when my mind translates this:

For me, it is one of the only places – and working with it for over 20 years, I happen to think a really good place - where you can find advice, guiding principles and an understanding of the service-side of things. It provides guidance on how to manage a service with everything that entails, rather than on how to build your software, or tell you how your teams need to be organized, or which tools to use. And yes, it has evolved a lot over the years. That being said, I think it is all too often overlooked when discussing “Shift-left”, that people from the “left” (dev, test,..) also need to understand the “right” (Service mgmt and OPS), and that they don’t need to reinvent the wheel.

Now, hopefully the above overview already brings some clarity and structure to some of these topics and how they interact.

So let me conclude: most of these concepts work really well together, as long as you remember it is not a matter of “OR”, it is a matter of “AND”. I have not seen a single organization that uses any of these in a “pure” form, so don’t worry about that.

If it works for you, it works! And if it brings you joy, you should embrace it!

Do you have questions after reading this blog? Can we help you with your DevOps activities? Either way: don't hesitate to contact us. We'll be glad to help! [email protected]