Scan barcode
erikars's review
4.0
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.
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.
poenaestante's review
2.0
There are some good concepts here that I've applied to technical project management and leadership over the years, but the book itself is dry as a bone. My old boss swore by it as the foundation for his approach to engineering management but even he had to admit the damn thing was tryptophan in paper form. Has anyone ever really read this thing cover to cover? I highly doubt it. Bring on the Cliffs Notes version.
nimishg's review
4.0
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.
chrisxaustin's review
5.0
I started reading this but stalled partway through since it wasn't as engaging as the other books in my queue, but revisited it after reading The Phoenix Project and Team of Teams and found it much more engaging with that framing.
It's an excellent book that added support for things I already believed, provided analysis around things that were more gut feeling before, and also made me rethink some of my beliefs and practices. I have a long list of changes to implement.
My recommended order is Phoenix Project, Team of Teams, then the three Idealcast episodes with one of the authors of Team of Teams, then this.
It's an excellent book that added support for things I already believed, provided analysis around things that were more gut feeling before, and also made me rethink some of my beliefs and practices. I have a long list of changes to implement.
My recommended order is Phoenix Project, Team of Teams, then the three Idealcast episodes with one of the authors of Team of Teams, then this.
corrompido's review
4.0
Another work book, but one of the better ones I've read in a long time. It's a rather technical (lots of formulas and graphs,) look at alternative ways to manage product development.
In many ways, lots of software organizations are following some of the precepts here, but if nothing else the author offers a much more interesting mathematical model as to why those precepts are good than Scrum & Agile teachers normally do.
Another fascinating thing that this book did was talk about why Kanban (and Six Sigma,) are completely wrong for software development, but then lays out what parts of those process frameworks are still useful and why.
I loved the deep technical layout of how economic functions impact decisions in resource and time allocation. Part of the book seemed a little tacked on at the end, but otherwise lots of interesting stuff to think about in here.
In many ways, lots of software organizations are following some of the precepts here, but if nothing else the author offers a much more interesting mathematical model as to why those precepts are good than Scrum & Agile teachers normally do.
Another fascinating thing that this book did was talk about why Kanban (and Six Sigma,) are completely wrong for software development, but then lays out what parts of those process frameworks are still useful and why.
I loved the deep technical layout of how economic functions impact decisions in resource and time allocation. Part of the book seemed a little tacked on at the end, but otherwise lots of interesting stuff to think about in here.
robert_bose's review
5.0
Excellent book. A bit hard to get into (to start) as it is a bit like a textbook, but once you do it's fantastic.
tobysinclair_'s review
4.0
This was a very hard read and it's taken me almost a year to get all the way through the book. I found the writing style and dense information quite hard to consume and I could only do a few pages in any one sitting. Once you get familiar with the writing style it's full of amazing insights. The chapters on Batch Size Reduction, Queueing Theory and WIP Constraints are incredible.
danslimmon's review
4.0
This book basically lays out the mathematical and economic case for agile development.
Agile and kanban didn't just spring fully formed from the forehead of the Scrum King; they're methodologies designed to get the most economic value from your organization's processes. And if you don't understand the reasoning behind your methodology, then you're bound to misuse it.
Agile and kanban didn't just spring fully formed from the forehead of the Scrum King; they're methodologies designed to get the most economic value from your organization's processes. And if you don't understand the reasoning behind your methodology, then you're bound to misuse it.
More...