This post is the latest installment in a series aimed at helping organizations adopt DevOps.
Some say that DevOps is a method; others say it is a movement, a philosophy, or even a strategy. There are many ways to define DevOps, but everybody agrees on its basic goal: to bring together development and operations to reduce risk, liability, and time-to-market, while increasing operational awareness. Long before DevOps was a word, though, its growth could be tracked in the automation tooling, culture shifts, and iterative development models (such as Agile) that have been emerging since the early 1970s.

While its community-driven evolution has given DevOps strength by infusing it with ideas from many corners of the software development world, it has also hindered the movement by not providing the community with a central set of operational guidelines.

Often, a company attempting to adopt DevOps will be doing so against the current of operational red tape and culture of silos. This transition is not easy for companies that have built their enterprise (and their employees' expectations) on a foundation of "un-DevOps." Moreover, once the decision has been made and a group has the freedom to attempt implementation (which is often its own challenge), the group is faced with the problem of how to implement it properly.

As we'll discuss below, DevOps adoption is not a one-step process, and it can certainly be done incorrectly (or not at all). An attempt at correctness can be found in the scientific method, with the ability to measure, test, analyze, and repeat DevOps decisions and outcomes. While many leaders in DevOps talk about what needs to be done, there have not been enough eyes and ears tasked with objectively and measurably observing change as a result of implementing DevOps.

This gap is not to say that DevOps does not prescribe monitoring and measuring. In fact, monitoring and measuring is a primary objective in some DevOps circles. The purpose of this monitoring, however, is to compare the state of a project now to that same project last week (or in another sense, to alert the team that the servers are down). This perspective is great when you need to see how well a project is progressing, but fails miserably when you need to answer the question "How far along are we on the road to DevOps implementation?"

Studies of DevOps adoption rates use the phrases "have adopted" or "will adopt," as though they are line items on an organization's quarterly goals and objectives. Does that mean they have achieved Flickr's 10 deployments a day, or do they use the word adopt in a softer connotation, where they have simply accepted their fate, and will now begin listening to DevOps philosophy? Given the many definitions DevOps carries, the word adopt has at least that many variations in meaning and probably more. In any case, DevOps is not a one or a zero, but a continuum of positive and negative attributes, and far from linear.

I'm not going to craft arbitrary milestones. In some teams, achieving any level of DevOps behavior is an accomplishment worthy of a catered lunch. But, to understand that DevOps is at once culture and technology goes a long way toward framing the goal. Another perspective is that your goal of DevOps adoption is what you need it to be. In other words, each organization has its own signature of pain points and struggles, and the vast array of solutions that DevOps offers is sure to provide a good start toward fixing them, even if just one or two are needed.

It seems as though the DevOps movement is doing just fine without some dry, boiled-down set of standards and metrics. However, if we focus on making changes without measuring them we risk being on an endless road to gold plating our process. This outcome would be fine, except customers are also investing real money into these cultural overhauls, whether they know it, want to, or neither. Changes must be planned, with a clear goal and a target date.

Because DevOps doesn't come with an inclusive guidebook, identifying concrete goals and reasonable timelines can be hard. Seeing a report of, say, 400 percent decrease in release time or 8,000 percent increase in profits, can tempt organizational leaders to chase similar results. In reality, any positive result achieved from focusing on some aspect of DevOps will be proportional to the size or output of a business. While these kinds of measurements are quantifiable and objective, are they targeting the specific problems within an organization? If the current process isn't noticeably damaging release time or profits, what is? Culture-related issues can be hard to identify, let alone quantify and measure. In many cases, providing channels for a team to report incidents in a genial manner can help to identify distinct properties of those incidents, such as severity (rating on a scale), what groups are involved, or the point during the development cycle at which it occurred? By identifying concrete metrics for a problem in this fashion, changes will become observable over time. Starting with the problem and designing a system to measure its change can be a far more effective strategy than jumping in headfirst to implement DevOps.

A set of standards and metrics might even already exist in some sense, but the casual conference-goer might be led to think they don't, due to how DevOps is often presented: as a patchwork of stories of individual experiences, do and don't lists, and vendors hawking automation technology. Developers new to the idea go home refreshed, approaching the task with enthusiasm, but without the clipboard and analytical squint. This approach can be dangerous for businesses that take a real risk in initiating a culture shift and then find themselves without a quantifiable goal. It is important to be aware that we are missing the dense and tabular chart that would define specific and measurable attributes for degrees of DevOps adoption. Simply knowing that we should have reachable goals is not only logical, but also helpful in guiding change as it occurs within a software development and release team.

Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for 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 view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits, please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.