“Do you understand the words that are coming out of my mouth” This classic quote from Chris Tucker to Jackie Chan in the movie Rush Hour has been used by every parent, and unfortunately every business analyst or business relationship manager when speaking to IT. “Do you understand the feedback that is coming out of my mouth?”
An allure that DevOps offers is bringing the builders closer to the operators. Enabling the person who has the skill to create, the designer / developer / engineer, the ability receive direct and immediate feedback to the usage and outcome of what they created.
Here’s why that matters: The person with the need, the one who will utilize the thing created, may not always fully understand how this newly created solution will solve their need or change their capabilities.
So while at a high level we can craft a requirement, as we know the success of the outcome is always in the detail of the usability. I know I can build a world class request platforms, I’ve done it hundreds of times. However, if my sponsor doesn’t love it, and his team doesn’t use it, then it will not survive the hardest part of technology… user adoption. I also know that my sponsor and his team will have many “wish I hads” but my team has limited resources and can deliver only “I must haves”.
Here is the first point on feedback traditional ITSM fail to recognize and thus their rigorous processes contradict DevOps ITSM methodologies:
There is no such thing as A business requirement. Only refining of requirements to meet A business outcome.
ITIL ITSM’ers talk a lot about THE business requirement, and designing, transitioning and operating to THE business requirements. Capital A’s and THE’s are intentional as the mindset in traditional ITSM is that there is a singular business requirement. As if the business owner / analyst / relationship manager, knew with absolute certainty what the need is and IT should be a good service provider and just deliver to it.
Well, I hate to break the news to all you ITIL fans, but that elusive Business Requirement is a MYTH. DevOps bashers will say DevOps only works for purple unicorn companies, in other words very rare and unique organizations. Well the truth is the organization that gets THE business requirement right is actually the purple unicorn. IT delivering to that is even more rare because:
A) This BRM you call Customer is not the customer, they are a partner in solving the problem and they are not always right.
B) They really don’t know what they need, want or have… what they know is that they have a challenge, the right solution… they’ll know it when they see it.
C) By the time you created it, deployed, elicited feedback and took that to the creators, the “understanding” has been lost in translation or the need as already changed. But thanks for playing!
Marry this elusive business requirement with a set disconnected and confused set of internally focused service providers and … “What we have here is a failure to communicate”. Another classic quote from the 1967 movie Cool Hand
Luke starring Paul Newman.
Hopefully I’ve covered the WHY.
Let’s talk about the HOW.
So your organization has just spent the last 5 years convincing management that you need ITIL training, new Service Management tools for managing Knowledge, Change, Requests, and so forth… and here I am telling you your processes and methods are not going to work. Well sort of, but completely so don’t mentally shut down on me yet.
What’s the value of ITIL? It’s never been design, transition or operate. It’s about improving the business outcome, continually improving the way IT manages it’s activities.
ITIL’s value is not in process improvement, it’s in its ability to guide towards business improvement.
ITIL shops (whatever that means) can make great gains, if they learned to increase their feedback to focus more on business outcome improvement and less on process improvement. So if you read my blog before you know I’m overly analogous… I don’t plan to disappoint.
As a musician when I hear the word feedback, I can’t help but think of the piercing noise that comes from my amp when sound loops through my pickups and then is project back out the amp in an infinite loop. (If you really want to geek on that check out the master of Feedback Jimi Hendrix video
Feedback Step 1) Get plugged in!
If your axe (this is what guitarist call their guitars… don’t ask) is not plugged directly into your amp feedback will never happen.
If you call yourself an ITIL shop, or say you are doing ITIL (I still really don’t know what that means) more than likely you have created a bunch of job functions based on the roles of ITIL. Problem Manager, Incident Manager, Change Manager… etc.
When you are structured like this role is actually more of a process owner, and general practitioner. With that you loose the real connection to the effectiveness of the service being delivered and the flow of work that goes into the deliver it. What really needs to happen is the functional expert needs to have a direct line of site and channel of communication to the feedback of their work. This requires a complete “re-think” on the Single Point of Contact structures. It also requires the functional owners to play more of a direct role in the after incident feedback, change review, and problem review processes.
Feedback Step 2) Increase the gain!
After your plugged into the amp, turn your gain up to increase resonation of the higher frequency tones.
When we have higher frequency. In other words, more releases happening. We need to increase the frequency of data we are taking in. Thus our monitoring, surveying, closed loop validations, need to be increased as well. We might need to increase the polling frequency on our Nagios. Call our BRM’s proactively and ask about rumblings in the end use community. Maybe run incident matching processes more frequently to determine if end users are experiencing issues.
However we are collecting information on quality of service, we need to increase our sample rate. Change, Sample, Adjust, Repeat!
If we are simply measuring by process, we will never see this. Thus, creating smaller teams who can cross-functionally create things and work closely with the those who utilize it will help us improve the outcomes.
Feedback Step 3) Turn up the volume!
Plugged in, gain high, it’s time to turn it up… but do this cautiously or you’ll get: “I’m afraid you are just too darn load Next, Pleas” Come on I had to get this quote from Huey Lewis in Back to the Future
in here some place.
Make changes and release more visible to the end-user, business and customer community. Turning up the visibility will encourage them to be more vocal and willing to share this feedback. But word of caution! This is not a pass to go all HDI on them with 500 surveys. Be smart about this. Utilize in-app notifications about changes and releases if it’s an app roll-out. A simple upper right hand screen pop-up can do wonders.
“We just released some new features, how’s it going
A weekly what’s changed email can be huge, but be a marketer. Brevity and clarity on the call to action. For Example:
Here are some modifications to systems this week and we want to ensure it’s improving:
Network speed to increase speed
New updates to desktops to improve security
New pricing system updates to improve quoting
Redesigned partner portal for quote tracking
This increased volume will be welcomed, and you’ll soon see your chorus of feedback is belting it out.
This is really going to challenge some of your traditional ITSM mindset and reporting structures, but the bottom line is creators need user feedback, and we need to get them out in front to help tune that outcome.
Feedback Step 4) Strike with intent and listen closely!
You are now ready to hit a note. Strike it hard and then slowly point your guitars pickups at your amplifier. At first your guitar will get quite, then out of nowhere this awe inspiring squelch will make you sound like a rocker.
If you start releasing your next set of updates without waiting for the feedback, then you will never know if you have the right settings. It’s human nature to get excited and want to move fast. Resist that temptation, execute the change with the steps listed above and now listen. If you can’t hear, turn up the gain or volume, until you hear it.
Then you can adjust appropriately with better precision again.
Soon you will see the feedback is coming, people are telling you what’s working and what’s not, and you are in a position to accurately and effectively execute on it.
This is why DevOps can work when done right.
- We know THE business requirement doesn’t exist, and it will be a series of hits and misses to tune it on the best delivered outcome.
- Those creating, building and changing are plugged in closer to those using the technology service.
- We are setting our metric collection based on the key things we need to react to and increasing polling frequency.
- We are increasing user feedback and quality measurements maximize the correlation of release to benefit or release to impact.
- We are executing, listening, reacting. We will not react until we have heard clearly the feedback.
DevOps and Agile done right mean we execute with precision. We have increased and enlightened our ability to make decisions.
So this ITIL thing, what are we going to do with it… well one thing I love about ITIL is you can do whatever you want with it. It’s a big hunk of clay that you can mold into the superhero of your choice. I wrote in 2015 is ITSM vs. DevOps Battle Royale
. In my next blog I’m going to hit on specifically areas of ITIL vs. DevOps. What really are the things that are different, what we can keep, and what needs to go for an IT organization to stay high performing.
Tell me what you think of this post: