- Gebundene Ausgabe: 304 Seiten
- Verlag: Celeritas Publishing; Auflage: 1 (29. Mai 2009)
- Sprache: Englisch
- ISBN-10: 1935401009
- ISBN-13: 978-1935401001
- Größe und/oder Gewicht: 3,2 x 15,9 x 22,9 cm
- Durchschnittliche Kundenbewertung: 4 Kundenrezensionen
- Amazon Bestseller-Rang: Nr. 5.487 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
The Principles of Product Development Flow: Second Generation Lean Product Development (Englisch) Gebundene Ausgabe – 29. Mai 2009
|Neu ab||Gebraucht ab|
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Wenn Sie dieses Produkt verkaufen, möchten Sie über Seller Support Updates vorschlagen?
The Principles of Product Development Flow The dominant paradigm for managing product development is wrong; not just a little wrong, but wrong to its very core. Stagnant piles of idle work lengthen cycle time, delay vital feedback and destroy process efficiency. Yet today, these queues remain unmanaged. This landmark book defines a new approach, one based on solid economics and real science. It focuses on controlling the invisible and unme... Full description
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Summary of the book
Don Reinertsen describes in his book 174 principles how to develop an improved, more profitable development flow.
He uses ideas from lean manufactoring, economics, queueing theory, statistics, the internet, computer operating system sesign, control engineering and maneuver warfare and adapts them to product development.
The author states that todays problems in product development are caused by failure to correctly quantify economics, blindness to queues, worship of efficiency,hostility to variability, worship of conformance, institutionalization of large batch sizes, underutilization of cadence, managing timelines instead of queues, absence of WIP constraints, inflexibility, noneconomic flow control, and centralized control.
He emphasizes that it is important to treat development decisions as economic decisions. This is in his opinion much better than chasing whichever proxy variable is popular at the moment.
Developing an economic framework and decisions rules help to quickly process the small, perishable economic decisions. The economic models and rules do not have to be perfect, because even imperfect rules improve decision making.
A decision rule that is missing in most companies today is a quantified cost of delay.
Reducing Queues is the key to improve product development performance. The hidden cost of queues are often overseen. They are the hidden source for most development waste, because they increase cycle time, expenses, variability and risk and they slow feedback, reduce quality, and decrease motivation.
Queues are linearly increased by variability and exponentially by high capacity utilization.
The structure of the queueing system affects the queues, e.g. sharing a queue for multiple servers. The Optimum queue size occurs when we balance the cost of capacity agains delay cost. The cost of queues can be reduced by a queuing discipline.
The commulated flow diagram (CFD) and Little's formula are tools to visualize and analyze queues and to relate queue size to cycle time.
Variability is, in contrast to manufactoring, not always bad in product development, because here the economic payoff-functions are frequently asymmetric.
It is important to focus on the cost of variability instead of worrying about the amount of variability.
On the other side variability can be reduced using variability pooling, creating covariance, exploiting reuse and especially by reducing batch size.
Small batch sizes are desirable to product developers, because they reduce queues, accelerate feedback and reduce risk. Decreasing transaction costs, and thus allowing smaller batch size, has an enormous economic value. "Although batch size is a mature concept in manufactoring for almost a century, today, most product developers do not even recognize batch size as an issue."
Work in Process (WIP) constraints can be used to control cycle time, since they influence queue size which determines cycle time. They are powerful because they are inexpensive, incremental and reversible. They prevent queues from reaching dangerously expensive levels of congestion. "Unfortunately, today less than 1% of product development processes are managed with WIP constraints."
Cadence and synchronization are known from lean manufacturing. Time based cadences have big advantages. Synchronization can reduce queues without changing either batch-size and capacity utilization.
By borrowing concepts form computer Operating system design, we can develop network based development processes, that use flexible sequencing, tailored routes, alternate routes, late binding and some other methods and do much better fit the needs in PD than the linear processes used today.
The goal in managing the PD process is to increase the economic outcome. We can design control systems that must deal with multiple objectives and moving targets to achieve this goal.
The concepts of leading indicators and balanced set points helps to improve the process. Product development presents us with unplanned economic opportunities that we should exploit.
Fast feedback reduces queues and accelerates learning. It can be achieved using small batches and control systems that handle small batches of information.
Accelerated feedback loops improves efficiency and gerate urgency. Slow feedback undermines urgency in PD.
It is important to have additional fast local feedback loops. They work best when de decentralize control.
There are some metrics that support flow based product development, e.g. measuring design-in-process inventory, cost of queues, aging of items in queue, batch size trends, feedback speed, decision cycle time, number of multipurpose resources, etc.
Robust systems combine centralized and decentralized control e.g using layered control and virtual centralization.
Centralized control works well for problems that are infrequent, large, or those with scale economies.
Decentralized control permits us to adapt to uncertainty. It works well for problems and opportunities that are perishable.
Decentralized control requires a set of technical skills that can be trained and practiced. It can be supported by a set of management choices that enable lateral communications and the creation of cohesive teams. Decentralized control is important and decisions rules and mission statements are necesary for it.
Ein paar Erkenntnisse aus dem Buch zum Anfüttern:
(1) Entwicklungsergebnisse sollen Profit bringen. Alle Aktivitäten sollten darauf ausgerichtet sein und sich daran messen. Stellgrößen sind insbesondere Entwicklungskosten, Herstellkosten, Produkt-Features, Time-to-Market und Risko/Versicherungen. Nicht die Optimierung einer Stellgröße bringt den Erfolg, sonders das aktive stetige Einstellen des richtigen Arbeitspunktes für alle Stellgrößen zusammen.
(2) Entscheidungskurven für a oder b ergeben U-Kurven, die in der Regel ein breites Minimum haben. Das bedeutet, solange die Entscheidung nicht auf dem Rand der U-Kurve liegt, liegt man nicht weit vom Optimum weg. Die Entscheidung kann also mit einer beruhigenden Ungenauigkeit getroffen werden.
(3) Mehr Auslastung von Entwicklern führt bei Änderungen und Taskwechsel zu relativ mehr Overhead. Die effiziente Ausnutzung von Entwicklern liegt eher in der Größenordnung von (z.B.) 65-75% als bei 90-100%. Das genaue Optimum muss im eigenen Unternehmen gefunden werden.
Die hilfreichsten Kundenrezensionen auf Amazon.com
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.
Reinertsen clears this away and looks at the product development cycle from holistic perspective. When you approach the problem from a Total Lifecycle Profits perspective some forms of apparent 'waste' are really not. Implementing two options in parallel knowing you will throwing one away may very well be less wasteful then implementing just your preferred option - only to discover too late that it won't work.
His focus on queues and queuing theory is critically important. All processes and business have queues but too often we don't think of them that way. It's just the pile of work we need to get done - which is completely different from a queue right? Looking for hidden queues and treating them properly is the key to improving many processes.
I particularly enjoyed his discussion of efficient 'resource utilization'. A road network that is 100% utilized is gridlocked. A computer server with a pinned CPU and full memory is clogged and overloaded. A FedEx truck packed with every cubic inch of space is impossible to unload efficiently. Why then do managers assume that an employee with 'only' 90% of their 'capacity' spoken for is in desperate need of another project? Reinertsen cuts through this nonsense.
This is a new form of Scientific Management. Most previous attempts have treated people like clockwork parts in a machine. Differences were seen as a problem to be eliminated. If everything and everyone were the same then Efficiency would be achieved! All re-work was seen as inherently bad and a sign of a flawed process. Instead, by focusing on flow Reinertsen shows that in many cases variability is the key to adding value. With small batch sizes, parallel queues and fast feedback re-work can actually result in much better products and higher profits.
This book doesn't not provide a capital P Process that a business can implement as a magic wand. Instead it provides a set of tools and a way of thinking that can guide each organization to discover how to achieve flow in their own domain.
I highly recommend this book to executives, managers, product developers and "in the weed" workers. It's applicable across a wide variety of industries. While the details of developing new furniture or the next great cloud application are going to be very different the principles and tools are the same.
There were some helpful, concrete insights, but more important, this book will help you develop a mental framework for analyzing product development process. This understanding will set you free from the Agile vs. Waterfall cargo-cultism that permeates the tech industry.
Ähnliche Artikel finden