VMware: DevOps Behavior Change via Optimized Tooling
TL;DR: Even though VMware is a product and services company, technologies such as those at VMware can accelerate the adoption of DevOps.
Almost ten years after its earliest beginnings, IT organizations are still struggling with the philosophy of DevOps. There are many reasons for this. Of course the biggest issue that usually arises when seeking a cause for a lack of DevOps enterprise success is the lack of a required culture shift. Most DevOps experts and thought leaders agree that for DevOps to take hold and become the new modus operandi of an organization, the culture – everything from our unstated beliefs and assumptions to our values which together influence how we act and behave has to change.
The Schein Culture Model
What I have described in the previous sentence is what is now known as the Schein Culture Model developed by noted organizational psychology and management expert Dr. Edgar Schein (formerly with MIT’s Sloan School of Management). Chad Renando does a good job of summarizing Schein’s description of culture as a collection of assumptions a person makes with respect to the group in which they associate or are a participant. These assumptions include:
- External adaptation (such as why are we all here in this organization and what are we trying to achieve?)
- Internal integration (examples might include to things and what is the common and agreed upon framework of communication and terminology?)
- Deeper cultural assumptions (reflecting on human nature with questions such as, are people only here to get work done, or are people complex individuals more than their position?)
The assumptions manifest themselves into three levels. As you traverse from top to bottom, the ability to articulate, not to mention change them (and hence the culture) becomes more difficult:
Figure 1. Schein Culture Model.
Given the above discussion, it’s clear that wholesale culture change of an organization presents a daunting challenge because there are many layers that need to be pierced to ultimately change how an organization perceives and thinks. It’s obviously easier to design a new organization from a clean sheet of paper (such as what was done with Facebook, Google, etc.) than to take head on the established culture of many of our venerated corporate institutions.
I used to tell my former clients (without knowing about the Schein model at the time) that you can take incremental steps to change culture. I often cited things such as re-arranging physical work spaces to encourage communication, updating rewards systems by making them cross-cutting and modifying the current organizational structure. These would be some of the artifacts listed in the upper most layer of the Schein model. Processes would be here as well as many organizations would often focus their initial DevOps efforts on updating the release management process.
Culture Change at NUMMI
A great example of a real-life change that occurred that started with the upper level (and hence not trying to tackle head-on changing how people think) is that discussed by John Shook and his experience with NUMMI. In the article, Shook states “What my NUMMI experience taught me that was so powerful was that the way to change culture is not to first change how people think, but instead to start by changing how people behave — what they do” and “This is what is meant by, “” The key at NUMMI was the implementation of the andon quality control system and perhaps its most iconic aspect, the andon cord, which empowers individuals to stop the line whenever an issue arises.
Figure 2. Andon cord (source: http://www.shmula.com/).
So, the implementation of a system of tools (and processes) enabled people to more successfully do their jobs, and over time, changed the way they would behave. This dovetails with the activities of one of my former clients at Gartner who began their DevOps initiative not by directly confronting how people think, but by developing automation tools that would enable developers to more easily (and more often) test their code – an activity which was not occurring as it should have resulting in high costs when issues were detected in their production environment.
The results at NUMMI and elsewhere would probably not be a surprise to many anthropologists who seem to be in general agreement that tools helped to shape the behavior of our early human (and even proto-human) ancestors. For example, with respect to hunting, tools enhanced our access to an increasingly broad array of foods along with the ability to process and prepare those foods more effectively.
How VMware helps with DevOps
Hopefully by now we all understand that tools (technology) and people are interconnected and thus here at VMware we are focused on delivering the right services and tools to not only improve your DevOps success, but to overall optimize the corporate socio-technological ecosystem (thanks go out to Nicole Forsgren for introducing me to this concept of how technology and behavior can inform each other). What sets VMware apart with respect to our approach to DevOps from that of other technology providers, however, is that we enable new agile capabilities within a framework of existing tooling. VMware’s DevOps philosophy is grounded on giving developers the native experience they prefer and operations the consistent tooling and control that they are more familiar with via technologies such as vSphere Integrated Containers (VIC), VMware Integrated OpenStack (VIO), and the recently announced VMware Pivotal Container Service (PKS).
But we’re not stopping there. We are continuing to enhance our “cloud native” capabilities with recent enhancements to the technologies that make up our vRealize Suite as well as products such as Wavefront by VMware so that DevOps and IT operations teams have the needed observability and control for increasingly dynamic environments. No longer must one IT constituency conform to the other in terms of technology and thus any passive aggressive behavioral resistance to change is minimized. VMware-enabled DevOps is thus both “fit for purpose” and “fit for use,” i.e., not only enabling the basic utility of DevOps, but doing so in a manner that I believe is potentially the most effective in terms of its design to speed its adoption and ultimately influencing organizational behavior.