Manage Learn to apply best practices and optimize your operations.

Be wary of DevOps evangelists preaching a culture change

There are many reasons to adopt DevOps, and there are many challenges involved in getting it right. But don't buy into the culture myth that many DevOps evangelists are selling.

When it comes to DevOps, nothing is quite as irksome as the advocates, consultants and highly paid DevOps evangelists...

who devolve every dialog about the topic into a discussion about culture. DevOps isn't about culture, and those who constantly beat that drum are being both disingenuous and unhelpful when it comes to moving their DevOps agenda forward.

DevOps isn't about culture. DevOps is about automating tasks, it's about reducing manual interactions in the process of continuously integrating software, and it's about moving successfully tested software swiftly into production. That's the essence of DevOps. DevOps isn't about culture.

Culture is a nebulous and intangible concept. When DevOps evangelists laud the importance of culture in the world of continuous integration and continuous deployment, they are both selling a pig in a poke while holding for themselves a pretty precious get out of jail free card. 

The pig in a poke

It's a pig in a poke because culture is an unquantifiable, abstract concept. There's a wise, old proverb in the software development world that insists that if an action can't be tested, there isn't any point in doing it. How do you test culture? How can a DevOps evangelist report as to whether the culture is improving or deteriorating from one week to the next? They can't. It's impossible.

Well, perhaps impossible is a bit strong.

"Using tools such as the Net Promoters Score approach to surveying employees is one way to evaluate how DevOps is impacting culture," said Eric Minick, a product management lead at IBM. But Minick also suggested that there are other aspects to DevOps development that are better suited to testing and evaluation.

"Delivering new applications faster and reducing the time required to get new features to market are major benefits to DevOps," Minick added. But both are attributes that are measurable using more scientific metrics than a survey.

DevOps evangelist
Culture is too nebulous and intangible a term to be useful when trying to transform organizations. DevOps evangelists who say organizations need a culture change to achieve continuous delivery have the tail wagging the dog.

Do not pass 'Go'

The reason why the culture myth is a get out of jail free card is because it allows the DevOps evangelist to lay nebulous blame whenever the transition toward automation and continuous delivery falls apart. Automation isn't happening? Unit tests aren't providing thorough software coverage? Software is still being manually integrated? If that's the case, just blame the team for not properly adapting to the DevOps mindset. If DevOps isn't working, just blame the team's inability to adopt a DevOps culture.

The only good use for the concept of DevOps culture is for advocates and DevOps evangelists to shift blame away from themselves when the project their clients are working on goes sideways, and that's not a good use at all. Such scapegoating has no place on an enterprise software development team.

Delivering new applications faster and reducing the time required to get new features to market are major benefits to DevOps.
Eric Minickproduct management lead, IBM

And finally, the most disingenuous aspect of promoting DevOps culture is the strawman fallacy that insists that the ideals of DevOps are somehow foreign to software development teams that don't embrace a DevOps approach. There are no software development teams out there that believe automation is bad, that delaying feature releases is good, and that software quality isn't important. There is no doubt that many software development teams struggle with these concepts from time to time, but to assert that a cultural shift is required to make developers realize that frequently releasing bugfree software is a good thing is pure bollocks.

Want more people doing DevOps? Start training

Here's how large organizations are training their own employees and even college students to infuse the DevOps talent pool.

DevOps evangelists have it wrong when they say organizations need a culture change to make DevOps work. These DevOps evangelists have the tail wagging the dog. It's not changing attitudes that gets DevOps to work, but it's watching processes improve through the use of continuous integration tools and increasing task automation that changes the attitudes. DevOps doesn't require an attitude change in order for it to work. Instead, it's when DevOps practices start to work, which in itself is what promotes a change in attitude.

Software developers are smart people. They are interested in solving problems, meeting deadlines and delivering high-quality code. If there are practices and processes that can be proved to work, developers will adopt them and adapt to them. Software professionals don't require a change in culture in order to believe that delivering software faster is better. All they need is proof that a change in the process will work. Deliver the facts, and the change in attitudes will follow.

Dig Deeper on DevOps Team Organization

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Which are the most important DevOps metrics you use to evaluate whether your DevOps processes are working?
It's an interesting choice of words to call "DevOps culture" a disingenuous strawman fallacy because this article is a disingenuous strawman.

