Beyond the Phoenix Project: Modules 4, 5, 6 – Lean, Safety Culture, and Learning Organizations
Beyond the Phoenix Project: Modules 4, 5, 6 – Lean, Safety Culture, and Learning Organizations
Take a look behind the scenes of DevOps thought leader Gene Kim's famous DevOps book The Phoenix Project, in the next 3 modules.
Join the DZone community and get the full member experience.Join For Free
With the influx of DevOps-related products and services on the market, today’s application delivery toolchain has become complex and fragmented. Watch Avoiding the DevOps Tax to learn best practices for integration and automation to realize a faster DevOps lifecycle.
In my last post, I described the first three modules of Beyond The Phoenix Project, along with excerpts from the first three hours — this is from the nine hours that John Willis and I created from the audio series, resulting from hundreds of hours of research into the bodies of knowledge that DevOps draws upon.
In this post, I wanted to share with you details from the next three modules: Lean, Safety Culture, and Learning Organizations. The first two of these areas, Lean and Safety Culture, are the bodies of knowledge that John Willis has long asserted that have influenced DevOps the most. One can see the influences of these two fields almost everywhere in DevOps, including the language we use, the behaviors we desire, in our daily rituals, and so much more….
Module 4: Lean
In Module 4, we describe the origins of Lean, against the historical backdrop of the 1980s — this is the period of existential angst as the U.S. grappled with the seemingly unstoppable ascendency of Toyota and other Japanese industrial companies, who dominated every industry they entered, from consumer electronics (Sony with its Walkman, VCRs, TVs), semiconductors and DRAM manufacturing, and so many more.
By then, Japan’s economy had surpassed Germany’s, becoming the second largest economy in the world — many were projecting it to be only a matter of time before it eclipsed the U.S. In 1980, NBC ran a famous documentary called, “If Japan Can, Why Can’t We?” I remember reading the 1987 best-selling book “The Rise and Fall of the Great Powers: Economic Change and Military Conflict from 1500 to 2000” by Dr. Paul Kennedy, with the famous book cover, showing a person holding the Japanese flag ascending an Olympics-style stage, while the two people holding the U.S. and U.K. flag descend.
This is the prevailing mindset as the Lean movement begins, as entire industries and a broad community of researchers start studying Toyota, trying to figure out what they are doing differently, so that others could replicate their amazing outcomes — for many, this is not just a matter of maintaining competitiveness, but also survival. Over the following two decades, scores of books are published, resulting in a breathtaking set of concepts that are often the exact opposite of the existing orthodoxy, but has almost become almost mainstream today: the value stream, small batch sizes, just in time, limiting work in process, pull, the Andon cord, and so much more.
In this module, we present the timeline of the seminal research and books that are published that starts building the Lean body of knowledge in the 1980s and continues for the following thirty years (!!). It starts with the MIT International Motor Vehicle Project, an ambitious, $5 million, five-year study that resulted in “The Machine That Changed The World” (1989). We discuss the core concepts of Lean, as it is codified by the Lean Enterprise Institute, and some of our favorite books, including those from Mike Rother and Dr. Steven Spear.
I love this module, because it puts so many books that I read earlier in my career into a broader historical narrative. I also now better understand why and how Lean gained so much mindshare, ultimately winning the manufacturing revolution doctrine war, having reached far more people than TQM and Six Sigma (based on Dr. Deming’s work) and Constraints Management (based on Dr. Goldratt).
Listen to the 15 minute excerpt from Module 4 here.
Module 5: Safety Culture
In Module 5, we discuss the other body of knowledge that DevOps draws heavily upon, which is Safety Culture, sometimes referred to as Resilience Engineering or Human Factors. With its origins in aviation, space flight, manufacturing, health care delivery, and nuclear reactor operations, Dr. Sidney Dekker describes safety culture as “a culture where employees can tell the boss bad news.”
Dr. Dekker divides the world into Safety I and Safety II. In the world of Safety I, when accidents occur, we are consumed by the question of “who caused the problem?” — often to figure out who to punish or fire, reminiscent of the pre-Deming notions of command-and-control. On the other hand, in the world of Safety II, because we understand that we are working in a complex system where no one person can possibly understand the system as a whole, we instead ask “what caused the problem?” — only by doing this can we genuinely strive to create a safer system of work.
I did not fully appreciate just how many DevOps patterns we use every day can be traced to this incredibly rich body of knowledge, including the blameless post-mortem, Just Culture, the circuit-breaker pattern, Chaos Monkey and the Simian Army, Game Days, the Google SRE concept of error-budgeting, and the criticality of deliberate design, user-experience (UX) and human factors for complex and mission-critical systems.
In this module, we talk about the important contributions of Dr. Erik Hollnagel and Dr. David Woods, and how they became more accessible through the work of Dr. Sidney Dekker, Dr. Richard Cook and John Allspaw (yes, that John Allspaw). We discuss how these fields have resulted in two important and distinct areas of active work in DevOps: architectural and technical practices, and how a just culture is a prerequisite for managing complex systems.
We dive into these concepts and the characteristics of complex systems in depth, and present the timeline of how these concepts start emerging in the DevOps community, including the paper by Dr. Richard Cook called “How Complex Systems Fail” (1998), and how it was translated to technology domain by John Allspaw in the “Web Operations” book (2009). We discuss how this body of knowledge influenced Adrian Cockcroft and the Netflix cloud transformation, John Rzeszotarski at KeyBank, and how this field remains vibrant and evolving, with the startling concept of “above and below the line” described by John Allspaw in 2017 in his DevOps Enterprise Summit talk.
(On a personal note, during this project, I realized that The Visible Ops Handbook that I co-authored in 2004 was written from the world of Safety 1, where The Phoenix Project and The DevOps Handbook are written in the world of Safety 2.)
Listen to the first 15 minutes of Module 5 here.
Module 6: Organizational Learning
In Module 6, we cover Organizational Learning, which I believe academics will, decades from now, ultimately describe as the superset of Lean and Safety Culture, as well as DevOps. At the heart of Organizational Learning is the notion that high performers win in the marketplace by outlearning their competition.
In this module, we describe some of the key figures in this domain, including “The Fifth Discipline” by Dr. Peter Senge (1990), which interestingly, Dr. Deming wrote the foreword to; double-loop learning and other concepts by Dr. Chris Argyris, which sound incredibly similar to the conclusions of John Shook from the Lean community.
One of the big a-ha moments for me was revisiting the MIT Beer Game, designed as a way to teach managers and leaders the dangers of slow feedback loops in supply chains: it’s a simple game, played often with four people (the beer manufacturer, wholesaler, distributor and retailer), with fifty turns played in an hour. In each turn, each player places an order with their upstream provider, and the goal is to minimize stockouts and excess inventory.
The surprising finding is that across thousands of trials, even with experienced CEOs of Fortune 50 companies, many go out of business long before the fifty turns are over. Often, it only takes one person to over- or under-order for catastrophe to strike, causing the “bullwhip effect,” where errors are rapidly amplified, exhibiting the characteristics of a complex system — even those who “win” describe being extremely frustrated, even wondering whether their teammates fully understood the rules.
Here’s what’s frightening: the complex systems that we deal with every day in technology every day are orders of magnitude more complex than that of the MIT Beer Game. Which shows how important skills described in the learning organization literature are, such as psychological safety, systemic knowledge sharing, education, and experimentation and reinforced learning.
We then discuss in detail the work of Dr. Steven Spear, who describes the four capabilities required to create dynamic, learning organizations, and how so many of these concepts are now mainstream concepts in modern management.
Listen to the first 15 minutes of Module 6 here.
In the next post, I’ll describe the last three modules of Beyond The Phoenix Project, when we hosted a panel of Dr. Dekker, Dr. Cook, and Dr. Spear where they described their lifetime of learnings (three people who we’ve mentioned today!), our favorite case studies from the DevOps community, and why we are so optimistic about the DevOps movement.
I hope you enjoy!
Opinions expressed by DZone contributors are their own.