The Never-Ending Story
When a new process or methodology comes along—particularly when one gets a lot of attention like DevOps has—there always will be failures. I’m not talking about those always-present group of people who say they’ve seen this cycle before and, thus, it is just a fad; I’m talking about actual implementers who, in the end, come up empty-handed.
DevOps is no exception. In fact, because it radically changes much about IT, it probably has a higher rate of this problem than most new methodologies.
The end result is easy enough to identify: Either an organization abandons DevOps altogether or shunts it off into that area where other processes and technologies have been implemented by only one team and eventually die.
Problem Children
In almost every case of DevOps failure, people are the problem. That is not to say people purposely undermine the system, but IT is built, managed and run by people. And the breadth of people in an organization has immense influence on the success or failure of DevOps (or any other IT initiative).
With that said, let’s look at some problems that contribute to DevOps abandonment organizations should avoid in their attempts to evaluate/implement DevOps.
Team Isolation
It is a standard enterprise reaction to split off a team to look at a new technology/process and isolate them from the rest of IT. I was the first hire in a “New IT” at an organization—it was weird to have rooms of cubicles filled with people I was not allowed to talk to. One of several keys to success in DevOps is communication, and no application or application portfolio works in a vacuum. The need to discuss server space, security, routing and a host of other topics with core IT means isolation will not work. It is one thing to clear the pilot team’s workload to allow them to focus on assessing DevOps for the organization, but it is quite another to isolate them (functionally, geographically, whatever). If they find some quick-hit streamlining opportunities in standard operations, don’t you want those shared with the wider IT department?
Getting the Tools Side Right, but Missing the Culture Side
I make no secret about the fact that I’m a bigger fan of the automation side of DevOps than the culture side. But sooner or later, all the whiz-bang tools are deployed, and culture becomes the main focus. That includes not only communications between different parts of the DevOps team, but also the “can jump in and do” mentality that is more prevalent in DevOps than in a more divided IT environment. Getting the culture and communications down early is important for success. And success is important for wider gains in IT’s ability to meet the demands of the business.
Adding to the Workload of Overloaded Team Members
This is perhaps the most common pitfall that causes organizations to leave DevOps or minimize their exposure to DevOps practices. DevOps holds the promise of increased productivity and decreased backlog. But it is a promise. Implementing tools and forging new relationships and new paths of communication … these things take time. And that time is added to existing workloads, unless steps are taken to lighten existing workloads.
The team working 10 to 12 hours a day just keeping the lights on will not side-track into anything that requires a definite investment of more man-hours unless it is mandated to them by the business. Asking them to start working on it is a recipe for failure; the best you can hope for is some automation that makes their life easier in some other way.
Not Managing/Meeting the Expectations of Various Leaders
What line of business (LoB) leaders and the CIO expect out of DevOps are different things. While vaguely similar—increased responsiveness to business needs is normally 100 percent shared—the details show different concerns.
It is up to the CIO to manage what those under him in IT expect/demand from DevOps, and what those peers in the line of business expect from it. There is no reduction in commitment from LoB teams—indeed, one could argue there is an increase, as IT is no longer the bottleneck. And, perhaps most importantly for some organizations, DevOps doesn’t make IT mind readers any more than previous new methodologies did. The LoB still must define what is needed and get requirements into IT.
Trying or Retrying DevOps? A Few Tips
Pilot
Run a pilot project. Lighten the load of the project team so members can focus on DevOps and bring its value into the team. Do not isolate them in any way. Including other teams by asking for help/ideas should be encouraged. In fact, if the pilot team is motivated and enjoying the pilot, this type of interaction can help smooth the way for extension of DevOps to the wider organization.
Use Existing Resources/Management
Don’t bring in specialists to do DevOps. DevOps can be learned, and there are a ton of resources available, so use people who know your environment and can apply standardized tools and practices to it. That includes management. The last thing an organization should have in a pilot is a manager that knows DevOps but not the relationships within and special quirks of your organization—both technical and social.
Pick Your Pilot Carefully
Pilot a project that is relatively small but is visible to the organization. Actively manage expectations, and see where DevOps takes you.
Rethink Everything
Empower the team to look critically at every single process/workflow and see where the most gain can be had. DevOps is not a switch; prioritizing high-value/important items for change in this iteration and lower-value items for future iterations is part of the process. But if you don’t look at everything, you can’t guarantee you’re getting the most bang for your buck on this—or any—iteration.
Clearly Communicate Goals/Changes
Make sure everyone in IT and out understands what the pilot is testing. Is it increased time to market? Is it ability to apply tools and processes to intractable sub-projects? Is it a test of the benefits touted by talking heads? Communicate what you are measuring and how you’re measuring it. If possible, share a dashboard showing those measurements with everyone who cares to follow along.
This Time is Different
DevOps is different from any other new methodology that has gained traction for the operations side. Ever. I’d say it was different than any other new methodology at all, but Agile is the precursor to DevOps on the Dev side, and they share a lot. It challenges decades-old thoughts on the best way to do things. It will fail sometimes, for a variety of reasons. Give it the best chance for success that you can, don’t tie the pilot team’s hands and use it where it succeeds, even if it doesn’t include every project in the portfolio.
In the end, if it really does help the business succeed, then—like it or not—it is the right tool for the job.