At the outset, you imply that those advocating for culture change aren't also advocating for automation. Meanwhile, a mainstream concept in the DevOps community is CAMS (or now CALMS), which advocates for both. Plus some other important concepts like measurement and sharing.

Later as you explain your assertion that culture is immeasurable, you neglect the studied connections that correlate employee satisfaction to time-to-market (see 2016 State of DevOps Report). Or is your assertion that statistical correlation is unscientific?

The most disingenuous part of your post is asserting that DevOps advocates use culture as a mechanism of blame, when these are the same people talking about "blameless post-mortems" and using the Westrum Model to measure culture with a focus on safety.

When I read beyond the logical fallacies, I see a valid critique of the DevOps community. I can agree that it feels like a lot of arm-waving goes on about culture, without a lot of concrete, actionable advice. Moreover, you and I agree, "Software developers are smart people." But DevOps isn't "a thing" because some of those developers figured out how to automate away testers or sys admins. Rather, it's because people discovered that, automating as a team, with testers and sys admins, has more impact on speed and quality simultaneously than when solo developer heros automate tasks on their own.

Even as I take your critique to heart so that I do a better job explaining culture changes in more concrete terms, I'll stick to my position that culture and collaboration are essential to DevOps.
Points well made.

>>Even as I take your critique to heart 

I will take your critiques to heart as well.
Every top founder of the DevOps movement disagrees with this post. I suspect the author simply hasn't grasped what they mean, as shown by the fact he thinks DevOps is mostly about "automating things"!
DevOps works in conjunction with lean product management approach as well as agile software development processes. While DevOps can be heavily an engineering practice, the other aspects require significant mindshift from the waterfall method of doing things. I think It would be great to ask DevOps consultants what they mean by cultural change when they talk about it.
The problem I have is that when I talk to DevOps consultants, 'culture' is the only thing they talk about. Every question or concern comes back to 'culture.' Then you ask them to quantify culture, or how to evaluate culture, or how to monitor culture and they can't do it. 
In the case you mention, that’s totally a problem. But i wonder who these consultants are. Nobody i work with in the industry who i respect would focus solely on culture. And most, of not all, know how to measure it. See the work of Dr. Nicole Forsgren and DORA for examples. Nobody worth their salt is saying that it’s all about culture. But to dismiss it is fallacious. And yes, there ARE teams that resist everything you say. I’ve worked with them. And I’ve never blamed them. You work with them to help them see the value of the new ways, and the culture change comes along. But you have to understand why you’re doing it. It’s commitment vs compliance.
>>And yes, there ARE teams that resist everything you say. I’ve worked with them. 
I agree. I agree with that completely.

Now, what does that have to do with DevOps? Nothing. Yes, there are people who refuse to work, refuse to cooperate and refuse to follow instructions. Those people were alive before DevOps came about, and they will be here when DevOps is long gone. DevOps doesn't solve those problem behaviors, and those who assert that it does are being disingenuous.
That’s completely backwards. DevOps proposes to solve those behaviors. That’s what it’s been about from the beginning. Have you seen John Allspaw’s “10 Deploys A Day” talk? If you have, you misunderstood it. You can’t do the DevOps items you refer to with broken culture. Period.

>> You can’t do the DevOps items you refer to with broken culture. Period.

I guess I would then ask what you *can* do with what you call 'broken culture?' Does Agile work with broken culture? Does waterfall work with broken culture? Does ALM work with broken culture? You could easily argue that nothing works with broken culture, and more to the point, you could constantly use 'broken culture' as a get out of jail free card when things don't go your way, which is exactly the disingenuous behavior I take issue with in the article.

This takes us back to the beginning, which is the fact that the blanket statement about culture is meaningless, because it applies to everything. And if it applies to everything, then the marginal value discussing it provides is nothing.

And again, my assertion was the culture argument is a get out of jail free card. Any time DevOps doesn't work, you just say 'well, it failed because of broken culture.' That's not acceptable. If your process requires perfection in all human interactions, and failure in that regard can make the whole thing come crumbling down like a house of cards, then your process is far too fragile and way too nebulous to be practically applied.

I don't think DevOps is impractical, and I don't think DevOps is nebulous, which is why I object to people who insist that it can't be implemented unless the human element is perfected. "You can’t do the DevOps items you refer to with broken culture. Period." So then every organization who is doing DevOps has perfected the cultural element? That's not a reasonable assertion. Period.

