The DevOps Handbook for Unicorns and Horses

Enterprise Initiatives

Our guest on the podcast this week is Gene Kim, DevOps expert and author at "The Phoenix Project" and "The DevOps Handbook."

We discuss “The DevOps Handbook”, which was started over five and a half years ago and released in October 2016. Gene co-wrote the book with Jez Humble, Patrick Debois, and John Willis. The book includes over 48 case studies that range from unicorns like Google, Amazon, Facebook, but also horses like Nordstrom, Target, and Capital One. Many of the case studies came from the DevOps Enterprise Summit. The book has discussions of both greenfield and brownfield deployments, even touching on mainframes.

The most common question enterprises ask about DevOps is: Where do we start? “The DevOps Handbook” starts with a chapter on starting with DevOps by picking the right value stream. The research started by looking at where successful unicorns and horses started with their DevOps initiatives.

They also look at the failed DevOps initiatives to learn what to avoid. Failures can be categorized in two ways: starting too small or starting too big. Initiatives that start too small often start with a simple Chef or Puppet project end up looking like like more of a hobby. When they finish the project, they haven’t actually proven anything and the project gets easily dismissed. Initiatives that start too large often choose something too critical to the operations of the organization, and is unforgiving of mistakes. The most successful journeys start with something that creates a material contribution to the organization, but is small enough that it does not get shut down early for small mistakes. Their studies found that one out of three leaders who were starting these transformations were being promoted for their contributions.

There is no one answer for how to change an organization’s culture for DevOps, but there is a prescriptive set of guidelines. The technical practices do not change such as version control, continuous testing, continuous integration, automated deployments, proactive monitoring of the production environment, security integrated into every step. What is different is where these initiatives start from. Some come from the Director ofr Operations, a Chief Architect, or even Director of Development. This transformation starts from different people and teams at different organizations. There are many different ways to reach a great DevOps practice.

The three guiding principles of DevOps are:

• Flow : Maximizing the flow of work and minimizing the lead-time
• Feedback: Creating check-ins and the equivalent of being able to stop the assembly line
• Culture: Fostering a culture of continuous experimentation and learning

There is a myth that with DevOps you can’t have any central control. We discuss differences in self-service teams like Netflix and Amazon to function-based teams used at Google and Disney. We look at Etsy’s liason model assigning ops engineers to various service and product teams. Many companies do well with the technical aspects of DevOps, but struggle with the culture changes it requires. Ten years from now, it will be about creating learning organizations and the command and control model will not be effective. It won’t be about who caused a problem or who to blame, but will be about creating a culture of learning for a successful team.