DevOps and ITSM – the Perception of Different

DevOps and ITSM Perception

Below is a famous image that’s used to help people appreciate that what you see may not reflect what others see, in which case you need to find a way to bridge the gap of understanding and perception. It’s something I believe is highly relevant to the DevOps and ITSM relationship.

DevOps and ITSM perception image

This difference in perspective is something that I repeatedly see when talking to people who happen to sit on either side of what’s commonly a DevOps and ITSM (IT service management) divide.

To help, in this article I offer up a way in which to help with these different perspectives.

Are you sitting either side of a #DevOps and #ITSM divide? Here @DanielBreston challenges you to change your perception of both and to start talking in a common language. Share on X

DevOps and ITSM

DevOps and ITSM (whether your favorite flavor is ITIL 4, VeriSM, or something else) definitely suffer from a “perception of different.” There are two silos of philosophy on how to create and manage technology in an organization:

  • Different roles
  • Different key performance indicators (KPIs)
  • Different tools
  • Different practices
  • Different perception in the business.

But are DevOps and ITSM really that different?

All of you have an image of what IT should be doing for a business: obtain a request to do something, create it, test it, deliver it, support it, and improve it. Bring that image into your mind, keep it high-level if you can, and reflect on what this looks like if diagrammed.

Ready? Now, look at the two DevOps and ITSM images below. How close are they to what you thought the image should look like? If you didn’t know which was ITIL or which was DevOps, would it matter to the perception you created? But, knowing which is which, does it affect how you perceive a diagram compared to your perception?

DevOps and ITSM – the ITIL 4 Service Value Chain
Source: AXELOS – The ITIL 4 Service Value Chain
DevOps and ITSM – Atlassian DevOps Image

DevOps and ITSM – Perception is stronger than truth!

My perception of the two DevOps and ITSM images above is that they’re the same. They both visualize the practices of achieving a customer outcome based on the use of technology and the practices shown are the same. Nothing different!

Don’t believe me? Please try this DevOps and ITSM exercise: Take the first picture and explain it by using no ITIL words, just DevOps words. For example:

  • From my Jira board of work to do, I take a request
  • After analysis and agreement by the team, we begin work
  • The code created is integrated with other code after passing certain tests
  • Based on these or further tests, we allow the code to be used
  • Monitoring along the creation lifecycle for issues, and again after live, helps us to know what we need to improve
  • Which drives work back to the Jira board for our next cycle of work.
Remember: The customer doesn’t care about your incident or problem management team or process. They simply want their issue resolved, so create a resolution language and practice – @DanielBreston #ITSM #DevOps Share on X

This is a very simple version of a longer DevOps and ITSM discussion I had with a team. Using all of the DevOps buzzwords from the 3 Ways, Continuous Integration to Continuous Deployment (CICDCD+), the 5 ideals, automation, containers, sprint, and others, I explained the first image.

Using no ITIL language whatsoever. The audience was flabbergasted as they saw their perceptions fall away.

I then challenged them, and I now challenge you, to do the same with the second image. Explain it using ITSM words. No DevOps or Agile words allowed.

My tips for addressing this IT perception of different

Mitigate the perception of DevOps and ITSM being different by creating a common language for performing IT activities, the roles of IT, and the metrics of IT. The best words should reflect the “perception of customer.” The customer doesn’t care about your incident or problem management team or process. They simply want their issue resolved, so create a resolution language and practice.

Your customers don’t care about your ContinuousEverything technology capability, they simply want great experiences – @DanielBreston #ITSM #DevOps Share on X

Your customers don’t care about your ContinuousEverything technology capability, they simply want great experiences as they visit your company website. So, create experience words for your practices.

Importantly, don’t have a team of people who removed from these activities create the language. These words and metrics and practices must be owned and developed by the people doing those tasks daily.

Change the perception and see what truth (reality) you can create in terms of DevOps and ITSM. Please, let me know how your perceptions change and, if you need advice or even a facilitator, I’m happy to have a chat with you.

Please use the website search capability to find more helpful articles on topics such as continual or continuous improvement, service desk team member development, ITIL processes, IT service management (ITSM) including the incident management process and service level agreements, service time to market, the problem management process and root cause analysis, dealing with service disruptions, DevOps teams and DevOps practices, knowledge bases, design and transition practices, managing production environments, ITSM stats from the United States of America and other countries, and service operations.

Daniel Breston
Daniel Breston
IT Management Advisor at Independent

Daniel Breston is a 50+ year veteran of IT, ex-CIO and principle consultant, multiple framework trainer, blogger, and speaker. Daniel is on the board of itSMF UK and is a Fellow of the British Computer Society. Daniel may be retired, but he will help an organization if requested. Not full-time, but hey!

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

Leave a Reply

Your email address will not be published. Required fields are marked *