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.

Download this free guide

PDF: Are you migrating to DevOps?

As DevOps is slowly taking over the IT landscape, its vital that IT pros understand it before jumping right into the movement. In this complimentary guide, discover an expert breakdown of how DevOps impacts day-to-day operations management in modern IT environments.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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.

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

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.

14 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

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.

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 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?

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.

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.'