Customer Reviews

The Principles of Product Development Flow: Second Generation Lean Product Development

5 star:		(11)
4 star:		(2)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

If you've ever wondered why agile or lean development techniques work, The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen is the book for you. It's quite simply the most advanced product development book you can buy.

For those who hunger for a rigorous approach to managing product development, Donald Reinertsen's book is epic. Myths are busted on practically every page, even myths that are associated with lean/agile. For example, take the lean dictum of working in small batches. I push this technique quite often, because traditional product development tends to work in batches that are much too large. Yet it's not correct to say that batch sizes should be as small as possible. Reinertsen explains how to calculate the optimal batch size from an economic point of view, math and all. It's wonderful to have an author take these sorts of questions seriously, instead of issuing yet another polemic.

The book is structured as a series of principles, logically laid out and briefly discussed - 175 in all. It moves at a rapid clip, each argument backed up with the relevant math and equations: marginal profit, Little's law, Markov processes, probability theory, you name it. This is not for the faint of heart.

The use of economic theory to justify decisions is a recurring theme of the book. Its goal is to help us recognize that every artifact of our product development process is really just a proxy variable. Everything: schedules, efficiency, throughput, even quality. In order to trade them off against each other, we have to convert their impact into economic terms. They are all proxies for our real goal, maximizing an economic variable like profit or revenue. Therefore, in order to maximize the true productivity (aka profitability) of our development efforts, we need to understand the relationships between these proxy variables.

[...]

I read a lot of books. This is the most important one I've read in 10 years.

Reinertsen synthesizes several tough subject areas: queuing, ToC, Lean, and Real Options. There's rigor here, but it's incredibly accessible and presented in a set of concise principles.

I've bought copies to hand out, and I'm promoting this as a way to put business, technology, and marketing all on the same page. If we can all talk about the cost of delay, then all kinds of emotion-based debate just evaporates.

I won't repeat what others have said except that this new standard on lean product and software development challenges orthodox thinking on every side and is required reading. It's fairly technical and not an easy read but well worth the effort.

For the traditionalist, add to cart if you want to learn:

- Why prioritizing work "on the basis of project profitability measures like return on investment (ROI)" is a mistake
- Why we should manage queues instead of timelines
- Why "trying to estimate the amount of work in queue" is a waste of time
- Why our focus on efficiency, capacity utilization, and preventing and correcting deviations from the plan "are fundamentally wrong"
- Why "systematic top-down design of the entire system" is risky
- Why bottom-up estimating is flawed
- Why reducing defects may be costing us money
- Why we should "watch the work product, not the worker"
- Why rewarding specialization is a bad idea
- Why centralizing control in project management offices and information systems is dangerous
- Why a bad decision made rapidly "is far better" than the right decision made late and "one of the biggest mistakes a leader could make is to stifle initiative"
- Why communicating failures is more important than communicating successes

For the Agilist, add to cart if you want to learn:

- Why command-and-control is essential to prevent misalignment, local optimization, chaos, even disaster
- Why traditional conformance to a plan and strong change control and risk management is sometimes preferable to adaptive management
- Why the economies of scale from centralized, shared resources are sometimes preferable to dedicated teams
- Why clear roles and boundaries are sometimes preferable to swarming "the way five-year-olds approach soccer"
- Why predictable behavior is more important than shared values for building trust and teamwork
- Why even professionals should have synchronized coffee breaks

And the list goes on and on and on.

My favorite sections are Reducing Batch Size, which I use in my Agile courses, The Human Side of Feedback, and Achieving Decentralized Control, on "what we can learn from military doctrine."

Mind-expanding! Bonus: the author includes his email address and promptly responds to inquiries.

