Image: iStockphoto/faithiecannoise

It’s easy to get confused by DevOps. Ever since the term was (more-or-less) coined in 2009, we’ve tended to make believe that DevOps is something you buy. You know, a set of tools like Ansible or Jenkins that magically transform a lumbering enterprise into a lithe startup machine.

If only it were that easy.

But it’s not and, as Microsoft’s Emily Freeman makes clear in her new book, DevOps for Dummies, “DevOps is a cultural revolution that unites the traditionally adversarial sides of development and operations. It encourages teamwork, collaboration, communication, and—above all else—trust in the people with whom you work.” Freeman isn’t the first to remind us that DevOps is a culture thing, but what makes her book worth reading is the amount of time she allots to defining what a healthy DevOps culture looks like and how to create that culture.

SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)

DevOps is a cultural revolution

Ultimately, DevOps is about people, not tools, and that’s why Freeman can boldly state, “If you take only one thing away from [this book], I want it to be the list of the core values that are central to the DevOps movement. Those values are:

  • Encourage teamwork

  • Reduce silos

  • Practice systems thinking

  • Embrace failure

  • Communicate, communicate, communicate

  • Accept feedback

  • Automate processes (when appropriate)

If those sound easy to achieve in practice, your EQ may need some work. Kubernetes isn’t going to make your enterprise agile if the people inside aren’t talking to each other. After all, the whole idea of “DevOps” is to bring developers and operations (two groups historically at loggerheads with each other) into partnership. That’s not a software thing. It’s a people thing (which software can then amplify).

SEE: Quick glossary: DevOps (TechRepublic Premium)

Given Freeman’s emphasis on people, I love some of the practical advice she offers. For example, in any organization there are executives, middle managers, and engineers, with middle managers wielding a lot of clout. They’re the ones, Freeman points out, that serve as intermediaries between executive vision and developer know-how. They are, however, the last group you should try to persuade to implement DevOps, she writes. “The process of convincing them will flow much more smoothly if you take advantage of the peer pressure from the other groups.”

That’s wise, and derives from Freeman’s two decades in enterprises large and small.

Getting smart about DevOps

The book is riddled with other practical advice, like…

  • How to quantify DevOps benefits to both pitch your plan and evaluate its effectiveness. Among other things, Freeman delves into how to tally up the average cost of meetings (“endless meetings are a sign of poor collaboration, distrust, and an ineffective process”), measuring customer satisfaction, and more.

  • How to measure the efficacy of processes you’ve implemented using such techniques as mean time to detection and recovery (MTTD/MTTR), defect escape rate, and more.

  • How to put feedback to work (“However you receive feedback, you need to create a process through which anyone—truly anyone in your organization, from the engineers to the executives—can receive and pass along feedback”).

And more.

SEE: What is DevOps? An executive guide to agile development and IT operations (ZDNet)

Freeman also offers insight that will perhaps shock developers, like this from her description of the six stages of the software development lifecycle:

The actual development of features is the face of the process and gets all the glory. But I argue that it’s one of the least important steps in your development life cycle. In many ways, it’s simply the execution of the preceding areas of your pipeline. If done well, coding should be a relatively simple and straightforward process.

Now if you’re a developer and just gasped at that last sentence because you’ve dealt with hundreds of random and difficult-to-solve bugs, I know how you feel. Coding is hard. Nothing about software development is easy. But by mastering the planning, design, and architecture (and separating them from the actual implementation of code), you ensure that the hardest decisions of software development are abstracted away.

If you’re already deep into DevOps, there’s still likely something you can learn from Freeman’s perspective. Given that just over a quarter of developers claim that their companies are immersed in DevOps, Freeman’s book is a bible of sorts to the rest of us. Maybe you’ve heard of DevOps, and maybe you’ve even dabbled in it, but if you have yet to master the cultural shift that DevOps demands, Freeman’s DevOps for Dummies will help to ensure that you don’t remain a “dummy” for long.