Five years in the making, the DevOps handbook arrives

Gene Kim thinks he has at least one thing in common with George R.R. Martin: They both take their sweet time writing highly-anticipated sequels.

In Kim's case, however, the wait is over. Kim's particular song of fire and ice—or rather, two equally opposing forces, "dev" and "ops"—continues this month.

Fans of 2013's The Phoenix Project—a novel about organizational life inside the often all-too-real Parts Unlimited, which depicted in vivid detail the radically lean approach to IT work that would eventually become known as "DevOps"—now have their follow-up, The DevOps Handbook.

"Five and a half years in the making," Kim says with his characteristic, infectious chuckle.

Completed and published earlier this month in collaboration with co-authors Jez Humble, John Willis, and Patrick Debois, the book serves as a textbook for seasoned DevOps practicioners and newcomers alike, one built on years of interviews, observations, and conversations.

"I cannot tell you just how much I've learned since even 2013," Kim says. "I don't think I've ever learned as much as I have any time in my life as over the last three years."

Interestingly, Kim and co-writers initially conceived the Handbook as the initial vehicle for introducing the world to the then-nascent practice of dismantling prohibitive boundaries separating organizations' software development and IT operations teams. But they soon realized the enormity of the task before them.

"It was just so clear that there was just so much that we didn't understand well enough yet," Kim says.

So Kim instead began work on The Phoenix Project, and the sequel became the prequel (perhaps Kim is more like George Lucas than Martin). The book has since slipped to and from many an eager and appreciative hand in progressive IT circles.

"I think The Phoenix Project does a good job of capturing the hearts and minds of people," Kim says. "It has really created the appetite—or it has surfaced the need for a more prescriptive guide of how to get from here to there."

The Handbook is that guide. While Phoenix Project was technically fiction, it presented a new organizational model so refreshing, compelling, and competitive that its ideas materialized in IT shops around the world. Tales from those shops constitute the roughly 50 case studies illustrating various ways high-performing organizations (like Capital One, Target, and Nordstrom—even the United States government) have successfully implemented the special brand of collaborative, iterative, and data-driven work that Kim has spent the past decade chronicling.

He's also been refining his model. In the Handbook, Kim says, he's finally able to describe DevOps as consisting of three dimensions.

First is architecture, something that "enables small teams to work independently and quickly so so they can independently develop tests, and deploy value to the customers without having to coordinate with hundreds—or even thousands—of other engineers."

Second is what Kim calls "technical practices." These are things like "version control, and continuous integration, and proactive production telemetry"—the concrete activities that take place within those nimble architectures.

And then there are what Kim calls "cultural norms," the attitudes, habits, and beliefs that guide the pratices in the structures.

"How do we foster a culture of learning where it 's safe to fail?" Kim says,offering one example. "Because that psychological safety is needed to talk about mistakes, and that 's required to enable prevention."

The new tripartate schema allows Kim and co-authors to provide organizational leaders with more targetted advice and guidance. Today, Kim says, leaders need to focus on architecture, technical practices, and culture if they hope to create high-performing teams. They need to set "the emotional tone" that influences "how people bahave to each other," he says.

"Only the people at the top can set the tone at the top," Kim says. "They demand excellence. They really demand excellence, and have that be a part of how to measure people."

Moreover, Kim has noticed—and has begun advocating—cultures of continuous learning, something the 20th century's hierarchical modes of organization typically ignored. These are cultures with a strong mandate "to learn, teach, because we need that innovation in order for us to win in the marketplace," Kim says.

"In a just world, every technology leader will be talking like that. I think that's so contrary to the way that, I think, managers, that we've been trained for the last century," he says.

Listening to technology leaders talk about change is what Kim does best—and he'll do much more of it in November, at the DevOps Enterprise Summit in San Francisco.

The event brings figures of DevOps success together with aspiring innovators to accelerate the pace of change in IT and beyond.

"What a privilege it is to chronicle that journey," Kim says. "The DevOps movement has barely begun. Despite how much we hear about it, it's barely started."

That's enough to warrant a trilogy, at the very least.