More on this book
Kindle Notes & Highlights
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.
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 organization’s 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.
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.
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
...more
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 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.
When we first join new organizations, we go through a learning process, discovering the mores and acceptable behaviors of that organization, be it a new company, a sports team, or the PTA. It’s common to get different answers to questions like “Why are we doing X this way?” from different people. When we hope to change the prevailing culture of the group, we need to assess the current state of that culture, and ask all of the questions about why we’re doing X the way we are.
The one question you must ask is “What is our primary business goal?” You need to know what people have decided is the motivating factor for the business as they know it. If the organization’s leadership has done a good job of communicating the organization’s goals, you’ll find most people are on point.
Proving change is necessary requires some legwork. 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.
