Continuous failure when DevOps goes wrong - Matthew Hooper VigilantGuy Digital Transformentalist - Create High Performing IT

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:

A) Knowing you got it right
B) Confidence you did not create failure
C) That you know better than the user what they want
D) All of the above – yeah some of you exist out there.

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?”

Why?

3 reasons:

  1. It is a myth to think that someone out there knows the perfect “Business Requirement”.   Businesses, especially in this digital age, are learning as they go.  Thus they make assumptions as to what the business requirement is, and IT works with them to validate that assumption. Yes this challenges the mythical “Business” ownership position ITIL preaches to Service Providers… but we are not a service provider, we are a partner in making our company rock through testing, learning, trying, experimenting and improving.
  2. No such thing as a total failure, or a perfect fit.  Some things will work well about the design, user experience, or functionality, and other things won’t.  Our objective is to learn what works, harden it and increase its resistance to fragility.  The things that don’t we re-work to improve. So forget that whole Bi-Modal thing… it too is a myth.  What we are really focused on is what functionality, design or capability will become core, and what is disposable.  Core get’s monitored, backed up, HA & DR focus.  Disposable is throw away that we learn from.
  3. Better is the champion of right.  If we’ve never spent any time in a startup and our career has mostly been large organizations or government, this can be a hard mental pill to swallow.   However, what studies have shown us time and again, is that working towards getting a massive release “right” costs and fails substantially more frequently then iterative improvement processes.  (See Puppet Lab State of DevOps report)   Thus create an organization of continual improvement, not just continual release. Focus on what is making us better by listening not only to end-users, but to the security team, the infrastructure team, consultants, management, finance.

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)

screenshot-2

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.

screenshot-3

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 @$$.

Written by

Digital Transformentalist Twitter: @VigilantGuy http://twitter.com/vigilantguy Linkedin: http://www.linkedin.com/in/matthewbhooper Web: http://www.vigilantguy.com Matt Hooper is an industry advocate for Service Management strategies and best practices around Enterprise Service Management. For over 20 years Matt has instituted methodologies for business intelligence and optimization. Leveraging technology to drive business outcomes, he has built an industry reputation for his highly effective approach to creating value through Service Management. Matt is active on Social Media known as VigilantGuy, and co-hosts the weekly podcast: Hacking Business Technology. HackBizTech.com

Leave a Reply

Matthew Hooper

Digital Transformentalist