In his Behaviorally Speaking series, Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior.
DevOps has it detractors, and they can send an enterprise back to the days when development and operations acted more like a volleyball game than a high-performance technology organization. This article will help you understand resistance to change involving DevOps and what you need to do in order to move that mountain.
DevOps is enjoying a tremendous amount of interest and support from software developers, operations engineers, and the technology managers who support them. But DevOps also has it detractors, and very often, these folks can stop the DevOps transformation—or sometimes even set it back to the days when development and operations acted more like a volleyball game than a high-performance technology organization. This article will help you understand resistance to change involving DevOps and what you need to do in order to move that mountain.
I have had some interesting experiences dealing with change. I grew up with a severe visual handicap through high school and into college that caused me to have to use a combination of Braille, large print, and tapes to read. I have experienced a major shift in the way society looks at the blind and disabled, and I certainly hope I had some small hand in bringing about that positive change. From navigating with (and often without) a white cane—albeit walking through a large glass window every now and then—I have developed the determination that comes from overcoming a major physical disability. Consequently, my managers are always cautioned that I have a little difficulty believing things cannot change. This optimistic persistence comes in handy when I sometimes I run into situations where key stakeholders are trying hard to keep the status quo.
When you are working in an organization, you need to consider the ecosystem within which you are operating. I usually try to understand what my colleagues might feel they could be losing, often in terms of autonomy or position power, if the MO of their process changes. The most common impact is actually eliminating key man risk because the application build, package, and deployment process becomes automated and can be run by any competent engineer. Sometimes, I find folks who resent what they feel might be a loss of job security. DevOps also changes organizational structures.
When development and operations teams implement DevOps, they are essentially organizing into self-managing, cross-functional teams. From my experience, this is the best approach: eliminating errors, improving quality, and generally helping the organization be much more effective. But I find some managers feel their turf is being threatened by DevOps, and they may resist the DevOps transformation in very subtle and even clever ways.
The best way to address these issues is for the organizational leadership to set very clear goals and hold the entire team responsible for the success of this effort. In practice, I focus on implementing an approach that has come to be known as “left-shift,” whereby operations gets involved much earlier in the process than usual. When I am the build engineer, I ask for the work of deploying to all of the environments from development test into production. Many organizations allow developers to deploy their own code into the early environments and then expect operations to pick up the deployment when they get to the controlled environments, including user-acceptance testing and production. The DevOps focus is to use the same approach (and automation) to deploy to all of the environments, and the sooner operations is involved, the easier it is to mature the deployment automation process many call the deployment pipeline.
Knowledge is power, and I am often working to get development to share their expertise with the operations folks who will be minding the production systems around the clock and responding to system outages when they occur. Developers typically get to pick the technologies they will use and then get a fair amount of time to learn and become comfortable with the technical frameworks and tools. Operations typically comes in later in the process and may not have been able to build the necessary technical expertise. By involving Ops in technical architecture meetings and document and code reviews, development can share their knowledge through the entire software and systems lifecycle.
DevOps doesn’t happen overnight, and any change may be a little rocky at first. My focus is to ensure that team members continuously review the process through retrospectives (or, as some call them, postmortems) and work toward understanding exactly what went well and what needs to be improved. Mistakes happen, but I believe mistakes are good when you learn from them. Teams that are willing to openly admit mistakes and have candid conversations about how to avoid them in the future will ultimately achieve success. Sometimes managers see a mistake early in the DevOps transformation and try to use that as an excuse to go back to the old approach they are more comfortable with. I am always armed with the reasons why deployments failed in the past and use that information to counter any attempt to stop the DevOps transformation.
Competitive pressures are making the need for agility and the capability to rapidly deliver changes to ever more complex systems crucial. When dealing with resistance to change, I typically remind managers that many of their competitors are successfully embracing DevOps best practices, enabling them to achieve success with improved productivity and quality.
