I was recently talking to an engineer friend of mine over of a cup of coffee at a conference. His company had been in “DevOps strategy planning” for over six months and they had settled on the task of automating the delivery of their software. He was feeling frustrated—there never seemed to be enough time to get anything meaningful done, he couldn’t tell what others were doing, and a recent conversation revealed that not everyone had the same definition for “automating the delivery of software”, much less having the same ideas behind what the word DevOps meant.
After several moments of ranting, he turned to me and asked in an exasperated voice: “What do we do now?”
Have you been there before? I know I have. If someone is telling you DevOps is easy, they are likely either selling you something or being dishonest. It’s not easy—if it were easy, the Agile movement of the early 2000s would have already solved the problems that the DevOps movement was founded to address.
In this column, Coffee Shop DevOps, over the next 12 months, I’ll touch on some of the key things you and your organization can do to make incremental progress without taking on big hairy audacious goals. I hope to help you address the moment when we all ask: “What do we do now?” Hopefully these small suggestions towards incremental change will also help you build a habit that will carry you and your organization into something that looks a little bit more like successful DevOps.
Get on the same page
One of the most common problems we face at work is communication. You and your team could have the appearance that everything is going as expected and then one day, as my engineer friend discovered, have a total failure to communicate and a breakdown in progress (and process). One way to address this type of failure is to build a common language with your coworkers.
One solution I’ve found is finding a neutral place to talk from. You can do this by reading a book or article, listening to a podcast, or watching an informative video, and starting from there. This works because it isn’t immediately close to home, like starting off with a discussion of the automation of your software delivery. Parallels can be drawn, discussed, and overall agreement can be forged that gets everyone on the same page.
The Phoenix Project, written by Gene Kim, Kevin Behr, and George Spafford, is an iconic book recommendation for those who are starting out fresh. Indeed, it’s where I started at Red Hat, and so did many others. It’s an easy read and follows a storyline that any technologist will likely have experienced sometime in their career.
When you are done with that one, pick up one of the following:
Gary and Tommy’s book follows their journey to Continuous Delivery and DevOps on the HP LaserJet product line. It’s a short read, at a little over 100 pages, and is written with practical examples for scaling the concepts of Agile and DevOps at large organizations.
I spend most of my time at work teaching people to understand that the why behind the work that we are doing, which leads to the how and what. Simon’s book helps drive those concepts home in their natural progression.
Or, how about a podcast? These are great for listening to on a long drive, in the evening, or over the weekend. Two of my favorites are:
The Ship Show: Bimonthly podcast talking about a topic near and dear to my heart: release engineering. Hosted by: J. Paul Reed, Youssuf ElKalay, EJ Ciramella, Seth Thomas, Sascha Bates, Pete Cheslock, J. Michael McGarr, and Katherine Daniels. Recent episodes I’ve enjoyed are:
What do we do now?
If you’re wondering how I ended up answered this question for my friend, well, I did so by asking him a question, of course: “What is one thing, something you can fit into a few hours, that will make this situation better?” He settled on the idea that they needed a defined list of terms so that they could communicate better. I suggested that he take time to start a draft and share it with the rest of the people on the project as soon as possible. It might not sound like a lot—it may not even work—but he felt better by having a task, and it was smaller than having a mountain to climb.