I agree with devpartisan. 

I find your post uninformed and purposely polarizing. Have you actually worked with teams of developers and ops yet? Do you even know what culture even is? Do you know that people problems are the number #1 barrier to solving technology problems? 

The minute you work with people (not just by yourself), you have to consider and respect the culture. That's why we talk about culture - which enables us to solve technology problems. Like automation.

Why is an inflammatory post of this nature permitted in a publication intended to discuss devops culture?

Just for clicks? I don't get it.
>>Do you even know what culture even is? 
I'm happy to entertain anyone's definition of culture and how that definition pertains to automating tasks and removing manual interaction from the continuous delivery pipeline. Basically, I want to know how it pertains to DevOps. That's where the DevOps evangelists run out of steam. 

>>Do you know that people problems are the number #1 barrier to solving technology problems? 

Isn't it the #1 barrier in addressing most problems? I know 'people problems' are common or reality TV shows. Would DevOps processes make people get along better in the 'big brother' house? Of course not, because the two topics are completely separate. If you want to address the human problem, then address it appropriate. If you want to address DevOps, then address that appropriately. But conflating the two is completely disingenuous. 
" If you want to address DevOps, then address that appropriately."
But, as every single founder of DevOps points out, the DevOps problem IS the people problem.
I still think one of the most constructive things we've done on this site (and I think it applies here) is our first conversation with Gary Gruver, on defining DevOps.

When we asked Gary how he'd defined DevOps, he started with Gene Kim's definition, which emphasizes outcomes over practices. There's no such thing as practices that work for everyone. But we're all more or less striving towards the same outcomes, as Gary put it, "to deliver code on a more frequent basis while allowing them to maintain quality."

And I think when you frame DevOps in this way, the culture vs tools/processes is less chicken vs. the egg, and more in the line of "okay, let's see how culture and tools/processes can work together to build a sustainable deployment pipline."

I think that is an excellent article, and the point that we need a common definition for DevOps is more than pertinent. That is often the problem. The term DevOps sometimes means all things to all people.

"it's about the outcomes that enable you to deliver code on a more frequent basis while allowing you to maintain all aspects of quality whether it's functionality, security, performance and all those things."

The things mentioned here are all measurable, can be base lined and can be tested after changes are made. And if any of the gathered metrics fail, hopefully there is a source that can be identified, rather than going around saying that 'performance is degrading due to a lack of DevOps culture.'
I trust you know who Patrick DeBois is.
"It's a pig in a poke because culture is an unquantifiable, abstract concept."

And what nonsense here! As though only "quantifiable" things matter! In fact, the attempt to quentify everything is highly destructive of, among other things, culture. See The Tyranny of Metrics, Muller.
I agree, that "The reason why the culture myth is a get out of jail free card is because it allows the DevOps evangelist to lay nebulous blame whenever the transition toward automation and continuous delivery falls apart."

This is the main problem with the use of the word culture. Besides being ill-defined (or definition not well understood/agreed upon) it does get used as an excuse for things we don't understand. Here be dragons.

Why is this dangerous? Because people use it to explain things they don't understand and then by naming it, feel they do not have the need to investigate and try and understand further.

That said I do believe culture is importantNow since I think culture is important let me define it.

First some history of the definition, the OED in 1430 defined culture as "cultivation" and "tending the soil".

In 19th century one definition had “culture” defined “refinement of mind, taste, and manners.”

Refinement defined as "the process of removing impurities or unwanted elements from a substance" aka - removing obstacles which is part of DevOps/Agile/Lean

Second Edgar Schein (retired MIT Sloan) defined it as “a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.”

Third, Steven Spear (High Velocity Edge, and MIT Sloan) defines it (as best as I can remember) as "the embedded reaction to external stimulus".

These are all good definitions, but the question is what kind of Culture (as defined by Schein and Spear) that we want to "cultivate"? I would say one of psychological safety and continuous improvement.

So while I believe culture is extremely important (not just as defined above, but also along the lines of the Westrum Culture model and things like a culture of High Psychological safety and experimentation). See:

I actually agree with the author that the term should not be used, but more because it is so often misused and I believe in trying to teach in a jargon-free way to facilitate learning (my own and others).