Actually Getting Started with DevOps

a valentine’s day heart tin laying in snow
That’s a heart pan in snow. I took that in Cincinnati, OH. Happy Valentine’s Day.

There are countless blog posts and guides dedicated to working Agile DevOps into your team. There are posts on how to measure MTTR (mean time to repair) and CFR (change failure rate). There are posts on how to measure velocity and team throughput. There are posts on what makes a great DevOps culture. These posts are all incredible if you already practice some version of DevOps. They are also good if you work on a dev team with people itching to do DevOps.

They are not so good if you are just getting started. I want to help build into that body of work with this post. Read this if you are not DevOps fluent or you know someone who needs help just getting started somewhere. These tips are totally doable by yourself at first to help you get a handle on where to start. My advice is divided into three easy-to-use chunks.

The benefits of a great DevOps culture are big ones. I speak from experience in saying the difference between a high functioning team and a low functioning team are vast. The former drives org growth, developer quality, lower attrition, better products, lower QA time, faster delivery, happier customers. And, yes, more income for the business.

Do not read a book on great DevOps culture as your first task. You’re not trying to boil the ocean here. It’s like watching Yo-Yo Ma and getting bummed out that you suck at cello. He’s been playing since 1959. He probably wasn’t that good in 1960. DevOps is a process, it’s very organic, and even small growth will give you benefits, further fueling your ambition.

Start by seeking to understand what DevOps — software Development, IT Operations — is. From Wikipedia:

[DevOps] aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

All right. So, “shorten the … life cycle” means deliver products to market faster. Great! Provide “continuous delivery” means we keep pushing out new features with little friction. Finally, “high software quality” is exactly what it sounds like: stuff that doesn’t break in our customers’ hands.

It’s fine if these are abstract concepts right now. Don’t start solutioning against them. Not yet. Just keep repeating in your mind that you want to build great software faster. Okay.

With the list above in mind, pick just one thing about your software delivery you want to improve. This is a concept similar to building software: start small. Make the tiniest piece work first, and then move on to something else. Focus on solving a real-world problem that you have:

  • Our software updates take too long to get finished
  • We have a lot of bugs in production
  • The site/app/server goes down a lot
  • The team is really unhappy
  • I never know what’s going on, or where things stand
  • Time / $ estimates are always way off
  • [Insert your own problem here]

Make your own list. What are the problems that you have as you see them? Pick just one thing from that list and circle it. If you need to, ask someone you trust wants to improve the team (some badly running teams don’t have a lot of these) if they agree this is a problem to be solved. Don’t let them convince you to pick a bigger problem.

Now, cross off all the other problems on the list. You are not solving those other problems right now. Literally cross them out. Don’t take a photo, don’t save the paper. If these truly are problems, you will be able to easily recreate this list again later.

With that problem in mind, let’s consider the next piece of DevOps — measurement. Much like any other piece of a business, from accounts receivable to payroll to product supply to shipment times to margins, everything is measurable. Software delivery is, in many ways, no different. If your site goes down a lot, how often is it? Be vague — is it once a week, once a month, etc? If your estimates are way off, by how much? Are you always 50% over budget? 75%? 200%?

Create a spreadsheet and put your problem in there on the first line. Next to it, put the frequency or the other measurable number. Then, in the third column, put your goal.

Now you’ve got yourself two things. A line in the sand, and another line in the sand a little bit farther away. This is where DevOps comes into play. You have a problem with your software delivery that you want and need to fix. In this case, your web server goes down a lot.

Your immediate next step is to communicate with the technical leader on your team to talk about your problem and your goal. If you are that person, well, this just became a lot easier. Now, identify a handful of things that you can work into the next couple of sprints that can ideally improve this metric. If you’re not running sprints, add them to the task list. Your goal is to get your first number closer to your second number every couple of weeks until they are the same.

If you can’t figure out how to break that down into workable chunks, start over and pick a new problem to solve. Pull your list of the trash, I guess.

DevOps covers a lot of ground and does a lot of things and requires a lot of expertise… to operate at the expert level. You can start at the earliest stage doing the most basic amount of work. Grow from there.

In the above example, think of the cascading effects of lowering server crashes.

  1. Less customer and user impact
  2. Less developer stress
  3. Less time spent on support calls = more time spent on developing other features
  4. Measurable improvement for the team to see and applaud
  5. Education and growth for the team working to solve it

It goes on and on. Put another way, DevOps is the construction of virtuous cycles of process improvement that result in better software development and operations.

Hit me up with questions in the comments below.

Peanut butter first, code second.