Why DevOps works to improve a business’ fortunes

Most people will probably agree that the end goal of DevOps – improving a business’s fortunes by producing better software faster – is a good thing.

And many would probably also acknowledge that the means by which that’s supposed to happen – getting the development and operations teams to work together closely – is also valuable if you can make it happen. 

One problem has been helping managers encourage development of a DevOps culture. The movement’s founders have never laid out a set of procedures and tasks that managers should use to turn an information technology department into a DevOps shop. (Incidentally, for some great info and tips, you might want to tap into the DevOps Virtual Summit, featuring Gene Kim and other luminaries, on March 18. More on that later.)

Despite a path that can be difficult, many companies are getting aboard the DevOps bandwagon. Perhaps not surprisingly, many are limiting the upside of their DevOps pushes by hitting common barriers to adopting the management philosophy, according to a recent report by Gigaom Research on adopting and implementing it.

These barriers, the report says, include inconsistent business goals; too much focus on certain areas of an organization; failing to address changes in the structure of certain organizations; and misaligned software systems.

The document’s authors, Kris Buytaert and Paul Duvall, have four key findings:

  • High-performing organizations deploy software faster and more often, and reduce lead times, the number of failures, and the mean time for recovery;
  • Following the lead of early adopters, which were primarily online businesses, more traditional enterprises need to start adopting similar operational practices “if they are to compete and survive”;
  • Organizations that do DevOps well:
    • Create small, “cross functional teams” that both build and run small pieces of software, such as for a given product or service;
    • Treat software as a “whole system” consisting of non-binary source files;
    • Represent everything that goes into a software system in text-based files;
    • Deploy software in small batches;
    • Create internal procedures to get instant feedback on changes to the system, with a goal of cutting the time between when a problem surfaces and when somebody fixes it.
    • Companies need to avoid the common barriers to DevOps, such as a lack of management support or understanding of what DevOps is. 

Building skills in DevOps

A key in implementing the philosophy is breaking down walls, both real and metaphorical, that separate different working groups in an IT shop, the report notes.

Some changes the document recommends on this front include:

  • Pair off people from development with people from operations. Thus, developers should work with folks such as testers and analysts;
  • Create pilot cross-functional teams;
  • Focus on improving both the system for creating and rolling out software and improving procedures, rather than on human failure;
  • Meet with other folks who are implementing DevOps in their organizations;
  • Ensure developers get calls to assist when production goes down.


It’s the culture, stupid

The overriding lesson about DevOps is that it requires a change in corporate culture. And that is the single hardest thing both to do in an organization, and to get right.

Not surprisingly, DevOps thus requires buy-in across the board, from the C-suite to the folks who answer phones. If managers believe they can wave a magic wand and get DevOps, they will quickly find they are sadly mistaken.

My view is that planning and diagnostics of an IT department are key.

On the one hand, managers need a solid, step-by-step game plan for how they’re going to implement the philosophy. But before they create that plan, they need a thorough understanding of where the potential landmines are in their organization.

What are the areas of friction between different individuals or different work groups? Why don’t those folks get along, and how can everyone learn to work together collaboratively?

The problem I see is that many managers simply don’t want the hassle of dealing with all that. Honest conversations are hard to come by with the rank and file, and it’s a pain having to deal with problems that otherwise get papered over.

But it’s essential to dig into the people issues and resolve them on the front end. Nothing can sink a DevOps initiative faster than people problems.

And that, in turn, can hurt your company’s ability to grow and prosper going forward.