How to introduce DevOps into a moribund corporate culture

"We need to do DevOps."

And there you have it — the scariest words that could ever come out of the mouth of an executive.

There is a lot of interest these days in DevOps, especially as organizations of all types and sizes evolve into software producers themselves. The problem is DevOps — like its siblings, agile lean and quality — is not something that can be pushed onto the workforce from way on high.  DevOps is not a "program," an "initiative," or even a "best practice." DevOps is a way of doing business, a way of thinking, that stretches from the moment an application is conceived in someone's mind to its release into production, and way beyond.

DevOps is the melding of developers' tasks with those of operations people. This is important in today's go-to-market-fast economy, because software releases need to be fast and furious. Release 3 needs to be ready to spring just as Release 2 is sent out to customers. The goal of DevOps is to align the creative and innovative spirit of developers with the constraints and requirements of ongoing operations.

Many organizations simply do not have the corporate cultures to support such an approach. They may be siloed, they may have fiefdoms, they may have uninspired, hidebound managers who prefer to throw products over the wall with a minimum of testing, and only go back to fix problems when enough customers are screaming loud enough.

That's the wall that IT leaders seeking DevOps run up against. In a recent post, ActiveState's Phil Whelan puts it this way:

From enterprise IT customers and conversations I have had, it seems that DevOps may be a little intimidating. Nobody wants to be accused of not doing DevOps right, especially if it has been mandated from high up the chain that 'we need to do DevOps.'

Companies that are successful with DevOps do more than just push tools and continuously deliver pipelines, Whelan says. "They have the right culture. The culture for learning, for adapting and for seeing the bigger picture. They see how the drawing board relates to final product."

That's because, as Whelan eloquently explains: "DevOps is an invisible thread that runs through the entire process of IT, from the design of the software right out to the software running in production." Accordingly, it needs to be baked in right from the beginning.

So, there's the challenge, what's the solution? It's a long-term process to embed DevOps, quality and agile into an organization. Let's face it, IT leaders are not in a position to overturn a calcified, counter-productive corporate culture overnight. Here are some ways to start the process:

Engage the business. You may hear this a lot, but this is especially important when moving to DevOps. Business leaders need to be made aware of the potential of DevOps to streamline and improve the business. Also, business executives are increasingly turning to their IT leaders for guidance as we lurch into an increasingly digitized economy. They want IT to take a proactive stance on laying out a compelling business technology vision for their organizations. IT executives are in a position to promote DevOps as part of this new, digital direction.

Study and learn from organizations that have successful DevOps underway. This doesn't have to include IT DevOps, either. There are organizations that have successfully aligned their design, engineering and production operations in a DevOps way.

Join professional organizations that provide education and knowledge sharing in DevOps.  While there aren't professional organizations or certifications specifically for DevOps, many existing bodies may hold sessions or provide instructions in the DevOps way. User groups may also be a resource as well. The values found in lean, continuous improvement and agile also have DevOps components. There is also an ongoing series of "DevOps Days" conferences held throughout the world.

Failure is an option. The most successful organizations are constantly innovating and improving, and that comes from allowing people to fail, and learning from those failures. Whelan notes that successful DevOps companies "often have new hires push to production on their first day. The testing hurdles in place almost always ensure that no real damage could be done by any naive new hire. Failure here is placed on the infrastructure and not on the new hire."