IT Revolution recently published an audiobook with nearly eight hours of conversation between Gene Kim and John Willis; Beyond the Phoenix Project; the Origins and Evolution of DevOps.
The Phoenix Project, a novel about IT, DevOps and Helping Your Business Win, published in 2013 and written by Gene Kim, George Spafford and Kevin Behr, is itself a homage to The Goal, a novel about manufacturing, written by Eliyahu Goldratt and published in 1984. Goldratt also followed The Goal in 2003 with an audiobook: Beyond The Goal: Eliyahu Goldratt Speaks on The Theory of Constraints.
Kim and Willis' audiobook collects personal observations and insights into their journeys in DevOps via conversation through nine modules referencing the influencers and thinking that has driven DevOps to what it is today. Kim defines the core chronic conflict for DevOps:
In order for technology to help our organisations win in the marketplace, we have to respond to urgent business needs. That means we need to be able to ship changes ever more quickly, but we also have to preserve world-class reliability, security, and stability. But that means we can make changes never. Both valid business goals. You have to respond to urgent business needs, but we also have to preserve security and stability. Diametrically those actions - make changes more frequently and quickly versus making changes less frequently and more carefully - are opposed. In some ways that really is the embodiment of Dev: ship, ship, ship. Whereas Ops was all about preserve stability, which means never ship again.
Willis and Kim describe the purpose of the audiobook as:
We have learned so much since 'The Phoenix Project', even before we started working on and completed 'The DevOps Handbook'. We're putting that together in a body of work to expand people's knowledge and to help companies become high-performing organisations. We can take all of these disparate bodies of knowledge and show how they're all converging to help make DevOps possible; it's the first time that these principles are being deployed at an industrial scale.
The first module focuses on The Phoenix Project itself, the second on Goldratt and the third Deming. Modules four to six address the theories and practices of lean, safety culture and learning organisations and the final three modules look closer at what we can learn from these experts (including a recording of a panel discussion hosted by Kim with Stephen Spear, Sidney Dekker and Richard Cook), some case stories (Nordstrom, Target, Disney, Marks & Spencer, CSG, Microsoft, Colombia Sportswear, Walmart, Nike and Goldman Sachs) and draw some conclusions.
Kim and Willis reference many works throughout the audiobook, recognising that they themselves are 'standing on the shoulders of giants' such as Goldratt, Deming, Spear, Mary Poppendieck, Ben Rockwood, Mike Rother, Mark Burgess, Peter Senge, Simon Sinek, Eric Ries, Sidney Dekker, Dr. Carlota Perez, Donald Reinertsen and L. David Marquet. They discuss numerous principles and practices including mental models, the chaos simian army, COSO cube, drum-buffer-rope, current reality trees, determinism, hypothesis driven development, ETTO, bad apple theory and Westrum's Typology of Organisational Culture.
Both Willis and Kim reflect on how readers of The Phoenix Project frequently voice their recognition of the characters and narrative:
We hear things like: 'I know that character. It seems like Gene snuck into my building when he wrote The Phoenix Project,' and 'Holy cow! What's happening to Parts Unlimited is what's happening to us!' One of the unexpected delights that came out of 'The Phoenix Project' is just how deeply the character Brent resonated with the DevOps community, because we've either all known one, or more likely, we've all been one.
Kim describes the design goals of The Phoenix Project:
To create an isomorphic mapping between the Lean principles as applied to manufacturing and the Lean principles as they applied to the entire technology value stream. Our hope was that, in 'The Phoenix Project', we could describe in equal clarity every sort of problem that every functional silo in the technology value stream also faced.
Willis and Kim discuss the importance of having people and practitioners pushing the DevOps movement forward: Kim says:
Kind of an a-ha moment for me is that it's one thing to put out a great theory, but if you don't have a vibrant community out there who can actually deploy that into industry, then it really becomes an academic, more intellectual work... There is no community I've seen that has been so voracious and eager to borrow ideas from different domains and incorporate them into how we do work. That's why I'm just so optimistic about DevOps and the DevOps community.
Willis and Kim discuss the underpinning principles of DevOps, The Three Ways in detail in the audiobook and frequently reference one of Kim's mentors, Dr. Steven Spear, a student of the Toyota production system who advocates seeing problems as opportunities for learning. Kim summarises The Third Way as:
This culture that fosters risk taking, so we can learn from successes and failures. It says that repetition is a prerequisite to mastery. But then it also says it's about a culture that creates a continual experimentation and learning culture. There's a school of thought that says how high performers win in the marketplace is because they out-learn the competition. Andrew Shafer said: 'You're either a learning organisation or you're losing to somebody who is.'
During the panel discussion in module seven, Dr. Spear builds on characteristics of DevOps culture from a psychological safety perspective:
Fear doesn't necessarily have to lead to cowering. Cowering only occurs when your brain almost literally short circuits and gets into a do loop of 'What do I do? What do I do? I don't know, I'll just sit on the floor behind a chair and hope the problem goes away.' But that's not what we're talking about. What we're talking about is, with discipline, rigour, energy, enthusiasm, and optimism, recognising moments where we're not understanding what we should be doing and how we should be doing it, saying, 'Yeah, but I know how to address that, because I'm trained and practiced in part of a profession of problem solvers,' so it need not lead necessarily towards paralysis.
Sidney Dekker brought these two ideas together:
I think Allspaw has said it beautifully, that an incident is an unplanned investment, and if you don't see it that way as a leader, you are not getting a return on the investment that was already made on your behalf.
Kim explains the purpose of automation in the DevOps model:
We want to automate as much as possible, and where we can't automate, we want to reduce the number of handoffs so that we can get as close to single piece flow as possible. Ideally, we are deploying all the time in single piece flow safely, securely, and reliably.
Willis explores the importance of automation from another level:
The real magic happens not just because of the automation, it's because of the analysis of the value stream from a waste viewpoint and, more importantly, the ability to look at bottlenecks from a global optimisation perspective.
Kim and Willis frequently reflect on the outcome of value when using these and DevOps principles to understand and improve work in the technology industry and the importance of close collaboration between the technology teams and the rest of the organisation. Kim observes:
It's so interesting where the bottleneck ends up. I first heard this from Adrian Cockcroft at Netflix and Roy Rappaport at Netflix too. Adrian said: 'Then the constraint ends up being the product owners and how many ideas we can come up with.' In other words, how many good ideas are actually worth testing with real live customers? He said the bottleneck shouldn't be Dev or QA or Ops or security. That's not where we want the bottleneck. And I think that really goes very well with the thesis that Eric Ries and Steve Blank said: the bottleneck should be the creation of good ideas.
Kim and Willis recognise that the nature of work in the technology industry is often challenging since software is often invisible and the complexity of the systems and weight of technical debt can make them unreliable and fragile and difficult to understand. Willis says:
Deming's ideas have gotten us to a place where we have no choice but to deal with uncertainty, and there's my theory that he has created a path for us to better absorb uncertainty. So, the melding of failure and efficiency - this is something we talk a lot about in DevOps, about the counterintuitive nature of going faster and being more resilient.
Kim and Willis also explore resilience and site reliability engineering in some detail and use error budgeting as an example of how speed and reliability can be balanced. Kim:
The error budget construct is one of the best examples of a self-balancing system. If the developers want to go fast, it can go as fast until they hit the brick wall where they've lost the right to go fast. On the other hand, it rewards ones who can do things well, and they can go as fast as they can demonstrate where they haven't lost control defined by the service-level objective.
During the panel conversation with Stephen Spear, Richard Cook and Sidney Dekker, Cook makes the following observation around sharing the knowledge, learning and expertise within the community:
DevOps is not simply the practice of fixing problems or generating velocity. DevOps is also the practice of building a community of people who do DevOps. I think you have a kind of moral responsibility to share that expertise with the people around you, to help them become better prepared to deal with the kinds of problems that they will deal with, even though you aren't going to be there at their side. I think that responsibility needs to become part of what DevOps is. I think DevOps needs to go beyond tool chains and beyond repositories and become a kind of practice that involves people. What John has called 'above the line.' To do this may require that we identify ourselves as people who practice DevOps rather than people who work for company x. That is, the practice of being a DevOps person has to be, actually, a kind of profession, a kind of skill, an expertise that exists apart from the particular employment that you're engaged in right now.
Kim and Willis conclude that the high performing organisations that harness the DevOps principles and practices they have observed can be described as 'Dynamic Learning Organisations' and that DevOps is likely a critical part of the next surge of productivity.
You can download the full Beyond The Phoenix Project audiobook here or the full transcript here.
