I had a couple conversations at DevOps Days Minneapolis about how get started with DevOps. I’ve collected my thoughts here.
From wikipedia: “DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.” 
DevOps, like any other buzzword, represents a powerful tool and a dangerous trap. Sometimes simultaneously. Getting started down the right path, especially at a large organization can be a daunting task. DevOps requires buy in, people skills, technical skills, and a commitment to improvement, iteration, communication, inclusivity, and learning.
There are many right ways to take the first step. In what follows I offer how I’ve done it, as a framework for how I believe you can do it.
Perhaps the worst way to implement DevOps is as “a solution in search of a problem.” Before you start reading up on DevOps, CI, CD, monitoring, chatops, hugops, and @beerops, ask yourself what you believe DevOps will be able to do for you, and why you need that. This can be “shorter release cycles,” “less down time,” “fewer production defects,” “reduced infrastructure costs,” “visibility into X,” “shared ownership of X” etc. You might also want to factor in what problems will be most compelling to whoever you need buy in from as you try to grow a DevOps culture in your organization.
Your next task is define a metric that can prove to yourself and others that your problem has been solved, or improved. This is also a litmus test for whether or not you’ve identified a problem. If you can’t find a metric for it you probably need to drill into it deeper. Once you’ve got your metric, determine your baseline, where are you at with it right now? Remember (document) how you made this calculation since you’ll have to come back to it later.
Dig into your problem space, understand what goes into it now, step by step. Become an expert on the way things are. What does your process look like today? What gets done? Who does it? How do they do it? The better you know this, the better you’ll be able to improve it. Build a spreadsheet, and get this documented. Don’t skimp on this step it’s one of the most important.
Now comes the fun part. Look at the document you built in the previous step, and notate where a DevOps tools / approaches / philosophies / methodologies / mentalities / etc. could make a difference. Build (document) a mind map, or a spreadsheet, or whatever helps you identify ways to impact your problem space. Look for improvements, but don’t forget to look for redundancies, waste, and anything that can be eliminated.
Pick one piece of the document you’ve created above that you see as low cost high benefit, a confidence booster, or an easy win. Look for something that you’re excited to work on. Make sure it’s something that you believe will impact that metric you defined already.
Now that you’ve got a starting point, try out a solution. Look at this as an experiment, you don’t have to keep your solution in place if it doesn’t work, and you can try another solution later. #YOLO
Moment of truth. Did it work? Has your metric improved? Are there other changes? Can others see the improvement? What went right, what went wrong (this is great time for a retrospective, after action report or postmortem).
If you didn’t improve your metric that’s still a win, you’ve collected data, you’ve found a way not to make a light bulb. Figure out where you went wrong, and try again! If your metric is improving, keep tracking it, and circle back to “Choose” it’s time to take another step, rinse repeat, DevOps.