Don Reinertsen has written two of the three books I recommend
when someone asks me what to read about product development.
He wrote Managing the Design Factory and co-authored (with
Preston Smith) Developing Products in Half the Time: New Rules,
New Tools (2nd Edition). (The third book I recommend is the
first half of Kiyoshi Uchimaru's TQM for Technical Groups.)

Reinertsen has now written an important new book, The Principles of
Product Development Flow -- Second Generation Lean Product
Development. On page 1 of this book, Reinertsen states his ambition
for the book: "I believe that the dominant paradigm for managing
product development is fundamentally wrong....I believe a new
paradigm is emerging, one that challenges the current orthodoxy of
product development. I want to help accelerate the adoption of this
new approach. I believe I can do this by helping people understand
it. That is the purpose of this book."

I agree that practices like the phase gate review process are a
mistake (and counter productive in even more ways than Reinertsen
lists). My impression from my years leading development organizations
is that the developers themselves also thought much of current
practice was misguided, but they were stuck with what is claimed to
be "best practice."

Reinertsen's book does not give a new process for product
development. Rather, he provides explanations of what is wrong with
current practice, a discussion of eight general "themes" for
improvement, and 175 principles (divided among the eight themes) upon
which to base one's thinking as one develops one's own product
development system.

Buy the book. It is excellent. It will help you figure out how to do
product development better in your own organization.

"Flow" digests the theory in "Managing the Design Factory (MtDF)" into a set of principles. I would suggest you read "Managing the Design Factory" first so you get a solid foundation for the principles. "Flow" is handy because it can be used as a quick reference. IF you have a question of how or why to apply a principle then you should dig back into the first book.

In my review of MtDF I observe that this earlier book covers a bit of queuing theory. The newer book leaves out nearly all of the theory. Still the summary of the principles is valuable. I'm happy I bought the book.

In software development, the Agile movement got a lot of things right. However, the Agile community is, in general, not very good at explaining why their methods work, and debates tend to be dogmatic. This is where this book can add a lot of value.

As a kind of experiment, I tried to explain the phenomenal success of Facebook with some of the core ideas in this book. Many people found value in this analysis.

This book has helped me to better understand my own work, to analyze problems and to justify unpopular decisions. I have benefited greatly from Don Reinertsen's approach.

In this his latest book, The Principles of Product Development Flow, Don Reinertsen challenges what he calls the "current orthodoxy" of product development, which in his view suffers from its failure to recognize, and correctly quantify, economic factors and their essential role in management decision making. Tightly coupled to this discounting of economic factors is the ignorance surrounding the management of queues in the product development process, their impact on development cycles times and, in the end, profit.

This book is a worthy follow-on to two previous volumes, Managing the Design Factory and Developing Products in Half the Time: New Rules, New Tools, 2nd Edition.

More detailed material can be found at http://iablog.sybase.com/paulley/tag/don-reinertsen.

If you are aiming to learn about the core principles behind the Lean and Agile approaches to product development, Don's book is the best resource out there.

Devoid of Dogma, Drama, and Shock/Awe terms/approaches, Don systematically covers all the bases of why Lean/Agile makes sense for Product Development, and what are the underlying principles that make these approaches work.

Best time to read this book is after some exposure to an Agile approach (like Scrum or Kanban), if you are curious as to why it works, and want to go beyond the marketing.

My only gripe is that its only out in hard cover and I cannot have it with me at all times on my Kindle iPad app. I find myself wishing to go back to the book for reference very often. Right now its on loan to my CEO who is loving it as well...

Donald Reinertsen's latest book on new product development aspires to making a global and historical impact. He systematically applies the theory and best practices of lean manufacturing, economics, queuing theory, statistics, web communications, operating systems, control engineering and military science to the new product development process. He summarizes these insights in 8 themes and 175 principles. Examples and graphs illustrate the concepts.

This is a dense book. The target audience of marketing MBA's, industrial engineers, project and general managers will be challenged. It requires some familiarity with lean manufacturing, economics and operations research. The principles are illustrated but not obvious. The quality, lean manufacturing, Toyota Production System, theory of constraints and technical sources are briefly referenced. The rationale for existing (stage-gate) best practices is not explained. Limits and trade-offs are not discussed.

Nonetheless, this is an audacious and path breaking book. Product development practitioners can learn and apply the principles of this book.
Economics trumps simple versions of quality paradigms. Expected net lifetime value is king. Marginal cost/benefit analysis rules. Global optimums outweigh local ones. Proxy measures undermine optimal economic decision-making. Decisions matter, precision does not. Priority features/competitive advantages matter most. Economic rules of thumb allow decentralized decisions. Cost of delay is managed through an explicit value of time.

Queuing theory manages delays. Project and task cycle times drive the cost of delay. Long queues increase defects, variability and risks. Misplaced high efficiency and utilization goals lead to delays, increased costs and disastrous momentum. Communications links between adjacent processes matter more than bottleneck capacity. Simple views that delays, variability, inventory or waste are evil or have infinite cost lead to bad decisions. Queues are everywhere in product development.

Measure variability with a payoff function. It can be negative or positive. Testing generates information value. Statistics based steps reduce variation, such as smaller tasks and time horizons. Counterbalance and design reuse offset variability. Economic priorities, faster iterations and early high risk actions minimize the impact of variability.
Smaller task batch sizes reduce variability and cycle time, accelerate feedback, improve engagement and reduce risk and overhead. Large batches increase costs, delay progress and may spin out of control. Optimum batch sizes are small and can be found through trial and error. Combine features in separately developed and tested modules. Smaller batches are more beneficial than capacity increases. Large batches impact every step of product development.

Detailed planning and control of tasks is costly. It is more effective to control the work in process between major functions. As with TPS or Theory of Constraints, managing the flow of released product from stage to stage improves final results. Many scheduling, prioritization, resource and recovery strategies can minimize task WIP. A blended generalist/specialist staff skills profile offers flexible capacity.

The flow of activities through product development can be managed. Use forecasts and share information between adjacent stages. Use cadence to set routine start/stop times. Synchronize tasks so that dependent events flow smoothly. Sequence tasks and change priorities based upon risk and incremental economic value added. Build in flexible paths and spare resources.

Develop rapid feedback systems. Employ early warning systems and value at risk triggers to escalate reviews. Align activities through training, incentives and templates. Adjust decisively when required. Use frequent communication to build teams and short queues to build urgency. Employ flow metrics.

Decentralize decision making to speed the flow and avoid management bottlenecks. Provide high level structure in the form of rough-cut plans, rules of thumb, intentions, templates and sequences.

The principles in this book can be applied to any operations or development process. The value added is limited only by the time invested.

I am usually too lazy to leave reviews and this is the first time ever I leave a review on Amazon. I've been learning about and working with Agile for around 5 years now and this is hands down the best book on Agile theory. The author does not actually come from software development and he started on the book more so from manufacturing approach however this theory is applicable to any operational process, Agile included. It goes a few levels deeper and explains why keeping sprints short works, why you need to release often, etc, etc.

The author uses statistics to actually prove his statements mathematically. It's not a very light read because of the math and the depth however it's really fascinating to see this broken down at such scientific level.