How Cultural Perception Can Cause DevOPS to Fail

The Role of Culture

Development and operations (DevOps) is a set of methodologies and processes that promote efficiency and innovation in product development and delivery. It has been my experience that some developers and managers mistake DevOps to mean the automating of an infrastructure. While automation is often an attribute of a DevOps model, DevOps in itself is an idea that encompasses a variety of attributes. A key point of failure for projects I have been a part of was the disregard of the cultural aspect of DevOps. A no-blame culture encourages innovation because individual contributors know they are part of a team and that any failure is a learning opportunity and a chance to grow professionally; they do not fear ridicule and avoid innovation for fear of unconstructive criticism.

Implementation failure often comes in one of three flavors:

• Cultural rejection (failure to adapt)

• Incomplete design

• Unsupported infrastructure

Cultural rejection is very common because once you have a system that seems to work, starting over and learning a new procedure isn’t very appealing to IT professionals. I remember my first attempt at implementing a CI/CD strategy and using a YAML linter on a Puppet project. The first developers who committed their hieradata got rejected because of inconsistent spacing; after three tries, all commits were in, but the developers refused to use the pipeline because it set them back.

I also implemented a Git branching strategy to keep version features from creeping into previous iterations of the software. The strategy had a version branch and a master branch. Both branches were locked, and the only way to get code in was to create a feature branch off the version branch and submit a pull request, also called a merge request. The idea was that peer code review would occur and would be a second pair of eyes for possible bugs or design flaws.

A branching strategy may be a new idea to a developer, and their willingness to adopt the strategy may hinder the efficiency of the pipeline. The chances of cultural rejection decline when the team is part of the design; when someone feels they are vested in an idea, they are more willing to accept it and to overcome obstacles in it. The best advice I ever received in my career was that adopting DevOps strategies require the support of upper-level management; it also needs the support of those who will use the system. If a solution is implemented, but nobody uses it, what is it really worth?