I picked up The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win a while ago, but only just read it this past week. I enjoyed it, and ended up staying up late to finish it. The structure of the book is quite familiar: business novel; looming disaster; averted with the determination of the protagonist (and colleagues) and the help of a wacky "guru."
Beyond the familiar structure, though, is an engaging story of how a variety of tools I use in my work can really help transform an IT organization and be used as a springboard for transforming business as a whole. The authors appear to use Theory of Constraints as a central organizing principle: they discover the goal of the organization (a couple times); they identify the constraint; they exploit and then subordinate. And while they talk about "elevate," they use it in a way that doesn't quite jibe with my understanding. And they go through this process a couple of times in the course of the book, as they look over more and more silo walls in the business. They even make reference to something other than the TOC Five Focusing Steps - something from questions for technology. There is the idea that if you introduce a change (new technology) but don't change the underlying way you do work, then the impact of the change is going to be much less. The authors also bring in concepts from the Lean and Toyota Production System worlds that emphasize visual control, ongoing learning, and continuous improvement as well. And being an IT-centric story, there are references to things like David Anderson's Kanban system. The story emphasizes that there are things to be learned from many disciplines.
I like how the story brought these things together without diving into the gory details of any one of them. This could also be a drawback, if you are coming to the book looking for answers and direction on how to do these things. One example of this was "the three ways" that the guru character introduced early in the book. These sound like Zen principles, but I hadn't heard them, and the guru kept referring to them as if they were known principles. The short form of these are Fast Flow, Feedback, and Continuous Learning. Written this way, they are very much in line with Lean/TPS.
I also liked the discussion around "types of work" that people do within organizations. The story is focused on IT organizations, but I think this applies generally. They described four types: business-focused projects, internal-improvement projects, changes, and unplanned work. The book emphasized the deadly impact of unplanned work on the other types of work. I usually talk about this in the context of multitasking, but it is interesting to think about the sources of all the multitasking. When we get emergencies (unplanned work), it tends to intensify the multitasking and can often create a vicious cycle where the planned work suffers and creates more emergencies (rework, bug-fixing, etc). The solution in the story and in many of my client projects is similar: find a way to lower the amount of work in process, so people can focus. This is consistent in TOC, Lean, Kanban and other approaches.
The book is the work of a group who have created a manifesto around transforming business through a key understanding that information technology is not a sideline business but is a key business enabler. The last couple of chapters felt more like proseletyzing for their movement, The IT Revolution. The general idea is not so much "information technology is wonderful" but that business leaders must understand technology and how it underlies almost all business needs. They authors clearly see successful companies deeply understanding technology and how it enables them to be competitive.