You are here

Is DevOps culture an all or nothing proposition?

public://pictures/Tony-Bradley-Editor-in-Chief-TechSpective.net_.jpg
Tony Bradley, Editor-in-Chief, TechSpective.net

You've probably heard by now that DevOps is more about a shift in the IT culture than it is about tools and practices. One of the prevailing themes of adopting a DevOps culture is that it requires breaking down silos, abandoning traditional corporate roles, and facilitating teams and individuals to work together more efficiently.

What if the whole organization hasn't embraced the DevOps culture, though? Is it still possible to start a DevOps initiative on a smaller scale, or is DevOps all or nothing?

[ Learn how value stream mapping can benefit your organization in this Webinar. Plus: Learn more with this GigaOm Research Byte on VSM. ]

Culture shift

John Jeremiah stated earlier this year that DevOps requires a transformation of culture and processes for both developers and IT operations teams. "To do that, you need to establish a culture of trust. That's not a trivial transformation to undertake, considering that for the past several decades development and operations teams have lived as separate tribes with sometimes conflicting goals and objectives. The former focused on delivering innovation and change, while the latter focused on protecting availability and keeping costs in check. The gradual erosion of trust between the two teams presents an obstacle to rapid business innovation."

One of the ten key takeaways from the Puppet Labs "2015 State of DevOps Report" focuses on the responsibility of IT managers to make DevOps successful. That responsibility is largely tied to the ability of the IT manager to simultaneously sell executive management on the concept while effectively leading the teams that need to execute it. I wrote in August, "Those who are too lazy or ill-equipped to do so end up falling back on some sort of cookie-cutter cultural framework like ITIL or COBIT. The [Puppet Labs] report found that high-performing organizations have IT managers who are able to build teams that cooperate effectively and aren't afraid to take risks."

[ Learn how release orchestration can govern compliance, control, and integration for successful DevOps transformations in this Webinar. ]

Going all in

"DevOps cannot exist in a vacuum and requires that the business and the technology around it work in concert with one another," explained TK Keanini, CTO of Lancope. "You have to think of this as an ecosystem that includes partners, customers, your business, and everything else. DevOps is born and sustained out of necessity. Doing it any other way is just ineffective and inefficient."

He went into more detail, describing the story he sees playing out time and time again with customers. For instance, a traditional software vendor decides it wants to offer a SaaS (software-as-a-service) product. What it doesn't realize is that offering a SaaS product means becoming a SaaS business, which includes people, processes, and technology that are SaaS. It can be painful to adopt a SaaS type of infrastructure and, in the process, learn that traditional tools and methods can't run it effectively.

Keanini summed up with:

"Ultimately, DevOps is born, and it's a painful birth. If successful, DevOps is there as the newborn grows into a real business or dies trying."

Eat the elephant, one bite at a time

That sounds a lot as if DevOps culture is all or nothing, that trying to do DevOps halfway is a fool's errand that's doomed to fail. That may be true to an extent, but there's still another way to view it. The departments or teams that embrace DevOps need to be all in and not try to "sort of do" DevOps, but that doesn't necessarily mean the entire organization from top to bottom and everywhere in between has to be on the DevOps bandwagon.

Jim Stoneham talked about this exact thing at the recent DevOps Enterprise Summit 2015. Stoneham's presentation illustrated how his team at Yahoo was able to embrace DevOps and achieve success in spite of a lack of support from the organization at large. Stoneham told me there were actually additional barriers put in their way, but the team persevered and ultimately triumphed with DevOps.

"My belief is you pretty much have to start small and go for small, early wins," explained Stoneham.

"DevOps at its core is about a more collaborative culture across the many functions (including dev and ops) that build, ship, and support the business. Culture is infectious, so creating new norms [one] person at a time can be quite effective, over time."

Tom Limoncelli agreed that a successful DevOps culture can be achieved without universal support throughout the organization. In fact, Limoncelli, SRE at Careers.StackOverflow.com and co-author of the book The Practice of Cloud System Administration, went a step further and suggested that top-down executive directives are often ignored, or that those who follow them aren't really on board and feign compliance just to keep their jobs. True progress, according to Limoncelli, comes from grassroots efforts that work and provide incentive for other teams to mimic that success.

"I think some of the biggest success stories started out with zero backing," said Limoncelli. "One team conspired to do it for one of their many projects. ... The success then bolstered support for doing it on many other projects; soon other teams were copying them. Eventually executive management finds out and spreads the word to all teams."

Baby steps

In the book All You Can Do Is All You Can Do, author Art Williams stresses a point that applies to DevOps.

"Remember, before you can be great, you've got to be good. Before you can be good, you've got to be bad. But before you can even be bad, you've got to try."

Along those lines, there's the old saying, "Don't let the perfect get in the way of the good." The basic premise is simple: Don't let an obsession with getting it exactly right prevent you from trying in the first place.

It would be awesome if you could get the whole company to embrace a seismic shift in IT culture and make the switch to DevOps. It's highly improbable, though. If you can't get the whole company on board, start with your team or project. Success sells. If you do it right and you achieve success with DevOps tools and principles, other teams will want to follow your lead. Before you know it, the whole company will be doing DevOps.

The bottom line is that DevOps is not an all or nothing proposition. DevOps is a "start from where you are today" proposition. Do what you can to move the needle, and build momentum as you go.

[ Learn what separates successful DevOps initiatives from unsuccessful ones in this new EMA research Webinar. ]