The question that comes up the most when I talk to people who are interested in DevOps is "Where do I start?"

Most of the time, the answer they're looking for is a list of tools and technologies to learn, so they usually look disappointed when they hear my answer.

If you want to get started in DevOps, if you want to deliver faster and keep up with everything that's being asked of you without killing yourself in the process, tools and technology are the wrong places to start.

First, you need to change the way you view and manage your work.

Step 1 - Define what matters

What's the purpose of your work? Care and feeding of servers, or "developing" might be what you do, but they aren't reasons in themselves. "Keeping everything working" is almost a reason but mostly in the vein of "I eat to live."

Chances are, the purpose of your work is a little meta - it's to support the needs and goals of your employer, to provide value in some way. So what does your employer value? If you don't know, it's time to ask and figure out how your work relates.

You'll arrive at some ideas you can measure and center your work around - things like systems uptime, mean-time-to-resolution, code quality, customer satisfaction, and so on.

This is where you start. Everything going forward is tied to the baselines you set and how you measure your progress against the new metrics you're now tracking. You're about to bring some science to your job - observing, measuring, and iterating.

Step 2 - Kanban ALL the things!

Before you start automating and building robots to do all the work, you need to gain visibility to that work.

You don't have to use kanban, although I would highly recommend it as an easy place to start. (Also, personal kanban is my spirit animal.) But you do need some sort of methodology that gives the entire team visibility to the work backlog and highlights bottlenecks that slow work down or otherwise impact the performance indicators you defined in step one.

This will require that your team starts collaborating, both internally and with other groups. They may not be used to this. You may not be used to it either, but people have to talk to one another if they aren't already.

Once the team starts talking about what they're working on you'll quickly discover opportunities to quash duplicate work, misplaced work ("Why is our group even handling this?"), and problems that were otherwise going untracked or getting piled on one person.

If you're a developer and have already been using Scrum or some sort of Agile methodology, some of these concepts might not be completely new to you. Even if that is the case, you may not be accounting for all of the backlog or might only be focused very narrowly on project work.

Step 3 - Automate and iterate

By now you should have a better idea of your team and employer's goals as well as the work the team needs to accomplish. After dropping items from the backlog that are 1.) of little to no value, and/or 2.) never actually going to be worked on (it's important to be honest about this), it's time for some experiments.

Use your kanban to identify the biggest bottlenecks that slow down processing of the backlog and attack them with process and automation. It will be tempting to attack low hanging fruit for easy wins, but it's important to treat the bottlenecks as if nothing else matters (because it kind of doesn't).

Note: Quality issues are bottlenecks and should be treated as such. If people have to constantly spend time fixing crappy code, failed builds, or similar issues - that's getting in the way of other work.

It's usually OK to throw some smaller improvements into your sprints that fit around other work but automating away the problems that significantly delay work (like waiting for Ops to manually build out environments) is where the focus should be. Most of the other stuff is just distraction.

As you put different processes and automation in place, make note of it and track those events against your performance indicators. Measure. Iterate. Measure again.

Step 4 - Keep learning

It's hard for me to imagine anyone succeeding with DevOps without regularly dedicating some time to reading. For most, working via DevOps practices will feel a little foreign at first, so the more you know about what others are doing and the ideas that inspired DevOps, the more comfortable you'll be.

There are a ton of great books that cover DevOps concepts and related topics like lean manufacturing, interpersonal relationships(!), and automation. Here are a few:

DevOps is a buzzword that gets thrown around to the point that a lot of people think it's just a fad or marketing-speak. It definitely can be depending on what the person saying "DevOps" means.

In my experience though, the people and process components of DevOps are really powerful and can change your day-to-day work and make things better. Unfortunately, these are the components of DevOps that usually get ignored. People tend to chase the shiny penny of automation without all the front end work that ensures they're automating the right things.

If you're interested in "DevOpsing", I can't stress enough how important it is to start with steps 1 and 2 before doing anything else. If you do, I can almost guarantee you'll achieve some level of success, even if it's just in how you handle your own work.

Originally posted on chrisdodds.net

How to get started with DevOps

Step 1 - Define what matters

Step 2 - Kanban ALL the things!

Step 3 - Automate and iterate

Step 4 - Keep learning