In the quest for DevOps, there are two paths organizations can take. One is to start with automation and attempt to get as much as possible out of automation tools. The other is to start with culture change and use tools to address what increased communications uncovers. Both scenarios are happening in the wild, and both have strengths and weaknesses, but there are themes across both approaches that are worth calling out.
DevOps: Culture vs. Tools
An extension of the above distinction is that some IT shops try to implement all changes with tools. After all, a large part of DevOps is the benefits that tools offer, so why not try to reap those benefits without changing the entire culture? This approach meets with limited success. Of course, things improve, since more automation means less room for human error. But there is a limit to how much improvement can be gained without the culture change that allows Ops to ask, “You are slating this project to use BobsEasyDatabase, but we only use the big three. Any chance we can retarget and save issues down the road?” Early and frequent communications can smooth over issues like this and allow a team to do a full-life cycle risk assessment of contentious choices.
Do not let an aversion to culture change limit your DevOps initiatives. It can be difficult to change teams around such that management responsibility changes or is even blurred. But by increasing the authority of a cross-functional team to make the decisions needed to get reliable software out quickly, these issues can be mitigated. It will be an adjustment for many, including middle management, but it is a change that allows the full force of DevOps to improve software delivery.
Silos vs. Culture
In traditional IT, Development happened largely in a vacuum and Operations received the results. The place of security and infrastructure teams was generally with Operations, though they dealt a bit more with development than, say, the systems management team did. The problem was that Development often did what was best for development, with little visibility into how badly it impacted the other teams in the life cycle. The same was true of Operations, which would sometimes “just say no” to any request outside of normal operations without consideration of overall life cycle. And also for Security, which theoretically has veto power for strange implementations in more organizations. These attitudes have to change if DevOps’ strength is to be realized.
Do not leave silos in place that reduce communications between teams. If possible, rebuild teams along application or application portfolio lines so that Dev, Ops, Security and Infrastructure are together discussing what is best for the application and the company. But if that is not possible, regular stand-up meetings to discuss contentious issues such as the security of a given library or inclusion of “Yet Another Database Management App” in a project. Barriers segment work in ways that make the lives of some easier at the expense of the overall project. Break them down as much as your organization will allow.
Driving Home the Changes
In the long run, the point of DevOps is to improve the product and the delivery reliability of the product. Making changes that forward these goals is paramount to success.
Do not let inertia stop culture change. The DevOps Institute has a Certified DevOps Leader program that points out (among other things) how middle management can be the stumbling block in many DevOps implementations. We won’t give away too much of its training, but will say that the organization has good tools for dealing with the dilemma of telling middle management they must meet deadlines while the organizational structure is shifting under them.
There always will be people who believe their role is so unique it does not belong as part of the DevOps process. To make DevOps successful at reducing time to market while simultaneously improving quality and agility, every part of the process must be visited. Quite often, the person whose job is so unique is the bottleneck in the process. If the decision is made to change culture, include everyone, even when it’s uncomfortable.