There are organizations that want to “buy DevOps,” like it is a plugin to add to the development process. They often create a new role, team, department, or infrastructure. But you can't buy DevOps, and it's not a designated team, either. It is the idea of people working together. Here are some approaches to get you there.
Just in the past year or two, when I’ve talked to technical staff and customers in my own work, I have noticed a trend: the dreaded DevOps team.
That is to say, the organization that wants to “buy DevOps,” like it is a plugin to add to the development process. To do this, they create a new role, often a new team, department, or infrastructure. At one Fortune 500 company I worked with, I met the director of the private cloud infrastructure project, which would take the next eighteen to thirty-six months to build out a private cloud so anyone could have DevOps on tap. It sounded good—at least, on paper—but there were a few problems.
First, consider the delivery team that wants to automate their build-release-deploy process. Instead of actually doing it, the delivery team is now waiting on an infrastructure team to deliver value (in eighteen to thirty-six months) that might be an easy plug-in to what the delivery team is doing now, or it might not be.
The DevOps group needs to hire staff like mad, so it’s looking for OpenStack administrators who understand a wide variety of Linux and Microsoft operating systems at scale, except that has probably changed to Docker by now.
Those people don’t exist—or, at least, if every large IT organization tried to hire those people, it would create a bidding war. That might be good for the few people who have the experience, but for the poor members of the delivery team, it means hiring is delayed, ramp-up time is delayed, support is delayed …
Meanwhile, vendors have jumped on the DevOps bandwagon and are happy to rebrand all the testing, monitoring, and support tools you’ve always been using (or couldn’t afford) with “DevOps.”
The idea that DevOps is something you can buy and install strikes again, slowing down delivery in the name of improvement.
And it gets a little worse.
Handoffs and Performance
One of the great things about a fully skilled, multi-discipline team is that the team can work together to move development forward all the time. As soon as you encounter dependencies, such as the team needing to request an external database administrator to add an index, or test needs to wait for a slow build, you slow the team down. I have seen projects that should have taken a morning take weeks because the work required the support of several different teams at one point in time, and each external group has a one-week service-level agreement. That meant wait a week, get a fix, assign the ticket to the next team, wait a week, get a fix, and repeat.
Even if the “DevOps person” is embedded in the team, adding a new column to the work board, and thus a handoff, will create a delay. At my company, we model this in our Lean Course, simulating a factory that has completely balanced throughput but small variation. Over time, bottlenecks emerge, and the more stations you have, the more bottlenecks and the worse things get. You don’t need to take the course; I wrote a little Ruby code on GitHub to run the simulation a few thousand times and report the results.
The bottom line here is that handoffs slow down delivery. You might need to have them, but carefully consider the case.
So DevOps isn’t something you can buy and have the new hires do. What should we do instead?