Building a DevOps Culture
Mandi Walls
Beijing Cambridge Farnham Kln Sebastopol Tokyo
Special Upgrade Offer
If you purchased this ebook directly from oreilly.com, you have the following benefits:
DRM-free ebooksuse your ebooks across devices without restrictions or limitations
Multiple formatsuse on your laptop, tablet, or phone
Lifetime access, with free updates
Dropbox syncingyour files, anywhere
If you purchased this ebook from another retailer, you can upgrade your ebook to take advantage of all these benefits for just $4.99. to access your ebook upgrade.
Please note that upgrade offers are not available from sample content.
Chapter 1. Introduction
After a few years of talking about What is DevOps?, a general consensus has started to form around DevOps being a cultural movement combined with a number of software development practices that enable rapid development.
As a technical process, tools have emerged that enable teams to work more quickly and efficiently. Tools alone are not enough to create the collaborative environment that many of us refer to now as DevOps. However, creating such an environment is a huge challenge; it requires assessing and realigning how people think about their teams, the business, and the customers.
Putting together a new set of tools is simple when compared to changing organizational culture. DevOps is a departure from traditional software development practices for just this reason. By celebrating anti-social superstar developers, or allowing code to go to production that wasnt properly tested, or deciding that the only reason the code doesnt run is because Operations is stupid, we are not doing our best to enable the business and create value for our customers.
There are those among us who were doing devops before DevOps. The most successful, rewarding projects I have worked on in my career were those that had an open, professional culture, but by attaching a common vocabulary, we can give others a blueprint for adjusting their organizations culture toward one that is more DevOps-like.
Chapter 2. What Is Organizational Culture?
The concept of organizational culture was developed in the middle of the 20th century, ostensibly by Edgar Shein at MIT Sloan. The idea that a group of people working together in a corporate environment could create a culture distinct from the greater societal culture is now fairly well accepted in many industries. IBM and Walmart are well known for having cultural characteristics that separate them from competitors, for good or bad.
Groups of people create a culture through shared values and behaviors. How we reward behaviors, how we treat those values as malleable or immutable affects how strong the organizations culture is and how well it is supported by the participants. It also affects how the members of the culture will react to attempts to modify the characteristics of that culture.
The last few years have seen a lot of discussion of what DevOps is and isnt. 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 wont 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.
We added a Velocity Culture track to the 2010 Velocity Conference out of recognition that there are important cultural aspects of successfully operating large infrastructures. What is more challenging, however, is how to help aspiring DevOps cultural warriors make modifications to their organizational cultures in order to reap some of the benefits of DevOps. Cultural change in general is a topic widely discussed in business research, and we can borrow from lessons learned by other industries.
Chapter 3. What Exactly Makes a Culture DevOps?
Culture, as an abstract collection of ideas and behaviors, is hard to pin down to a proscriptive set of requirements. In a technical team, its much more easy to talk about what kinds of tools to use and how to use them; the tools themselves are accessible as constructs. The people that will use those tools are complex.
The traditional friction between teams thought of as development and teams thought of as operations boils down to a few key cultural characteristics.
Open Communication
A DevOps culture is one created through lots of discussion and debate. Traditionally siloed technical teams interact through complex ticketing systems and ritualistic request procedures, which may require director-level intervention. A team taking a more DevOps approach talks about the product throughout its lifecycle, discussing requirements, features, schedules, resources, and whatever else might come up. The focus is on the product, not building fiefdoms and amassing political power. Production and build metrics are available to everyone and prominently displayed. The current infrastructure is documented, and maybe someone went to the trouble of having it printed on a plotter, which is totally cool.
Incentive and Responsibility Alignment
One of the early controversial aspects of what became DevOps was the assertion that Engineering should be doing on-call rotations. In fact, this idea was presented in a way that made it sound like your developers would want to be on call if they were truly dedicated to building the best possible product, because they were the ones responsible for the code.
I dont remember now who first articulated this point; my personal DevOps epoch begins with John Allspaw and Paul Hammonds Flickr talk at Velocity 2009, and they may have mentioned it. Regardless, the cultural characteristic here is empowerment. The people who are empowered to directly make an improvement are the ones who are alerted to the defect.
Likewise, your team is incentivized around your core goal: creating an awesome product for your customers, whatever that product happens to be. Development isnt rewarded for writing lots of code. Operations isnt punished when all that code doesnt 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.
Respect
All team members should respect all the other team members. They dont actually all have to like each other, but everyone needs to recognize the contributions of everyone else, and treat their team members well. Respectful discussion and listening to others opinions is a learning experience for everyone. No team member should be afraid to speak for fear of being abused or rudely dismissed.
Trust
Trust is a massive component of achieving a DevOps culture. Operations must trust that Development is doing what they are because its the best plan for the success of the product. Development must trust that QA isnt 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 doesnt trust another part of the team, your tools wont matter. Additionally, if you dont trust the people who work for you, why are they working there? Why are you?