Get your DevOps team on the same page

Coffee Shop DevOps: Start small, but start somewhere

Coffee shop photo
Image by : 

Florida Memory. Modified by CC BY-SA 4.0

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.

Media suggestions

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:

Leading the Transformation: Applying Agile and DevOps Principles at Scale, by Gary Gruyer and Tommy Mouser

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.

Start with Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek

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.

Want something faster and visual? Try Simon's Ted Talk, Start With Why

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:

DevOps Cafe: A monthly podcast that interviews awesome people occupying the DevOps space. Hosted by: Damon Edwards and John Willis. 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.



I'll show up for the coffee, but I'll stay for the DevOps.

Vote up!
Vote down!

I agree completely, communication is key! Along with communication, the organization has to define what a variety of terms mean to the organization. For example, in practice, CI/CD have different meanings for different organizations.

Vote up!
Vote down!

2 things that are very common in the daily life of Software developing communities and companies. Drinking "Coffee" :) and answering the question "How to deliver quality software in a regularly and automatically manner".
Worn-out processes are tough to change. For us we found out that is is a good approach to start changes with the first step "taking a task with most minimal effort but comparatively highest improvement gain", then try to find out if and how it works and then decide how to proceed and do the next step. And so on. It is a change process that needs patience because not everything gets better today or tomorrow, but it pays off on the long term.
Jen, thanks alot for starting this very interesting column. I'm looking forward to learn more.

Vote up!
Vote down!

Glad to hear about the coffee. :D I used to hate drinking it, but now ... it's basically a necessity most mornings. ;)

My entire job for the past 10 years has been about worn out processes and changing those. Sometimes I wonder about that career selection. :D

You know other thing about breaking things down into small chunks-- sometimes it feels like there is no progress. Or that the act of breaking them down into smaller bites is not worth the time and effort. But, I honestly do believe it is the only way to make progress on a huge goal that sounds like "make devops work for you and your org." I don't know how anyone is successful doing that with a big bang approach.

Vote up!
Vote down!