Gene Kim and John Willis recorded a set of conversations called Beyond the Phoenix Project to talk about the DevOps movement since the publication of The Phoenix Project. I read the transcribed version* because I thought it would be easier for me to pay attention. Beyond the Phoenix Project: The Origins and Evolution of DevOps
The conversation is split into nine modules and each cover a topic relevant to the DevOps community - either what went into the original Phoenix Project thinking or where the community has gone for more ideas and inputs. These modules cover a lot of ground and give plenty of references and other suggestions for background and reading. They make it clear from the conversation that the community is constantly looking back to some of the classic ideas as well as looking forward to new ideas from which the community can continue to grow. The first module gives and overview and a flavor of what is to come throughout the conversation, and the final module is a wrap-up.
The meat of the book (conversation) for me is discussions of Goldratt (Theory of Constraints), Deming, and Lean. But they also bring in ideas associated with Safety Culture (newer concept for me) and Learning Organizations (knowledge management circles). All throughout these conversations, they pull in threads from many different sources. They also pull in reminders about how the concepts applied to the story in The Phoenix Project or other well-known (to the DevOps community) examples and case studies.
The first topic (module 2) focuses on Goldratt and Theory of Constraints. Not only does Gene Kim and the community use the ideas beyond The Goal, but they also incorporate many of the other foundational elements of TOC (focusing steps, four questions for technology, chronic core conflict, thinking processes, etc.). Kim emphasizes frequently how important these ideas were to his original conceptions inside The Phoenix Project - he fully admits that the book was templated on The Goal. They also talk about how the TOC community itself has been inwardly-focused - that there is tension between TOC and Lean and other approaches. This seems crazy. They compare this to the DevOps community which seeks to take in any ideas that will be relevant and help.
Then they talk about Deming (module 3) and how his ideas developed had been foundational to a lot of what has happened in management sciences, understanding of uncertainty, and many other elements that are key in the world today. The conversation goes back into the massive changes happening in scientific understanding, changes in the way businesses are run (Frederick Taylor), and the fact that Deming was in the right place at the right time in many cases. Deming's System of Profound Knowledge (14 points) are based around four areas: Appreciation for the system, Knowledge of variation, Theory of knowledge, Psychology. These areas are all incredibly important, and they are connected to many of the elements that have been brought into DevOps from many sources.
Next is the topic of Lean (module 4) and the influence these ideas have had on DevOps. As a mostly outside observer of DevOps, my impression is that they have borrowed significant ideas and concepts from the Lean community. (Having this book summarizes many of the other influences really helped me expand my understanding.) This section confirmed this idea, but also how the various concepts about lean have been applied in the context of DevOps. I also particularly liked the comment that "Toyota was a community of scientists continually experimenting." This reflects very strongly the commitment in Lean (and DevOps) to always looking for better ways to deliver value to the customer. And they have a reframing of the idea of the "seven wastes" that are well known in Lean - that calling what people do as "waste" is dehumanizing. Instead rethink of this emphasis as "reducing toil" - get rid of the stuff that gets in the way of creating value.
And this idea of learning. It's a key aspect of all Theory of Constraints, Lean, the thinking that Deming presents. "If you don't have enough learning opportunities, you cease to get better." We set up experiments and tests with some expectation of results. Then we run the test, get results and explore how and why those results were different from what we expected, which informs and improve our understanding of the system. And gives us clues for the next experiment. And this leads into the 6th module of the book on Learning Organizations - a topic I know and love from my interest in knowledge management.
The 5th module in the book is about Safety Culture. "It's a culture that allows people to give the boss bad news," as defined by Dr. Sidney Dekker. It's this idea that when there is a problem that we look for WHAT caused the problem instead of WHO caused the problem. There is an understanding here that the effects we see come from the underlying system - an idea that is inherent in Theory of Constraints and Lean (but maybe not talked about as much as some of the tools). And it is probably no surprise that Safety Culture has a lot of elements that tie to Learning Organizations as well.
The remaining modules include a conversation with Sidney Dekker, Steven Spear and Richard Cook at the DevOps Enterprise Summit in 2017; a discussion of some case studies; and then a wrap-up. All of these tie back to the main ideas discussed earlier.
I very much appreciate that the thinking behind DevOps has been geared around learning and applying concepts and ideas from all of these areas. I'm sure there are cargo-cultists who simply try to mimic what they see other people doing, but the people who are developing and growing in DevOps are clearly those who are looking at the giants that have come before them, climbing up on their shoulders, doing something new that is relevant to their current view of the world, and then sharing that back with the community to test and refine and develop further. I got a strong sense of excitement and desire to learn from this.
* I suspect the audio version is better, as the transcription seems to be pretty faithful to start-stop conversation structure between two friends. As such, it doesn't read supremely well. There were even a few places where the transcription didn't get the content.