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. 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. 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: 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. Jul 02, Bjoern Rochel rated it really liked it Shelves: Marvelous 5 star content obscured by sub-par organization and style choices. Sep 11, John rated it really liked it. I didn't finish this the first time I read it and gave it two stars.
I gave it a second chance and found it chock full of valuable advice on managing product development. If I had to summarise the book I'd say it's about taking all the complex interdependent components of designing and building things and making them understandable and manageable through the use of economic frameworks. Just because "Product" is in the title, don't think it's just for product managers, if you're an I didn't finish this the first time I read it and gave it two stars.
Just because "Product" is in the title, don't think it's just for product managers, if you're an engineer or engineering manager I think it's just as valuable. I'd have given it five stars but for two criticisms. The main is that it's just too dry. It's hard to read. Most of these ideas are only applicable in the context of a team, but the book gives you very few tools to help communicate and sell the change in approach.
I also think the economic case for the problems with queues isn't particularly strong, everything else is very nuanced, but felt like I just had to agree with that premise. It's a slog but a valuable one. Jun 10, Charles Eliot rated it really liked it. The Principles of Product Development Flow is an important and thought-provoking book.
It's also a frustrating, condescending, and self-important book. Donald Reinertsen has some vital knowledge to pass on. He wants us to know why the rules of product manufacturing don't work for product development. He also wants us to know that he's a very clever man, and you're probably not. But he has a treasure trove of solutions, based on the simple and elegant practices of computing costs of delay, and ta The Principles of Product Development Flow is an important and thought-provoking book. But he has a treasure trove of solutions, based on the simple and elegant practices of computing costs of delay, and taking into account the impact of queues.
For all my frustrations with the writing and tone, the content of this book is irresistible, and I will probably be referring to a well-thumbed copy for many years to come. Nov 01, Roger K. I cannot recommend this book highly enough to anyone who works on projects, products, or services. Reinertsen is masterful in building a comprehensive approach to product development from manufacturing, networks, computer operating systems, and the military. The author uses principles to structure the book. He provides clear examples, inspiring charts, and practical advice throughout the book.
Yo I cannot recommend this book highly enough to anyone who works on projects, products, or services. You'll never look at the development cycle the same way again once you finish this book. May 11, Dan Lewis rated it it was amazing.
Lean Startup Book
I have not read about lean manufacturing, but I was exposed to some of its practices indirectly in my work at Amazon. This book was very practical for me. It honors the existing orthodoxy about kanban, lean manufacturing, and Toyota, while carefully drawing distinctions between repeatable production and innovative product development. So it serves as a useful introduction into that field, if only by contrast.
In the software world, all development is innovative product development, because it's so easy to reuse the wheel rather than reinvent it. So this book has many lessons that apply directly to software development. But it also has great application to my current domain, which is organizing and optimizing rocket manufacturing at Blue Origin. On many pages, I could find an example of received wisdom at Blue Origin that is questioned by the book. Fortunately, after the author diagnoses the problem treating product development like manufacturing , he provides many practical solutions, such as measuring and reducing work queues, or promoting fast feedback.
These are solutions we will be able to encode directly into the company's software on my team. The interdisciplinary grounding of the book is very interesting. The author uses lessons from economics, control theory, operations research, queueing theory, the algorithms running the internet, and even the Marine Corps. The portions I was already exposed to, such as lessons from agile software development practice, seem normal and used aptly.
It would be hard for me to judge any other area, because I don't have the background.
- Birds of prey (First animals Book 7).
- See a Problem?!
- .
- PANE IN PASTA, PASTELLE, BURRO COMPOSTO della cucina siciliana (IL MIO LIBRO DI CUCINA liberamente tratto dalle ricette di mia nonna Vol. 2) (Italian Edition).
But the book was also a useful entry point into those fields for me, and there's a list of textbook references at the back for Further Reading. If I have one problem with the book, it's that the author is touching the elephant from so many angles that I don't know if I have received an overall theory of development.
Do I understand lean development in a holistic Gestalt? I don't think so. The book contains a list of takeaways, almost its section headings. There are big themes, but the book tends to flatten them where it could have highlighted the most important. I would have liked a final chapter putting it all together, perhaps a case study. All in all though, I think there are too many gold nuggets on the ground to give this less than full marks. Nov 02, Nicholas rated it it was amazing Shelves: Other reviewers have written great reviews about the power behind this book's premise.
This is a fantastic treatise on how product development could and arguably should be. I'll simply say that I am happy join in and applaud Reinertsen for exposing many of us who are in the dark to these core concepts that are blindingly obvious in other industries. Reinertsen's principles together are truly more than just the sum of their parts.
Really Reinertsen is pointing to a completely different way Other reviewers have written great reviews about the power behind this book's premise. Really Reinertsen is pointing to a completely different way of thinking about product development, and I'm looking forward to applying his proposed framework the next chance I get. My only critique is that Reinertsen can be terse at times and more time is required to reflect on what he says that you might originally have anticipated.
This seems to be especially true any time Math is involved. I have a bachelors in Mathematics, and much of what Reinertsen discusses is mathematically accurate, but he typically only lays out conclusions and doesn't really try to help the reader reach the conclusions from the premises. You sort of have to trust him on this if you can't do the proofs yourself. He also readily uses terminology from disparate fields that the reader might not have exposure to such as probability and statistics, control theory, and economics.
Some of the terms used have very specific meanings, like transfer functions, transients, and step functions from the world of control theory. Still, this is a fascinating approach to product development, and I sincerely hope that this way of thinking leads us to the next great leap of innovation in honing our product development processes. Mar 07, Richard Mullahy rated it really liked it. That being said it isn't easy required reading.
Lessons Learned: The Principles of Product Development Flow
Reinertsen does attempt, in his principles-led structure, to make this logical and easy to follow. However there is a lot of looping back and forth and internal cross-referencing that can be distracting.
This book can probably be boiled down to a smaller number of key principles with less elaboration in the body of the text. The key learning though, is that this book looks at the challenges of product development in a different way to what we're all brought up to understand, and the insights that it offers have the potential to massively improve how we do things. A treat to read this book which is a distillation and a validation of knowledge I picked up from a bunch of other books and during years of painstaking work.
I'm a big proponent of the mathematical treatment of agile product development he outs together here with some dollops of critical chain project management thrown in. Living in Germany it is funny to read so many principles that are in direct opposition to local business practices. Halfway through it becomes a bit of a slog but I feel I need A treat to read this book which is a distillation and a validation of knowledge I picked up from a bunch of other books and during years of painstaking work. Halfway through it becomes a bit of a slog but I feel I need to have read all of it at least once to be able to use it as the indispensable reference that it is.
Thankfully the book did end with a chapter on manoeuvre warfare as a cherry on top. Mar 04, Hunter Hart rated it really liked it. This is a book of three different ideas speed, quality, cost. The book busts traditional product management myths and introduces well-known concepts from Lean methods. Mar 21, Eric Bowman rated it it was amazing. 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.
As a software development manager, it reinforces a lot of the concepts and practices I've adopted over the years using scrum. Yet there are still some surprises and lessons and important changes I discovered that I've already started applying to positive effect. The most important moment in the book is probably Figure 8. Metrics for Flow-based Product Development. Really good book but very hard to read.
Along with a lot of deep queue theory and serious mathematical theory interpolation, the advice are often very abstract and hard to understand how to put in practice. Generally the ideas are great and it is worth the effort to read but it is definitively not a light read and requires a lot of work to try to put in practice.
Get New Essays By Email
I liked the mathematical explanations and some of the principles are useful. The book is condensed in some parts where more examples and explanations would be useful, and repeats itself in other parts. Institutionalization of large batch sizes. Managing timelines instead of queues. Absence of WIP constraints.
Reinertsen is not pulling punches. For example, here's him discussing our collective blindness to queues: To understand the economic cost of queues, product developers must be able to answer two questions. First, how big are our queues? Today, only 2 percent of product developers measure queues.
- .
- !
- Memphis Blues: Birthplace of a Music Tradition?
- .
- Histoires comme ca pour les petits :partie 4 (illustré) (French Edition).
Second, what is the cost of these queues? To answer this second question, we must determine how queue size translates into delay cost, which requires knowing the cost of delay. Today, only 15 percent of product developers know the cost of delay. Since few companies can answer both questions, it should be no surprise that queues are managed poorly today. Or take this indictment of our worship of efficiency: But, what do you product developers pay attention to?
Today's developers incorrectly try to maximize efficiency Any subprocess within product development can be viewed in economic terms. The total cost of the subprocess is composed of its cost of capacity and the delay cost associated with its cycle time. If we are blind to queues, we won't know the delay cost, and we will only be aware of the cost of capacity. Then, if we seek to minimize total cost, we will only focus on the portion we can see, the efficient use of capacity.
This explains why today's product developers assume that efficiency is desirable, and that inefficiency is an undesirable form of waste. This leads them to load their porcesses to dangerously high levels of utilization. Executives coming to my product development classes report operating at What will this do? Or consider principle B9: Large batches lead to even larger batches: The damage done by large batches can become regenerative when a large batch project starts to acquire a life of its own.
It becomes a death march where all participants know they are doomed, but no one has the power to stop. After all, when upper management has been told a project will succeed for 4 years, it is very hard for anyone in middle management to stand up and reverse this forecast Our problems grow even bigger when a large project attains the status of the project that cannot afford to fail.
Under such conditions, management will almost automatically support anything that appears to help the "golden" project. After all, they want to do everything in their power to eliminate all excuses for failure. Have you had trouble buying a new piece of test equipment? Just show it will benefit the "golden" project and you will get approval. Have a feature that nobody would let you implement? Find a way to get it into the requirements of the "golden" projec. These large projects act as magnets attracting additional cost, scope, and risk At the same time, large batches encourage even larger batches.
For example, large test packages bundle many tests together and grow in importance with increasing size. As importance grows, such test packages get even higher priority. If engineers want their personal tests to get high priority, their best strategy is to add them to this large, high-priority test package. Of course, this then makes the package even larger and of higher priority. This snippet is characteristic of Reinertsen's writing style and reasoning. He shows how the actions of people inside traditional systems are motivated by their rational assessment of their own economics.
By setting up the wrong incentives, we are rewarding the very behaviors that we seek to prevent. Reinertsen has a visceral anger about all that waste, and his stories are crackling with disdain for the people who manage such systems - especially when their actions are motivated by intuition, voodoo, or blindness. Startups are frequently guilty as charged - the 4-year death march example above could be written about dozens of venture-backed companies slogging it out in the land of the living dead. Reinertsen does not speak about startups specifically - his book is meant to speak broadly to product development teams across industries and sectors.
Yet his analysis of the sources of waste in development and the remedies that allow us to iterate faster are especially useful for startups. There is an important caveat, however. Product development in established companies and markets has a clear economic rationale to judge effectiveness and productivity. The goal is to increase profitability by making high-ROI investments in new products. To give one example, Reinertsen emphasizes the power of measuring the cost of delay COD of a new product.
That is, in order to make economically rational decisions about cycle time for a given process, we should understand what it costs the company if the products produced by that process are delayed by, say, one day. Armed with that information, we can make rational trade-offs. Take one of Reinertsen's example: Unhappy with late deliveries, a project manager decides he can reduce variability by inserting a safety margin or buffer in his schedule. He reduces uncertainty in the schedule by committing to an 80 percent confidence schedule.
But, what is the cost of this buffer? The project manager is actually trading cycle time for variability. We can only know if this is a good trade-off if we quantify both the value of the cycle time and the economic benefit of reduced variability. Does this sound familiar? Many of the startups I talk to - and their boards - seem to equate ability to "hit the schedule" with competence and productivity. Yet timely delivery of new features often comes at the expense of agility, especially if cycle times are long. That is often a bad trade although, as I'm sure Reinertsen would hasten to add, not always!
For example, many startups would do better by removing buffers from their schedules, embracing the variability of their delivery times, and reducing their cycle times. Even worse, and unlike their established counterparts, startups often experience a non-quantifiable cost of delay. In a truly new market, we face no meaningful competition, there are no tradeshows to present at, and customers are not clamoring for our product.
This means that there are no external factors that argue for shipping product on any given day. A day delay has almost no cost, as far as profitability is concerned. Remember that startups operate by a different unit of progress: Any activity that promotes learning is progress, and productivity needs to be measured with respect to that. And that's also where we need to modify some of the specific practices Reinertsen recommends.
If the product development team can be engaged in activities that promote business learning at the expense of shipping - or even selling - product, that's a good trade.
The Principles of Product Development Flow: Second Generation Lean Product Development
Hence the need for partitioning our resources into a separate problem team and solution team. As with any methodology, applying the principles faithfully may require modifying the practices to fit a specific context. Let me close with an excerpt of Reinertsen at his best, using an unexpected example to illustrate the power of fast feedback to make learning more efficient: It should be obvious that fast feedback improves the speed of learning.
What may be less obvious is that fast feedback also increases the efficiency with which we generate information and learn new things. It does this by compressing the time between cause and effect. When this time is short, there are fewer extraneous signals that can introduce noise into our experiment. Team New Zealand designed the yacht that won the America's Cup. When they tested improvements in keel designs, they used two virtually identical boats.
The unimproved boat would sail against the improved boat to determine the effect of a design change. By sailing one boat against the other, they were able to discriminate small changes in performance very quickly. In contrast, the competing American design team used a single boat supplemented by computer models and NASA wind tunnels.