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.
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 IT service management (ITSM) 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. Click To Tweet
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 they 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 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?
Perception is stronger than truth!
My perception of the two 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 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.
This is a very simple version of a longer discussion I had with a team. Using all of the DevOps buzz words 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 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 Click To Tweet
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. 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.