For more than two years, I have participated in a number of panel discussions at Boston DevOps, our local DevOps meetup. Panels have been put together from several disciplines to address issues through the successful adoption of DevOps and reaching optimized use of this current methodology in software development.
As relevant as the DevOps challenge is for every technology organization, it remains elusive. Many groups simply are not cracking the code and in some cases simply do not know how to effectively start the change. Check out SMART DevOps as a way to get started.
A recent panel in which I participated was set up as an informal question-and-answer session, including questions from attendees viewing a live stream of the event. The introduction by one of the panel members laid out the complexity of issues required to optimize DevOps in an organization. It was clear from the audience questions, as well as those from the live stream, that there was discontent among representatives of all three groups who have been combined into a DevOps function–issues related to implementation and ongoing results. As I prepped for the panel, I came upon a Gartner Group article that had an extremely interesting quote in it: “The DevOps trend goes way beyond implementation and technology management and instead necessitates a deeper focus on how to effect positive organizational change. The DevOps philosophy therefore centers on people, process, technology and information. With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact.”
One of the questions from the live stream was: “If DevOps is so great, why is everyone so unhappy?” Another question from the panel moderator very clearly and succinctly asked about the kinds of cultural change happening in organizations, separate from new tools and new practices. The commentary from some technology-oriented panel members precipitated the rapid disintegration of audience discussion into a heated debate about tools and technology.
Observing that rapid switch away from very “soft” questions about culture to what tools will and will not support aspects of DevOps was enlightening and frightening at the same time. It was very apparent to me that this major shift in how information systems organizations were structured and managed was a throwaway in terms of organizational change. The Nike phrase “Just Do It” comes to mind.
The issues were obvious to me. In no way had most organizations viewed the combination of three separate, virtually autonomous departments (one of which is adjacent to customers) each with a different culture, as an organizational change. And, by the way, a change to be accomplished while maintaining a 24-hour idea-to-delivery cycle, with each new idea coming within seconds of the last. The departments in question were not filled to the brim with sales and marketing extroverts. Rather, they were groups and individuals who were used to looking at the problem in front of them and solving it without having to resort to communicating with others. Like its close relative Agile, DevOps relies heavily on communication and conversation to be successful.
The situation is a wake-up call to technology leaders and managers. If you are working in an organization that has embraced DevOps with the goal of providing customers with what they want almost immediately, check in with all of your technology teams. They may be floundering in what they did not perceive as an organizational change. If you are a technologist trying to implement DevOps successfully and suspect that there are underlying organizational issues, there are several things you can do to be effective and help your organization realize a successful implementation. Start the conversations that need to happen to have optimized DevOps, learn some of the principles of collaboration and consensus, and draw upon the expertise of outside resources who can facilitate you and your teams through the organizational complexities of a transition—“a philosophy, a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change.”
This article was co-authored by Kevin Fisher