5 Steps to Start Using DevOps

This post is an excerpt from our recent “Guide to DevOps in Government“. The full guide is available for download at this link.

Once you  understand the value of DevOps, how do you get started? Especially if your teams work in strict silos, without tools to foster collaboration, you might be overwhelmed at the prospect of completely revamping your development and deployment operations.

The good news is there is no hard-and-fast rule for what makes DevOps work. Diego Lapiduz from 18F explained: “With DevOps, you can say that you’re practicing it if your team is just talking — if you have a piece of the development team that is just talking to ops, and your ops team is just talking to your developers. But there’s also another end of the spectrum where you actually have no operations team. Everyone works under the same roof and it is all DevOps.”

DevOps requires iterative collaboration, but how you achieve that objective is entirely up to you and what makes sense for your organization. But whatever setup you choose, there are a few tactics our experts agreed make deploying and ingraining DevOps easier. Follow these steps to get your organization started:

1. Define DevOps. “Bringing people to a common standard and ensuring that you have a structured approach to how you lay out the application development lifecycle reduces risk and increases the likelihood of success for implementation projects,” Chris Cruz, Chief Deputy Director of Operations for the state of California, said.

Because DevOps processes vary in investment and sophistication, your first task is to define what DevOps means for you and your organization. This definition will allow you to determine which changes will be required to deploy the process and set expectations for how it will affect your project’s outcomes. For example, if you are low on resources, you might want to implement daily meetings between teams to start information sharing. Alternatively, if you have the leeway to implement collaboration tools and a joint development environment, you may consider a larger revamp of processes.

2. Build your first team. Eventually, you’ll want your entire organization to be a part of your DevOps strategy, but start small to minimize risk and really learn from your first attempt. Create a dedicated team of developers and engineers who are willing to execute your DevOps vision by testing new processes and tools, advocating for the process, and eventually teaching it to others.

3. Match tools to your vision. While we’ve repeatedly said that technology is not the central component of DevOps, it is a consideration. You don’t want to deploy an innovative process only to have it fail because you don’t have the tools to support it. With your team’s input, determine what tools you’ll need to enable collaborative development across projects.

4. Communicate to everyone. Rather than mandating that silos be torn down and processes redrawn, all of our experts agreed that it’s paramount to communicate why and how the methodology will benefit participants before it is deployed.

Then, as you begin to integrate teams and processes, be sure to keep communication going. Of course, you’ll want to publicize your progress and share your successes — that builds enthusiasm for the process and recognizes the hard work of your change-makers. Peter Eichorn, Director of Technology for Texas.gov, said an easy way to do this is to offer demos of your new products to other teams. “We find it takes a lot of the mystery out of developing software, and it also gains quite a bit of momentum. There’s visibility; people can really understand and be a part of something, so it really helps with the cultural aspects of DevOps,” he said.

But this communication will be equally, if not more, important when you miss the mark with DevOps. Rather than brushing failures under the rug, communicate where processes go awry and what lessons learned you can apply to your next attempt.

5. Remain flexible. Finally, even as you craft your implementation plan, don’t get locked in.

“Don’t be overly rigid,” Eichorn advised. “If something isn’t working for you, or you choose not to do all of the methods and techniques, that’s fine. You’ll still be successful. You don’t want to replace one set of things you did with waterfall, perhaps, with some other aspects that are so rigid that they get in the way of actually doing the work.” Remember, there is no one-size-fits-all for DevOps. Accordingly, be prepared to adopt more or fewer DevOps tactics as you experiment with the process in your organization.

Be sure to check out our newest guide on DevOps, available by clicking here.