DevOps is a marriage between tools and culture. If you are just using the tools that you heard about at a recent DevOps Days and not also embracing the culture (or at least working towards it) then you’re not really “doing DevOps”.
Is using DevOps tools, but not really “doing DevOps” a problem? Is the cultural baggage of DevOps getting in the way of utilizing some great tools or workflows that have emerged from under the umbrella of this movement?
From Enterprise IT customers and conversations I have had, it seems that DevOps may be a little intimidating. Nobody wants to be accused of not doing DevOps right, especially if it has been mandated from high up the chain that “we need to do DevOps”.

What folks have now is working. It may not be working well or efficiently, but it is working. Everyone knows their job and through hell-and-high-water they’ll ship their code… eventually.

DevOps is so alien to them that it is hard to know where to start.
Do we hire a new “DevOps” team? Where do we find these people? How do we integrate them into the organization? Do we reorganize and make some Developers into DevOps Engineers? No wait… all these articles on the Internet say we should not have DevOps Engineers. That is the road to failure. It will become another silo. We have to change as an organization. It’s a culture shift. I don’t think my boss will sign off on this.

Ain’t Broke, Don’t Fix It

I love this story from Simon Sinek’s book Start With Why…
*”A group of American car executives went to Japan to see a Japanese assembly line. At the end of the line, the doors were put on the hinges; the same as in America. But something was missing.
“In the US, a line worker would take a rubber mallet and tap the edges of the door to ensure that it fit perfectly. In Japan, that job didn’t seem to exist.
“Confused, the American auto executives asked at what point they made sure the door fit perfectly. Their Japanese guide looked at them and smiled sheepishly. “We make sure it fits when we design it.”*
Until the American car executives saw their competitors, their system was working for them fine. Cars would roll off the assembly line and the doors would fit “perfectly”, but obviously there was something fundamentally different in the way the Japanese were creating their cars. It wasn’t better CAD applications. It was something cultural. It was an invisible thread that ran through the car construction process from the drawing board, all the way to the doors being attached and even beyond that.
DevOps is a similar invisible thread that runs through the entire process of IT from the design of the software right out to the software running in production.

High Standards

There are some great talks out there by companies, such as Netflix or Etsy, who really define everything that is DevOps. They have their Continuous Integration pipelines running like a finely tuned engine – including security testing.
They often have new hires push to production on their first day. The testing hurdles in place almost always ensure that no real damage could be done by any naive new hire. Failure here is placed on the infrastructure and not on the new hire.
I usually come away from DevOps related conferences in awe of these speakers and their companies. They set the bar and they spawn many of the best new tools in this field.
But these great forward thinking companies have more than just tools and continuously delivering pipelines. They have the right culture. The culture for learning, for adapting and for seeing the bigger picture. They see how the drawing board relates to final product.

Culture First

Like the Japanese auto industry, the DevOps culture is one of high standards. A rubber mallet is simply a red flag that somewhere along the line the standards must have dropped. It should trigger an investigation into what caused the need for a rubber mallet. It should not trigger a bulk order for more rubber mallets.
Having high standards augments the workflow and results in the need for new tools. The tools around test driven development, agile processes and continuous integration have come from a cultural desire to raise the quality and consistency of delivered software.

Tools First

Culture drives the need for new tools, but new tools generally come from those pioneers at the forefront of innovation.
If you are not at the forefront of innovation then you are less likely creating the new tools, but you are likely to adopt new tools that have been proven. Most large Enterprise IT departments will be in this camp – with the emphasis on “proven”.
We have seen with test-driven development (TDD), Agile and now DevOps that tools can be used in isolation. TDD is the norm – everyone is either doing it or feeling guilty about not doing it. Tools like Jenkins and Atlassian’s Bamboo are helping build out company’s continuous integration pipelines, even if they do not see themselves as “Agile” or “DevOps”.
Is it raising the quality of the software they are creating? Yes! This means that the culture in one organization is driving the creation tools that are being used in other organizations. These other organizations are then getting the benefits as if they did have the culture.
New culture will no doubt lead to new tools, but can we say the same for new tools leading to new culture?

Thinking Tools Is Culture

“We do TDD, therefore we are Agile.”
“Is DevOps part of our culture? Well, we use Jenkins.”
“We’re all about Lean Methodologies – we created an MVP!”
I think it is a fairly obvious statement that using tools associated with a specific culture does not mean that that culture has been adopted. It is hard to understand a culture you are not a part of; therefore, it is easy to falsely assume that you are a part of it. If it walks like a duck and quacks like a duck, it must be a duck, right? Well, some ducks take off their costume at the end of the day and go home to their families.
What defines culture?
I think possibly a set of ideals. I will refer again to Start With Why. Simon Sinek stresses that you must always start with why. What are the core motivations for everything you do?
Why are you using Jenkins? To ensure that all the tests pass. Why? To ensure that nobody commits build-breaking code. Why? We want our builds to always to be good. Why? Why is this is important?

Culture Is A Compass

Tools are important, but these are just stepping stones. Culture helps you focus on the direction you want to go, and lets you see which stepping stones are missing and which new stepping stones you need to create. It helps you see when you need to change direction.
Just using somebody else’s stepping stones will send you in the right direction, but will not help you see the gaps. It means you are always following, so you better hope your competitor does not also have the culture.

Enterprise Adoption

Enterprise IT understands tools. It understands software. There is a problem and there is a solution. There is budget and there is cost to new software. They have a workflow and the new software either fits into that workflow or it does not. When it does not fit, the chances of adoption go down, but the software may have such a compelling story that it is worth the change.
Culture is much harder for large organizations to change.

Conclusion

Enterprise IT no doubt wants to reap the benefits from the tools that DevOps provides but do they do they also want all of the baggage that DevOps brings?
DevOps related tools are created with a DevOps culture in mind. Some would say if you’re using DevOps tools, but not making a cultural change, then you are doing DevOps, but you are doing it wrong. Nobody wants to be that company that is doing DevOps wrong.
Tools alone can take you a long way in the right direction, but it is closer to following breadcrumbs than actually having a compass.

Title image courtesy of Boston Public Library on Flickr under Creative Commons License.