the principles of product development flow; second generation lean product development

Download The principles of product development flow; second generation lean product development

Post on 07-Jul-2015




5 download

Embed Size (px)


The principles of product development flow; second generation lean product development


  • 1. The Principles ofProduct DevelopmentFlowSecond GenerotionLean Product DevelopmentDonald G. ReinertsenCELERITAS PUBLISHINGRedondo Beach, California

2. Celeritas PublishingRedondo Berch,CA90277www.CeleritasPublishing.comCopyright @ 2009 by Donald G. ReinertsenAll rights reserved. No part of this book may be reproduced or transmitted in anyform or by any means, electronic or mechanical, including photocopying, recording,or by information storage and retrieval systems, without the written permission ofthe publisher.For information on discounts for bulk purchases, contact Celeritas Publishing at:SpecialSales@CeleritasPublishing.comPrinted in the United States of America1098765432Library of Congress Control Number: 200891 1906Publisher's Cataloging-in-Publication DataReinertsen, Donald G., 1950-The principles ofproduct development flow: second generationlean product development/Donald G. bibliographical references and index.ISBN- l3: 978- l-935401-00- IISBN- l0: I -935401 -00-9l. New products. 2. Product management. I. Title. 3. Dedicated to my mother and my fatherMARY VIKTORIN REINERTSENLEIF CHRISTIAN REINERTSEN 4. l.ContentsThe Principles of FlowWhat Is the Problem?A Possible SolutionThe Relevant Idea SourcesThe Design of This BookIt Will Be a Long fourney, so Start NowThe Economic ViewThe Nature of Our EconomicsThe Project Economic FrameworkThe Nature of Our DecisionsOur Control StrategySome Basic Economic ConceptsDebunking Some Popular FallaciesConclusionManaging QueuesQueueing TheoryWhy Queues MatterThe Behavior of QueuesThe Economics of QueuesManaging QueuesRound Up the Usual SuspectsConclusionExploiting VariabilityThe Economics of Product Development VariabilityReducing VariabilityReducing Economic ConsequencesConclusionIJ152l2425272830344045495253535558687l8082858695r021082.3.vtl 5. vill CONTENTS5. Reducing Batch SizeThe Case for Batch Size ReductionSoftware Testing ExampleThe Science of Batch SizeManaging Batch SizeRound Up the Usual SuspectsConclusion6. Applying WIP ConstraintsThe Economic Logic of WIP ControlReacting to Emergent QueuesExamples of WIP ConstraintsWIP Constraints in PracticeConclusionControlling Flow Under UncertaintyCongestionCadenceCadence in ActionSynchronizationSequencing WorkManaging the Development NetworkCorrecting Two MisconceptionsConclusionUsing Fast FeedbackThe Economic View of ControlThe Benefits ofFast FeedbackControl System DesignThe Human Side of FeedbackMetrics for Flow-Based DevelopmentConclusionAchieving Decentralized ControlHow Warfare WorksBalancing Centralization and Decentralizationlll111t20t20t28135t4r143t44150158158r66r69t70t761811861911982062092tl2t3220222230234240243244246n8.9. 6. CONTENTS ixMilitary Lessons on Maintaining AlignmentThe Technology of DecentralizationThe Human Side of DecentralizationConclusionSelected BibliographyThe Principles of FlowIndexGoingFurtherAbout the Author25126026326526727r277293294 7. The Principles of FlowIt ain't what you don't know that gets you into trouble.It what you know for sure that just ain't so.-MarkTwainWhywrite this book? After about 30 years of advising product develop-mentorganizations, I ve been lucky enough to work with many smartand experienced developers. I've had a chance to see what they do, andwhat outcomes they get. At the same time, I've been exposed to all thestandard advice about how product development should be managed.Curiously, what actuallyworks is surprisingly different from the standardadvice. Why?I believe that the dominant paradigm for managing product devel-opmentis fundamentally wrong. Not just a little wrong, but wrong toits very core. It is as wrong as we were in manufacturing, before the|apanese unlocked the secret of lean manufacturing. I believe that anew paradigm is emerging, one that challenges the current orthodoxyof product development. I want to help accelerate the adoption of thisnew approach. I believe I can do this by helping people understand it.That is the purpose of this book.The approach I will describe has always been present in someform in development processes. After all, product developers repeatbehaviors that work, even if, in theory, they are not supposed to work.But discovering and repeating successful behaviors is not enough tocreate large-scale use. Product developers need to extract the underly-ingmechanisms of action that make these methods work. It is only bygeneralizing these principles that we can expand their application froma handful of isolated successes into a general approach that transformsthe entire development process.Lett begin with an illustration. Officially, many product develop-ershave phase-gate processes. Work is divided into mutually exclusive 8. THE PRINCIPLES OF FLOWphases separated by gates. One phase must be complete before the nextone can begin. For example, such processes typically require that allproduct requirements be defined before beginning design activities. Theteam appears to do this, and delivers complete product requirements tomanagement at the gate review. Then, theyare given approval to exit therequirement definition phase and to begin the product design phase. Onits surface, this procedure appears quite sensible, and it seems to work.What really happens is quite different. When I survey managersin my product development courses, 95 percent will admit that theybegin design before they know all requirements. In fact, the averageproduct developer begins design when 50 percent of requirements areknown. They simply do not publicize this to management. Instead, theyengage in a time-honored ritual of asking for permission to proceed.There is a tacit'dont ask, dont tell" policy. Managers politely avoidasking if the next phase's activities have already begun, and developersdiscreetly avoid mentioning that they have already moved on. In prac-tice,sensible behavior prevails, despite the presence ofa dysfunctionalformal procedure.The underground overlap of design and specification activities isjust one simple example of this alternative paradigm in action. Amongother things, this paradigm emphasizes small batch transfers, rapidfeedback, and limited work-in-process inventory (WIP). These threespecific methods are actually broadly applicable throughout the devel-opmentprocess. When we recognize why they work, we can adapt themto dozens of situations.At its heart, this new paradigm emphasizes achieving flow. It bearsmany similarities to the methods of lean manufacturing and could belabeled lean product development (LPD). However, the methods of leanmanufacturing have been optimized for a domain with very differentcharacteristics than product development.For example, manufacturing deals with predictable and repetitivetasks, homogeneous delay costs, and homogeneous task durations. Asa result, manufacturing sequences work in a simple first-in-first-out(FIFO) order. FIFO prioritization is almost never economically opti-malin product development, because product development dealswith high variability, nonrepetitive, nonhomogeneous flows. Differ-entprojects almost always have different delay costs, and they presentdifferent loads on our resources. 9. Whot ls the Problem?As you shall see, these new challenges force us to go far beyond theideas of lean manufacturing. If we are open to advanced ideas fromother domains, we can do this. To distinguish this more advancedapproach from the ideas of lean manufacturing, we call it Flow-BasedProduct Development.What Isthe Problem?Today's orthodoxy has institutionalized a set of internally consistentbut dysfunctional beliefs. This has created a tightly interlocking andself-reinforcing system, a system from which it is very difficult to breakfree. Even when we change one piece, the other pieces hold us back byblocking the benefits of our change. When our change fails to producebenefits, we revert to our old approaches.Let's look at how our current beliefs reinforce each other. Forexample, if we combine the belief that efficiency is good, with a blind-nessto queues, we will load our development process to high levels ofcapacity utilization. After all, underutilized capacity appears to be waste.High capacity utilization may cause queues, but these queues have noapparent cost. Thus, these two beliefs combine to drive us to disastrouslevels of capacity utilization. This, in turn, leads to large queues andlong cycle times.Let's take another example. If we combine the belief that variabilityis bad with the failure to correctly quantify economics, we will mini-mizevariability by sacrificing other unquantified economic goals. Wewill create risk-averse development processes that strive to "do it rightthe first timel'We will blindly embrace concepts like Six Sigma productdevelopment.This risk aversion will drive innovation out of our developmentprocess. Eventually, we will wonder why our products have no differ-entiationand low profitability. Thus, our current belief system incor-rectlycauses us to choose variability reduction over profitability. Yet, itdeludes us into thinking that we are increasing profits.In this chapter, I want to challenge some of the core beliefs of thecurrent orthodoxy and to highllght what is wrong with them. Of course,this is only a brief introduction to these controversial ideas. The ortho-doxbeliefs are quite well-defended, so we will need to assault themwith heavier weapons later in this book. For now I will just fire a few 10. THE PRINCIPLES OF FLOWProblems with the Current Orthodoxy1. Failure to Correctly Quantify Economics2. Blindness to Queues3. Worship of Efficiency4. Hostility to Variability5. Worship of Conformance6. Institutionalization of Large Batch Sizes7. Underutilization of Cadence8. Managing Timelines instead of Queues9. Absence of WIP Constraints10.Inflexibility11. Noneconomic Flow Control1 2. Centralized ControlFigure 1-1 Twelve critical problems with the current productdevelopment orthodoxy.tracer rounds so you can see where t


View more >