The DevOps Handbook : Book review

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Authors:Gene Kim, Jez Humble, Patrick Debois, John Willis

Released Oct 2016.

The DevOps Handbook was over 5 years in the making and it is worth it. It is a book that details DevOps with plenty of case studies and examples to support the principles and practices.

The book is a useful guide for organisations embarking on a DevOps journey. Case studies throughout show specific application of DevOps principles and describe the history of DevOps. The book covers DevOps for readers from many perspectives including Product Ownership, Architecture, Development, Qualtiy, Information Security, and IT Operations.

The book begins with a history of DevOps and the lessons incorporated from other areas including Lean, Agile, Lean Startup, Kanban, Theory of Constraints, Lean Software Development, System Safety, Learning Organisations and others.

The book is structured around the 3 ways that were introduced in the previous book “The Phoenix Project”. The three ways are:

  1. The Principles of Flow
  2. The Principles of Feedback
  3. The Principles of Continual Learning and Experimentation.


The book describes in detail these three ways with many real life case studies and examples.

The first principle is about increasing the flow of work. We do this by “making work visible, by reducing batch sizes and intervals of work, and by building quality in, preventing defects from being passed to downstream work centers.” We have done this within teams using Kanban and it has been effective but expanding the view of the value stream makes this much more powerful. Projects and organisational silos often obscure the end to end flow of work. (That is, we see project success without seeing the effort pre and post project.) It highlights the cost of multitasking, the loss of knowledge with each handoff and the fact that systems have constraints and improvement away from that constraint is an illusion.

Lean is about reducing waste but the book has this to say about waste in the knowledge work context: “‘eliminating waste’ can have a demeaning and dehumanizing context; instead, the goal is reframed to reduce hardship and drudgery in our daily work through continual learning in order to achieve the organization’s goals.”

The second principle is about principles that “enable the reciprocal fast and constant feedback from right to left at all stages of the value stream. Our goal is to create an ever safer and more resilient system of work.”

Before we can get to “fast and constant feedback” we need to have flow which is why we need to make progress on the first way before the second.

Feedback is especially important in complex systems when cause and effect is often only recognized in hindsight. In software development feedback is enhanced by automation and telemetry. Automated testing and monitoring systems can significantly increase the speed of feedback.

The third principle of Continual Learning and Experimentation. This requires a culture that requires and actively promotes learning – “instead of work being rigidly defined, the system of work is dynamic, with line workers performing experiments in their daily work to generate new improvements, enabled by rigorous standardization of work procedures and documentation of the results.”

The Westrum model of organisational models (see link below) uses splits culture into three categories of Pathological, Bureaucratic and Generative based on how communication flows. Observations in healthcare organisations indicated that the presence of a generative culture was one of the top predictors of patient safety.







From The Westrum paper below.

This also fits closely with sense and respond, continuous improvement, kata, and learning organisations.

The book goes into detail regarding automation and hypothesis driven development and risk management including a specific chapter on information security in a DevOps world.

I recommend this book for people wanting to understand DevOps or to understand why software should not be treated the same as creating widgets.

I also recommend watching conference presentations by the authors.