Building a DevOps Culture

by Mandi Walls

By celebrating anti-social superstar developers, or allowing code to go to production that wasn’t properly tested, or deciding that the only reason the code doesn’t run is because Operations is stupid, we are not doing our best to enable the business and create value for our customers.

by attaching a common vocabulary, we can give others a blueprint for adjusting their organization’s culture toward one that is more DevOps-like.

This part puts words to what I feel everytime I hear someone, usually an embedded- or C++ developer, express that the cloud’s “just someone else’s computer”. The same holds true for DevOps as well: we need vocabulary, no matter how symbolic, to describe complex behavior and ideas easier and clearer.

DevOps is as much about culture as it is about tools, and culture is all about people. No two groups of people are guaranteed to create the same sort of culture under similar circumstances. So to talk about a cultural movement in absolute terms is disingenuous. Implementing a prescribed toolchain won’t magically turn your team into a DevOps team. Using DevOps-friendly tools and workflows can help your team work in a more DevOps manner, but creating a culture that is supportive of the ideals of the DevOps movement is crucial.

your team is incentivized around your core goal: creating an awesome product for your customers, whatever that product happens to be. Development isn’t rewarded for writing lots of code. Operations isn’t punished when all that code doesn’t run as expected in production. The team is rewarded when the product is awesome, and shares in the improvement process when the product could be more awesome.

Trust is a massive component of achieving a DevOps culture. Operations must trust that Development is doing what they are because it’s the best plan for the success of the product. Development must trust that QA isn’t really just there to sabotage their successes. The Product Manager trusts that Operations is going to give objective feedback and metrics after the next deployment. If any one part of the team doesn’t trust another part of the team, your tools won’t matter. Additionally, if you don’t trust the people who work for you, why are they working there? Why are you?

People come with baggage: preconceived notions, past experiences, prejudices. When these individual characteristics are at odds with the culture that we want to foster in our organizations, we create stress. Alleviating that stress means either changing the person or changing the organization they belong to.

One recent anecdote that I found particularly interesting was buried in a story from The Atlantic about recent trends in repatriating manufacturing work to the United States after years of moving those tasks abroad for labor cost savings. The story of GE’s GeoSpring water heater is fascinating, regardless of the underlying drama of globalization and outsourcing. The product was designed in the U.S. and the specifications were sent to Asia for production; the manufacturing process became a black box that the design team sent instructions to. When looking at how to manufacture this particular product in the U.S., they brought together “design engineers,…but also manufacturing engineers, line workers, staff from marketing and sales” to discuss how best to build it, and discovered the design was “terrible” and no one actually wanted to try to build it. It sounds like Development wrote some code and “threw it over the wall” to Operations to figure out, doesn’t it? GE’s integrated team sat down and redesigned the product with input from everyone, and ended up building a better product, at lower cost.

It’s fine to want to change your organization because “everyone” is doing DevOps now, but you’re looking at months of work, new tools to learn and implement, teams to restructure. These costs must be outweighed by the benefits, so you have to be able to put real value on your processes.

Some common measurable goals are: Reduce time-to-market for new features. Increase overall availability of the product. Reduce the time it takes to deploy a software release. Increase the percentage of defects detected in testing before production release. Make more efficient use of hardware infrastructure. Provide performance and user feedback to the product manager in a more timely manner.

all of these goals can have a numerical threshold attached to them. “Reduce deployment time from 10 hours to two hours.” “Increase percentage of defects detected in testing from 25% to 50%.” You can reason about these numbers and judge the success of your transition process.