I have been following Clarke Ching's efforts to write Rolling Rocks Downhill over the years, including reading one or two early versions. But somehow the final published version felt very different from the earlier versions. One thing that hasn't changed - I could hear him in the voice of the main character I read the book to myself. I've noticed the same thing when I've read other books by people I know in real life.
In some sense, the book is a classic business novel in the Theory of Constraints vein: the main character (Steve) has a major problem: the software project that he thought had nine months gets pushed to finish in six and then even faster due to market pressures. The situation seems hopeless, but then he begrudgingly asks for help from a "guru" (on an ultimatum from his boss). In this case, though, the guru isn't positive that he can solve the immediate problem - though he does think he can help Steve in general. The guru leaves Steve alone for long stretches with various things to ponder - come to think of it, this isn't too far from "Jonah" in The Goal. One thing that was interesting about this guru is that he often didn't have the answer - not that he didn't want to say, it seemed he truly didn't know (and was willing to admit it!).
The story develops, and Steve learns a lot. The guru introduces some TOC and Lean concepts, and some of Steve's business partners introduce some new ways of thinking as well. He learns about the constraint and why it is important to identify it. He learns that forecasts are always wrong and spending too much time refining them is often time wasted. He learns ideas about smaller and smaller batches to create speed.
In the end, the team pulls off amazing feats and pulls the company from the brink of irrelevance. One of the biggest things they do is break a huge conflict that sat at the bottom of their reality: take actions for the short term or take actions for the long term. Do it fast or do it right, and they couldn't see a way to do both.
While the story is about the struggles of the development team and the larger business, one of the biggest take-aways for me is the way Clarke describes the Evaporating Cloud (or Conflict Diagram), which is a classic of the Theory of Constraints thinking processes. He also combined it with some thinking from Kelvyn Youngman that brings in the 4 views of change. Clarke has this available on his website as well.
Classically, the Evaporating Cloud is a diagram to help articulate the logic behind conflicts that occur. One describes an overall goal (A) and two needs of the system (B and C). Each of the needs generates and action (D and D'). The two actions are where the conflict resides. One reads it: In order to meet the goal, we must meet needs B and C. In order to satisfy B, we believe we must do D. In order to satisfy C, we believe we must do D'. And D and D' cannot exist at the same time. Just as important, taking action D puts need C in danger, and doing D' puts B in danger. We are in a conflict. Often organizations will find themselves swinging between actions as one need or the other becomes predominant. But both needs are important - but we compromise to get less that full amount of each need. A central tenet behind TOC is that all conflicts (of this type) can be removed - "evaporated." The key behind these diagrams is what connects the lines - the process of building the diagram helps to expose the assumptions underlying the "we believe". Why must we do D? or D'? What makes them conflict? As you (and the team) think through this - talking it out often helps - the reasoning behind why one action or the other comes into play. Could there be different actions we could take that allow us to meet both needs?
Conflicts are sometimes articulated with statements like, "On the one hand ..., but on the other hand ...." What Clarke has done in the book (through the guru) is to take this kind of statement and make the conflict cloud more physical. Turning the cloud, so that "A" is on the top, he draws a stick figure with D and D' in each hand. B and C on the shoulders - representing the "weight" of each need. And then the common goal is the head. He even take the idea of actions jeopardizing the opposite need: poke yourself in the opposite shoulder with your index finger. I really liked how this description of the conflict diagram has a physical feel to it - much more visceral than the dry cloud on a white board or a piece of paper.
The other thing he brings to the cloud is from Kelvyn Youngman. The cloud can be mapped to the four views of change: the benefits and hazards of a change, and the benefits and hazards of not changing. (This is best illustrated in the entertaining video on "resistance to change".) In Clarke's setup, below each hand you add the pro's and con's of the action. Understanding these pro's and con's helps to articulate the needs. And it helps to draw out the assumptions underneath the arrows in the conflict diagram. This is all described much better in chapters 13 and 14 - go read it there.
In the story, Steve and the guru develop the conflict diagram for Steve's software project. But then later on, there are a couple other conflicts that don't get their own diagram. What Clarke does though is describe Steve weighing the conflict in his hands and wriggling his shoulders as he thinks through the needs. There was even the line, "My shoulders ached from the weights I carried with me that day." This language, for me, makes the conflict feel much more visceral. (I've heard that TOC for Education encourages children to draw the conflict on the playground and stand in the boxes to discuss interpersonal conflicts.)
Another classic "problem" in software or any knowledge-work environment is Parkinson's Law: usually formulated as "the work expands to fill the time allotted." Clarke took another direction with this one in the software development world, "The scope of the project always expands until it's too big to fit in the time available to deliver it." When development happens in big batches, people throw more and more into the project until it bursts. He gives some great examples of this as he discusses the problem with a colleague (in Chapter 11). They also suggest the opposite: if you cut the scope to make the delivery date more reasonable, people might relax or slow down. This is the Student Syndrome: I don't need to worry because I have plenty of time. (Note: People aren't bad, this is a natural reaction to the environment we are in. And the extent of either of these varies by person / company / group.)
One final item: I've known for a while that Clarke has a sense of humor. It's in the writing - the little things like the coffee jokes or the expensive-looking pen that the guru carries. Or the fact that the book website is Clarke Ching www.Rolls.Rocks. And his humor shows up in the sub-titles of the book. On the Amazon page for the book, the subtitle comes up as "How to Ship YOUR Software Projects On Time, Every Time." But on the cover of the paperback it says "The Agile Business Novel." And the Kindle on Amazon, the cover says "The Agile Business Novel (which never mentions Agile)". But then on my Kindle device, it says "Accelerate AGILE using Goldratt's TOC." And in the book itself, the subtitle shows up as, "Read this when your AGILE implementation sucks."