You, yes YOU: DevOps' people problem

You’ve no doubt heard of DevOps. This is the process of getting developers and sysadmins working together closely on the same team to support a company’s custom-written software.

I know, I know, Dear Reader: you’ve been doing this ever since operating that AS/400; no one really needs weekly releases; and, of course, the favorite: “this is just the current way for consultants to make money.”

All signs point towards DevOps being not only all those things, but actually A Thing on its own. Ever since starting my career as a programmer, and through being an industry analyst, strategist, and, now, marketer, I’ve been motivated by the quest of learning how to improve the software development and delivery process. DevOps seems like the current, best method.

What has the IT department ever done for me?

The primary motivations for doing DevOps are to ensure application uptime (usually for mobile and web apps) while at the same time ensuring that you can release new code to production, basically, at will, usually weekly or daily. Presumably, a company would like these benefits to be more competitive with its custom-written software, both with more features, but also by taking advantage of short, user-interaction feedback loops to constantly tweak their apps to perfection.

Things are not too joyous when it comes to IT actually delivering on this dream of helping companies innovate. When I want to gin up an excuse to drink heavily, one of my favorite charts to look at is this one from the Cutter consortium.

When it comes to innovation, over 3 short years IT has plummeted in usefulness. To put it bluntly: IT sucks.

As I’ve studied DevOps over the years I’ve found that DevOps is the “how” of solving this problem: a process and mind-set. Continuous delivery is the “what”: the “tool” you put in place. This is why I look to continuous delivery as a tracer for DevOps adoption.

You’re doing CD? Yeah, sure...

Continuous Delivery (CD) is yet another one of those things that most people say they’ve done since the days of mainframes ... but reality is usually different, as seen by one study:

A fair number of people think they’re doing continuous delivery, but when compared to the textbook definition, they’re more like dabblers, picking and choosing practices that are easiest and leaving out the rest.

While these numbers are low, the growth year-over-year shows rapid change and progress. There is a strong desire to improve, if only organizations can figure out how.

Rub Some DevOps On It

Beyond the tracer of continuous delivery, there’s some fresh industry survey data we can look at to see if DevOps is actually a thing. Gartner fielded a survey last Autumn; while it’s all too easy to dismiss them as conservative and backward looking, isn’t that exactly the kind of thing you want when asking if DevOps has gone mainstream?

While it doesn’t have the muscular impact of a year over year study, Gartner’s September 2015 survey of 383 respondents showed good momentum for the adoption of DevOps: 29 per cent were actually doing something with DevOps, with 16 per cent taking a DevOps approach in production and 13 per cent piloting it. While small, those are impressive numbers for something as new as DevOps.

Trying is the first step to failing

While longer-running bodies of work like the always excellent, annual Puppet Labs DevOps survey are showing that the ideas work, things are not so rosy when it comes to putting DevOps in place. More often than not when I’ve worked with groups that want their software processes with DevOps, they underestimate the amount of organizational change needed. They view software more like building a Lego kit. Creating good software is more like inventing Lego all over again, each time. Fostering that kind of continuous learning requires putting the process in place that creates metaphoric “innovation factories.” DevOps thinking describes much of how those “factories” run, which is often much different than the status quo.

What I’ve learned is that it’s a meatware problem: people’s default to resist change is what holds back transforming to a DevOps mind-set. This is why the DevOps cult leaders go on and on about “culture.”

The problem starts with managers who often assume they can just throw a copy of The Phoenix Project at their team and expect them to “do the DevOps.” Instead, managers need to change incentives and behavior to lubricate change. But it’s not just managers – staff needs to get with the program too. You know, you might actually have to go talk to programmers! Or worse: sys admins!

Among other things DevOps-related, I’ll look to sort out those meatware problems in this column. As they say: to be continued. ®

Want to learn more about DevOps, Continuous Delivery, and Agile? Head to our Continuous Lifecycle Conference from May 3-5. Full details here.