My presentation at the upcoming itSMF UK conference is the latest iteration of my “Kill DevOps” talk. I presented the first version in 2014 in Beijing and have probably gone through 20 changes of it since then. This process of continual refinement is completely consistent with the message behind the cryptic title. “Kill DevOps” refers to an ancient Zen saying about a monk’s journey towards enlightenment and awakening. If you think that you’ve found it, think again, because you never will. It’s the same with DevOps: it’s about continuous experimentation and learning.
In terms of practical guidance, I’d like to share a few major takeaways in terms of critical questions to ask yourself.
What problem are you trying to solve?
Most people invest in DevOps in order to speed up their development and deployment processes, while not compromising – and often even improving – the operational behaviour of their information systems and services: reliability, availability, security. Whether DevOps will save costs is up for debate. Yes, it makes several activities more efficient, but on the other hand it’s quite an investment to adopt DevOps culture and practices. It won’t really help you come up with ideas for new functionality – that’s more in the Agile domain. It does however, have the potential to make IT a better place to work. Treating people like human beings is one of DevOps’ tenets. So if you’re after higher speed of change, better operational behaviour, and fun, read on.
Can you afford the benefits?
People are using DevOps’ cultural norms and technical practices in various ways and in various kinds of organizations, but the common success factor seem to be an inner drive and conviction that things need to change radically. Although many have gone before, it’s still a leap of faith. I often make the comparison of the transition from the dark ages to the age of enlightenment. The dark ages of IT were characterized by rigid project plans and processes , backed up by service levels agreements that polarized the relationship between the business and IT. The age of IT enlightenment is more responsive, emergent, and inclusive. Multidisciplinary collaboration is the name of the game, with a high degree of trust between all involved. This includes managers, who are now challenged by managing with their hands behind their back – not all are up to the job. So the question to ask yourself is whether you’re prepared to go through some pretty rigorous organizational and cultural change in order to get value out of DevOps.
Is the DevOps horse suited to your course?
DevOps flourishes in conditions of organizational complexity. I’m using the term complexity to denote a loose coupling between cause and effect. One of the experts on this field is Dave Snowden. Referring to his Cynefin framework, Snowden distinguished between five domains:
- Obvious, in which the relationship between cause and effect is obvious to all
- Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge
- Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance
- Chaotic, in which there is no relationship between cause and effect at systems level
- Disorder, which is the state of not knowing what type of causality exists.
The deterministic domains Obvious and Complicated are pretty good territory for structured project plans and processes, because you know more or less how things respond. When the conditions are less predictable however, a more emergent approach works better. Snowden calls this Probe – Sense – Respond. Because the non-deterministic nature of the “system” means that a fail-safe solution is unrealistic, it’s about taking small safe-to-fail experiments. This corresponds with DevOps’s culture that fosters continual experimentation, taking risks, and learning. Under conditions of complexity, you’ll get the most benefit from riding the DevOps horse. Or unicorn, if you work at a spangly company like Amazon, NetFlix, Google, Spotify, or Etsy.
If this blog has piqued your interest in my presentation, then there’s still time to register for the itSMF UK conference. With my presentation just one of many that will help you to consider your company’s status quo and provide guidance on where it will need to be in the future.
Finally, if you want to talk about ITSM, or feel free to get in touch with me on LinkedIn, Twitter, or by email – email@example.com.
Mark Smalley is an IT Management Consultant at Smalley.IT, specializing in application management and business information management. He is affiliated with the non-profit ASL BiSL Foundation, APMG International, GamingWorks, and AllThingsITSM. Mark is an inaugural member of the industry initiatives SMCongress and Taking Service Forward. Also know as The IT Paradigmologist, Mark has spoken to thousands of IT professionals at more than 100 events on four continents.