A classic business failure is permeating the DevOps community.
Business experts claim a major reason for business failure is arrogance. This very cancer is starting to dominate the DevOps culture, counter to the very thing that made it successful in the first place.
When this happens, you go from continually integrating to continually sucking.
Now I’m not talking about the healthy arrogance (confidence) rockstar developers have for their skills in coding and not wanting to do full-stack. (See infamous DevOps rant from Jeff Knupp) Which I’m actually cool with and support.
I’m speaking more about the arrogance that shuts down a vital ability required for DevOps engineers… listening. It’s human nature to shut down hearing the input from others when you feel overwhelmed. However, it’s a really bad idea to shut down feedback and input because:
When arrogance enters your DevOps culture you go from Continuous Integration to Continuously Sucking
Failing to listen to feedback loops is a critical flaw that will completely undermine the effectiveness of DevOps ITSM delivery.
This is where Release Management best practices need to be developed. Release Management is probably one of the most critical underpinnings of IT value creation, but frankly has been poorly championed as such. One reason is that Release Management means so many different things to so many different people. To developers it means software updates and code builds. To IT operations it means software installs and config changes. To project managers it means tollgates and communication. To men in their 50’s it means practicing Kegels, but I digress.
Release Management is all of that. However, it’s most important factor is the of actualizing business value from new capabilities.
All the planning, discussions, status updating, testing, coding, complaining, swearing, arguing, and everything else that went into creating this new capability, has no value, zero, nada, nothing, until the business can utilize it. Until it is actually in the hands of end-users to leverage, it has created no value, just risk.
The most important factor of Release Management is actualizing business value from new capabilities.
Then what; Was it what they wanted? Do they like it? Was it what they asked for?
All these are good questions, but are irrelevant at this point. The one simple question is: “What’s working, what’s not?”
This is one of the reasons in my Enterprise DevOps Service Model for IT Service Management, a core repository is collaboration around Enterprise Knowledge. Knowledge is the key to making faster more accurate decisions. Through Release Management processes we are making many “go / no-go” decisions. For continuous integration to work effectively we must harness the decision making through proper analytics, must of which were acquired through feedback loops. Be it monitoring tools, end-user feedback, performance statistics, etc… this is all vital knowledge.
It’s also why PMO as we know it will soon embed itself into more of an operational function. We don’t need PM’s to serve as corporate naggers providing oversight to a release when the releases are small, clearly defined, automated in validation and appropriately aligned to feedback loops. (See my Blog on Operational PM)
So DevOps Engineers, are you listening? If in an effort to increase velocity who have started to shut down those feedback loops, you are in danger of undermining your own success and the business value you have championed to create.
In my next blog (who knows when that will be)… I’ll tackle amplifying feedback loops in context to traditional ITSM structures. Cause let’s face it, having these two camps of “ITIL” and “DevOps” in your organization is seriously starting to become a pain in the @$$.