Weirdly good. It talks about processes that have existed forever manufacturing that we're only now discovering in Software Development. And it goes *really* in-depth into them, including ideas like queueing theory which was very new to me. It *is* written like a textbook though, which makes some of the information less accessible than it should be. ( )

This was sometimes a frustrating read. The author wants this to be a dense reference resource rather than a long explanatory text. This is fine. I can pull out the internet to look up unfamiliar terms. However, I do think that Reinertsen's brevity hurt his core arguments at time. For example, much of the discussion of the impacts of queues depended on details of the M/M/1/∞ queue. The shape of the conclusions apply to other queueing disciplines, but the equations don't apply exactly. It would have been useful to at least address that.

That said, this was still a highly worthwhile read. It lays out major themes in how to think about product development that offer a more nuanced view than most methodologies do. For example, Reinertsen discuss in multiple contexts the trade-offs between large and small batch sizes. Large batches can be more efficient to process in isolation, but at the cost of increased delay, slower feedback, and slower iteration. In general, Reinertsen believes product development tends to bias too much toward large batches, but he acknowledges that the right queue size depends on the situation.

I'll go into a bit more detail about the major themes of this book, although it's worth noting that there's much more than I can usefully summarize.

The first theme is that decisions should be made based on economic criteria rather than proxy variables. Reinertsen uses life cycle profits as the key economic measure, but the deeper point is that trade-offs should be made based on consideration of the underlying value you're trying to achieve rather than proxies. The example above about batch sizes is a good illustration. It would be easy to declare a principle about what the right batch size is, but instead, the particular economic trade-offs of batches in a particular situation should be taken into account.

The second key theme is queues. By thinking about queues in a mathematically rigorous way, we can better understand the impact of queues and high utilization rates. The key takeaway from the discussion of queues is that as resource utilization goes up, the total amount of time work spends waiting rather than in process goes up dramatically. Depending on the exact queuing discipline, there's generally a fairly dramatic uptick in the proportion of time spent waiting once utilization of the resources doing the work exceeds somewhere between 70% and 90%. Accurately measuring utilization is hard (plus, people tend to think that high utilization is a good thing), and changing it is even harder. It's much easier to monitor and control queue length and queue wait time. The other key observation with respect to queue size is that not all tasks have the same cost of delay. By taking cost of delay into account when pulling work from queues, you'll make better trade-offs than if you use a non-economic discipline like FIFO.

The third key theme is variability. The standard view is that variability is bad. This view comes from manufacturing where tasks themselves are uniform, so economic payoff is maximized when variability is minimized. Product development contrasts with manufacturing in that there is much more inherent variability in the tasks and also much more variability in payoff. Each widget you make gives the same profit, but every new product you develop has different trade-offs for both profit and loss. Instead of focusing on reducing variability, focus on reducing the cost of variability, e.g., through working through risks early instead of late so that less will be invested if the project fails. Importantly, the variability is still here. Some work may work will take much longer than

Theme number four is batch size. Although, as noted above, batching can sometimes be the right trade-off, controlling batch size is one of the key ways of controlling queue size (and, therefore, delay). Batch size tends to have a U-curve relationship to economic costs, with small frequent batches decreasing cost over large infrequent batches up until the point where the fixed-cost overhead per batch dominates the cost. But even then, small batches can be the right choice since the fixed costs can often be reduced and frequent batches provides motivation to do so.

Work in progress (WIP) constraints are one of the primary mechanisms for controlling queue size. By providing local WIP constraints for each queue and not allowing upstream workflows to add work to full queues, over utilization at one workflow can fairly quickly propagate to upstream workflows, leading them to adjust their rate of work production or figure out how to increase the capacity of downstream flows.

Principle number six is the importance controlling flow through cadence and synchronization. Having a regular cadence for work can reduce the cost overhead of smaller batch size. As a tiny example, if a project is reviewed on demand, then setting up the review meeting is a lot of effort, but if a review meeting has a repeated schedule at an appropriate cadence, that cost is lowered. Synchronization often builds upon cadence although it's not the same. Synchronization is the observation that if work is arriving to a queue at a random wait, then wait times will be longer than if the two workflows are syncronized so that the first produces work at approximately the rate at which capacity is available at the next work flow.

Fast feedback sounds like a non-controversial principle, but large queues, large batch sizes, and long delays have the unintended effect of slowing down feedback. This is problematic because fast feedback is especially important when trying to control risk and the cost of variability. An organization that deeply values fast and frequent feedback will structure work differently than one which is focused on maximizing utilization as a measure of efficiency.

The final approach for improving development processes is balancing centralized and decentralized control, erring much more on the side of decentralization than organizations currently tend. This is the section that had the most novel-to-me domain of inspiration: the military. Despite stereotypes, the reality of war is that decentralized groups must be able to make dynamic decisions based on local conditions to achieve a larger objective. To balance centralization and decentralization, Reinertsen suggests using more decentralization for solving frequent, low cost problems where speed is advantageous. Centralization is valuable for infrequent, large problems or when it's significantly more cost effective to centralize decisions. One approach is to assume most problems are amenable to decentralization and then have a well defined escalation process for when that's not the case. For decentralization to be effective, leaders need to make sure that the decentralized decision makers are aligned with the larger organizational goals. Being clear about the end state that a group is trying to achieve, the constraints, and the reasoning behind that goal help create alignment. Transparency in decision making process also helps; leadership in a decentralized organization should consider their job to teach everyone how to make good decisions even more than making good decisions themselves.

This only begins to scratch the surface of the content of the book. Overall, it was well worth the read, and I spent much more time reading it than usual because I kept pausing to think about the principles involved and how they apply to my work. ( )

A deep book which exposes the systematic flaws arising from a naive application of agile principles at scale. In particular, though not mentioned, this book provides the foundation for why feature teams and Inner Source are so important for realizing global efficiency in turning ideas into products. ( )