The Journey from ITSM to DevOps Begins with Willingness to Fail
ITSM team leaders know they need to adjust to a DevOps environment, if they haven’t done so already. But how to start? We consulted an expert on the subject, and it reminded me of my own journey from the couch to the obstacle course.
I used to watch videos of people racing through obstacles online and I thought damn, that looks like fun. From the couch. With a doughnut. I could get work out in fits and starts, but couldn’t sustain it.
Start with a crazy goal
So I set a crazy goal: I was going to do 200 push-ups a day. Over time, that number moved to 350 push-ups a day, until I felt confident in breaking into other exercises like running hills, pull-ups, burpees, and so on. At the end of September, I’ll run the Spartan Beast in Lake Tahoe and complete the Trifecta – three races of varying distances. The Beast is 15 miles at elevation.
Without that initial goal, the rest would have been impossible. Maybe that goal doesn’t seem crazy to you, but I’m old.
When I discussed how ITSM teams could start changing to meet the demands of a DevOps business world with Rob England, the IT Skeptic, he had some similar advice. Set a crazy goal. Rob instructs ITSM and DevOps teams on the philosophies and organizational structures for optimal results, and he can get pretty deep in the human side of it.
Lessons for Spartans and the service desk
At the time we talked, the similarities between the ITSM-DevOps journey and starting a fitness routine was lost on me. But reflecting on it later, there are some strikingly similar core similarities. Here are a few:
- Be willing to fail: Business in a DevOps environment is fast-paced, and companies must be willing to take chances to innovate and keep up. In my case, I had to continue to set goals I might not be able to reach if I was going to improve.
- Be accountable: Just because you’re experimenting and willing fail, you still have to set targets that you achieve or you don’t. Rob says to make your targets SMART (specific, measurable, achievable, relevant, and time-bound). He says to write them as a user story with defined acceptance criteria and a milestone date, To be race ready, work out with other people and sign up early for a race so you have a target you can achieve.
- Set stretch goals: Stretch goals rally and energize early adopters. As success draws closer, even skeptics want to get onboard, Rob says. To get race ready, er, well, I didn’t really set stretch goals. I’m old.
There are endless goals you can set, depending on the precise situation of your ITSM organization. Rob made a list of seven crazy goals:
- Make performance testing a parallel control instead of a serial one
- Eliminate a piece of written documentation
- Kill a CAB
- Enable developers to create a test environment at will, cloned from production
- Automate change approval of a product
- Set a product‘s deployment window for 2pm on a weekday
- Automate provisioning of users to a service
He generously explains how and why to perform each goal in a new white paper. Whether you’re just planning to update your ITSM practices or are stuck in the middle of your journey, there’s valuable information here. Some of the goals he sets are controversial, like killing a CAB. So I look forward to reading your comments and feedback after you read the paper.
You can find Rob’s paper, Seven Crazy Goals to Start You on Your ITSM Journey to DevOps, on our website. Please enjoy it, and good luck with your journey.
Rob puts strong emphasis on automation, on shifting left to take care of issues early, and on sharing data in an open and effective way.
xMatters integrates people into your toolchains spanning IT Services and DevOps solutions, so data is always available with options for taking action from notifications. Integrating xMatters across your tools and teams allows you to automatically transfer key data throughout your systems to drive workflows forward.