NEW YORK — Corporations looking to the DevOps software development method to swiftly build and test applications won’t get the full promised benefits without a workplace culture that is open, collaborative and compassionate.
Greg Bledsoe, managing consulting at Accenture Technology, gave the guidance during an interview at Cloud Expo. He was speaking at the June convention on the role of culture in DevOps.
“The culture is the complete set of unwritten rules that everyone follows that maybe nobody even talks about,” Bledsoe says in this SearchCIO video. He referenced business management theorist W. Edwards Deming, saying perception of those rules — what employees think they will be rewarded and punished for — are the drivers of culture.
DevOps focuses on tight collaboration between the engineers who build software and the IT operations folks who deploy it, so a workplace culture that encourages teamwork and transparency — and doesn’t point fingers when something goes wrong — is a natural fit.
In the video, Bledsoe relays a conversation with an employee at a client company about a project he was part of. It wasn’t going well, but the company wouldn’t tolerate problems, so they were hidden.
“How can you operate and make decisions if you can’t even get accurate information about what the state of things is?” he says. “A culture of blamelessness is probably the biggest prerequisite toward achieving a DevOps culture.”
A company with an unhealthy culture — one laced with “pathologies,” as Bledsoe puts it — can still get some benefit from DevOps, because the methodology calls for routine tasks like developing, testing and deploying code to be automated — and that reduces the chances for manual mistakes.
But in a company that judges employees solely on individual performance, say, collaboration may not come easily, Bledsoe says. Processes could be set up to enforce who works with whom, “but this is still in violation of the unwritten rules.” Individual goals and responsibilities will take precedent.
“In DevOps we have three legs of the stool: people, process, tools, and people is first,” he says. “Prioritize individuals’ interactions over processes and tools. That is where you get most of your benefit.”
What role does workplace culture play in DevOps?
Greg Bledsoe: Culture drives almost all human behavior. It’s very seldom that we make a decision to act outside of the culture in which we are situated. So the culture is the complete set of unwritten rules that everyone follows that maybe nobody even talks about.
So they are the driving force in what you can achieve. The venerable [W. Edwards] Deming found that the situation in the surrounding environment affects performance far more than the individual. The individual in different contexts can perform quite differently depending on how he perceives what he will be rewarded for and what he will be punished for, which are the drivers of culture — what is accepted and what is expected.
And these things are seldom consciously talked about. They’re seldom consciously drawn out in terms of what are the incentives that we’re creating with our culture, but we have to do it. Because now what we’ve discovered is, the biggest sources of problems and frictions and waste and drag is in that culture, is in misaligning the incentives that we’re actually giving to our workforce. We’re actually not incentivizing them to create value for the consumer but to protect themselves against the unwritten rules that they know not to violate.
What kind of culture is a good fit for DevOps?
Bledsoe: So cultures that have a collaborative, empowered bent are ahead of the curve. Cultures over time can sort of collect pathologies — things that don’t work as well as they should. Sometimes these things are caused And the longer organizations live, it’s likely that they’ve collected more and more of these — that these survive the individual who created them long after they’re gone. They’re very difficult to eradicate and they’re very difficult to even identify, because often no one even knows, why is it like this? It’s an unwritten rule that everyone knows and no one talks about but no one will admit.
I’ve had someone say to me, using a red and green light analogy, I was like, ‘Well, how’s your project?’ He says, ‘Well, we’re not allowed to be red, but between you and me, it is not green.’ So he knew that if he was the messenger delivering the bad news that was likely to be shot. And so all transparency was lost. And no one actually knew what the state of the project actually was.
How can you operate and make decisions if you can’t even get accurate information about what the state of things is? And this is why blameless post-mortems, a culture of blamelessness, is probably the biggest prerequisite towards achieving a DevOps culture.
Openness is also a characteristic?
Bledsoe: Blamelessness, openness, honesty. It really comes down to a core set of beliefs and values, right? People intuit what is the set of values that we’re actually operating under. Now, we can say we have certain values, but people see very quickly if there’s a mismatch between the messaging and what actually happens on the ground. They will go with what they see over what they’re told every time.
And so consistency in messaging combined with accuracy combined with consistency are the things that it takes to actually start to implement a healthy culture. Now that’s even before you get into a DevOps culture. That’s just a healthy culture in general.
Can an organization achieve DevOps benefits without changing its culture?
Bledsoe: So they can get some benefit. Even people who do DevOps badly and who can implement some automation will get some benefit. Because everything that you automate reduces the chances for manual mistakes.
So you will get some benefit, you will get some cost-effectiveness, but you’re missing out on the true power of DevOps, which is to transform the entire organization, to reorient it towards value to the consumer, to whoever is the end target of what you produce. So you can get some benefit and feel like you’re doing well, but you will find that you’re not actually getting the full benefit of DevOps. That what other people are able to achieve, you’re not.
And you will find that the typical flow is, people want to implement some tools and have some automation. And there are some problems with that, but they get a few of these running. They don’t understand why it’s so hard, why the collaboration, the integration comes with such difficulty.
So they say, ‘Well, what we really need is processes.’ So they write down some processes. ‘So and so will collaborate with so and so.’ But this is still in violation of the unwritten rules. No one’s performance evaluation is going to take into consideration whether they collaborated, so they’re still focused on individual goals, individual responsibilities. ‘What am I going to be judged if it is done or undone?’ And so the process does not solve the problem.
And so then people come behind that and say, ‘OK, the process didn’t work. What is the real problem? And the problem, I guess, is us.’ Which is why in DevOps we have three legs of the stool: people, process, tools, and people is first. And that’s a part of the Agile Manifesto — prioritize individuals’ interactions over processes and tools. That is where you get most of your benefit.
Get Greg Bledsoe’s take on traditional management structure at organizations today in this SearchCIO video.
View All Videos