On the surface, DevOps sounds great. Automation, collaboration, efficiency--all things you want for your team and organization. But where do you begin? DevOps promises high return on investment in exchange for a significant shift in culture, process, and technology. Substantially changing any one of those things in an established organization can feel like a superhuman feat. So, how can you start your organization on the path to DevOps without compromising your existing business goals and trajectories?

This is no easy question, and the answer is different for every organization. The first step is to not focus on automation or new technologies. Instead, look at your current team culture and processes, and identify the biggest sources of risk and inefficiency. A DevOps strategy for your organization should be designed and implemented to address these issues. Implementing a solid DevOps strategy often requires the introduction of new technologies, as with organizations that don't have a standard issue-tracking system in place across all teams or have inconsistent version-control practices. However, the ultimate goal should be improving communication and process.

In many cases the most important solutions are process-based, and may even be informal adjustments to team behaviors. Have Ops (operational) staff been invited to your development project kickoff meetings? If not, isn't that a great opportunity to engender broader support for your project, and get Ops feedback on potential wins or risks for the organization from their perspective? The overarching principle of DevOps is to align the goals of every worker with your ultimate business goal: a fully functional system, running smoothly in production, and delighting customers. Achieving this alignment must be the primary objective shared by all staff, including both Dev (developers) and Ops. Open communication is the first step in aligning goals across your teams.

Also, ask questions about goals and incentives:

• Are your developers held accountable for the success or failure of their code in production?
• Or, are they actually working toward the internal team goal of handing the packaged code to the Ops team and letting them handle deployment?

This bifurcation is a recipe for risk--everyone in the project must be incentivized to make decisions that will ensure both a successful deployment and a reliable system in the field. Often, the biggest cultural win comes from focusing all stakeholders on the ultimate business goal, instead of their isolated team goals, and giving them the space to optimize their processes to achieve this ultimate objective.

Every two weeks, the SEI will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To read all the installments in our weekly DevOps series, please click here.