“The human mind,” said sociologist Charles Horton Cooley, is “a cave swarming with strange forms of life, most of them unconscious and unilluminated. Unless we can understand something as to how the motives that issue from this obscurity are generated, we can hardly hope to foresee or control them.”
The late Dr. Cooley would have made a great DevOps consultant.
DevOps—the methodology that calls for software developers and operations teams to emerge from their silos and work closely to allow more frequent releases of code into production—is not only one of the hotter buzzwords in IT, but also one of the very few modes of software development and deployment that emphasize people over technology (though implementation certainly relies on tools and processes).
As a result, I would argue that the discipline that teaches us most about DevOps isn’t computer science or engineering but psychology. That’s a reality organizations need to be mindful of (pun intended) as DevOps grows, in Gartner’s words, “from a niche strategy employed by large cloud providers to a mainstream strategy employed by 25 percent of Global 2000 organizations” by the end of this year. Here are the implications.
DevOps on the psychiatric couch
Because adopting DevOps represents such a dramatic cultural shift in the traditional church-and-state separation between those who develop and test code and those who deploy and maintain it, you could fill a “Dr. Phil” episode with the emotional pitfalls that can sabotage an organization's DevOps journey. Fear of change, conflict, loss of control, and self-serving thinking—these are just a few of the issues that can arise.
The psychological forces that have shaped DevOps can be traced to its childhood. Under pressure to create new products and features at breakneck speed, the “Devs” were the first to drive the conversation on stronger collaboration with the production side. The “Ops” were slow to commit.
The great schism
So a disconnect has existed from the start. Developers want to roll out new software constantly, as more organizations move to a continuous delivery (CD) model. CD was pioneered by digitally native companies such as Amazon, Netflix, and more recently Uber, and many development teams envy the velocity they see among those companies.
On the other hand, to operations group members responsible for ensuring that applications are available and reliable, DevOps can seem like a Wild West environment. To Ops teams, deploying new software faster isn’t beneficial if its quality can’t be assured.
The great uncertainty
Complicating matters further, DevOps is more of a philosophical initiative than a clear set of strategies and processes. It’s not yet like ITIL (Information Technology Infrastructure Library), the set of practices that seek to standardize the selection, delivery, and support of IT services and align them with the needs of the business. At the moment, DevOps lacks a defined framework for operational execution. The continuing curiosity about how to do DevOps is evident at any conference where a speaker delivers a how-we-did-it talk. Those rooms are always packed.
DevOps mapped to psychological phenomena
Like nature, the poorly defined terrain of DevOps abhors a vacuum. If organizations aren’t careful, bad vibes could hinder their DevOps initiatives. Here are a few examples of the psychological phenomena that often are at play and what we can learn from them:
Fear of change: One of the most powerful human emotions is fear, and fear is frequently triggered by change. DevOps marks a huge change, especially for operations teams, and who can blame them for worrying? They perhaps can take comfort in Dr. Susan Biali’s observations in Psychology Today: “Any time you're out of your comfort zone, you're going to feel anxious. Just because you feel anxious does not mean something bad is going to happen. In fact, for me most of the time anxiety means something really great is going on and that I'm moving through new territory in the direction of my dreams.”
Social identity theory: This theory, developed by British social psychologist Henri Tajfel, holds that people derive their pride and self-esteem based on their group memberships—whether a social class, family, or work department—and that in order to increase self-image, humans tend to enhance the status of the group to which they belong. This also leads to people dividing the world into “them” and “us.” The best way for both sides of the DevOps house to overcome this tendency is to recognize that they both live in the same large house. The organization needs them to be on the same page and accelerate software delivery for competitive advantage.
Self-serving bias: This principle describes people’s tendency to ascribe their successes to personal traits and talents while blaming failures on other people or external factors outside their control. The lesson for DevOps? There should be no “other”—both sets of players are part of the same crucial mission and, in that context, parochial finger-pointing makes no sense.
Contact hypothesis: American psychologist Gordon Allport laid out a psychological framework for alleviating conflict between groups of people—including a sense of equal status, a sharing of common goals, intergroup cooperation, and personal interaction. Applying these tenets to DevOps could go a long way toward easing conflicts between the development and operations teams.
The attentive parent: A vital new role for the C-suite
What else can be done to build bridges between DevOps stakeholders?
As with a child, early DevOps adoption can benefit immeasurably from an attentive parent. That means the C-suite should take an active executive sponsorship role. Too often today, DevOps exists as point or trial projects by individual teams within companies rather than a strategic, enterprise-wide initiative. Projects aren’t a bad way to start, but to meet the full promise of DevOps, you need a structured mandate for change, and that need to come from the top.
At the same time, leaders should accept another important psychological element, autonomy, and allow teams to choose the tools for carrying out their DevOps mission. Technologies have come to market that automate many of the tasks and processes needed to meet DevOps’ objective of faster software releases. Gartner says these tools grew to a $2.3 billion market last year, with far greater growth ahead. But senior executives should understand that the best decisions about what tools to use should reside with those using them.
By considering DevOps as we might consider a complex individual, maturing through trials and achievements as they embark on their journey, organizations have a familiar set of psychological tools at their disposal for achieving an important business objective. The goal is a fully functional, mature process, one that significantly decreases software release time and responds quickly to market and customer demands.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
