The simple diagram below illustrates this perfectly. If you'd like to hear when articles come out, Lean product development can be looked at as flow-based product development. What we learn from this example is that flow is a product of speed and density. This has the effect of equalizing economic deviations. It is worth noting that Team New Zealand explicitly invested in a second boat to create this superior test environment.
If variability has both positive and negative consequences, it stands to reason that we should only try to eliminate bad variability. They can also assess when it is appropriate to engage leadership. As is the case throughout the book, concepts introduced elsewhere are interwoven. It relies on understanding mechanisms of action and quantifying trade-offs.
Just the way physics applies to both large objects and small ones, the methods used in this course can be applied in a wide variety of industries.
I came looking for a few nuggets and found an entire gold mine. Flow is more like an encyclopedia where you can easily find information.
The R&D factory isnt creating a product, its creating knowledge, which comes from information that is understood. This means that there are no external factors that argue for shipping product on any given day.
Today, only 15 percent of product developers know the cost of delay.
Let's take a look at each of the eight categories in brief. In my own experience, companies that implement decentralized control often exhibit a mild form of schizophrenia.
Again, you will find some powerful tools to think about how to optimize the use of human and system resources. I push this technique quite often, because traditional product development tends to work in batches that are much too large. Lowering capacity utilization (and thereby queues) and reducing batch size (iteration cycle time) have such an effect. Any activity that promotes learning is progress, and productivity needs to be measured with respect to that.
(For an introduction to the topic, I still recommend Reinertsens book Managing the Design Factory.). All things being equal, it is best to do the smallest jobs first in order to reduce the cost of delay. And yet it is this same ephemeral nature that gives rise to the most difficult problems of product development: how to tell if we're making progress, the high variability of most product development tasks (e.g. Failure to correctly quantify economics. Good for economically minded people (CFO, CEO, etc. Achieving Product Development Flow takes a different, science-based, approach. 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. 0000002588 00000 n Reinertsen is not pulling punches. 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. Here we see two different projects in which the same variables have different economic impacts. 0000001106 00000 n Myths are busted on practically every page, even myths that are associated with lean/agile. Given what I have already said, you can imagine that my attempt will be wholly inadequate, but at least I can try to pique your curiosity. They are not. Ill give you time to start reading either of Don Reinertsens books and will cover these other two topics in my next post.
Stay tuned for Part 6 where we look at other key Lean Product Development principles. One of the great additions to the lexicon of product development comes from the notion of quantifying factors that those of us in product development often treat as soft measurements. This can be done by creating an economic model that everyone on the team understands and buys into. Unfortunately, this is often limited to what I refer to as a few golden nuggets. Even good books have lots of fluff in between the nuggets, usually in the form of extended stories to illustrate the point.
Fast feedback allows us to remain vigilant for these opportunities. Reinertsen cautions against mistaking dynamic goals for static goals.
Product development deals in designs, which are fundamentally intangible. The techniques covered are general methods of analysis rather than industry specific rules. Closely related is the fact that high capacity loading has a serious impact on cycle times. Speaking of text books As full as this book is with good ideas, there is another that actually beats it in terms of density. And queues are leading indicators of system slowdowns so its important that we monitor them.
Small batches (or short iterations) provide fast feedback (more on this later), but they also have the effect of reducing queue size. Technical Debt: Adding Math to the Metaphor - R SKMurphy, Inc.
Some of these things happen on a schedule that can be anticipated and others cannot. We often think of product development backlogs as free. This is why product development routinely creates disruptive innovation, because our ability to invent new products is limited only (well, primarily) by our capacity for imagination. Achieving Product Development Flow - Learn how to manage and orchestrate development projects following advanced Lean principles, Value Stream Identification Lessons from the wild, The Principles of Product Development Flow, Calculate and use Cost of Delay as the most important key figure in your development process, Find, monitor and control bottlenecks in the process, Shortening lead-time through systematically reducing batch sizes, Create room for innovation, by allowing variation in the process. It is fundamentally different from other workshops in its intense focus on quantification, economic justification, and the use of a science-based approach for applying lean. 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. It is preferred that participants have a basic understanding of lean techniques and at least 5 years of experience in product development. 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.
0000000955 00000 n The book is organized as 175 principles, organized into chapters by area. My favorite part of this chapter was the discussion around alignment. It's refreshing to see ideas from these different domains brought together in a coherent way: If we limit ourselves to the relatively simple WIP [work-in-progress] constraints used in lean manufacturing, we will underexploit the power of WIP constraints. Because we are constantly correcting our course, refactoring prior efforts that turn out to be bad deviations are kept small enough to be much less costly than the deviations that come from longer feedback cycles. Almost all economic factors can be traced back to managing delay. Throughout the book, this is a recurring theme. In the previous two blogs I made a compelling case for Lean Product Development being the business opportunity of the century, and then gave an example of how and why we focused on the wrong end of the value chain. I have become a skeptic of concepts and practices that are not measurable and Reinertsen dives right in with this chapter about ascribing economic value to the work we do as product developers. No self-respecting Lean approach to product development would be complete without discussing batch size.
It is only through this type of thinking that we can exploit positive deviations. There are many causes, but a common one is that work sits idle for long periods of time (in a queue) before its worked on. In the manufacturing world, variability is almost always bad. With the importance of speed in mind, we need to understand what slows down projects. This ultimately enabled them to triumph over a much better funded American team. Ramp meters control the volume of vehicles on the freeway and thereby increase flow without actually limiting access.
When leadership defines the mission clearly, teams can interpret their situation against that mission to make good choices. If its a really good book it will have ideas in it that Ill want to find later, so Ill mark those pages with a piece of sticky note. Much of this chapter is a rehash of concepts that are familiar to anyone who has used Agile or Lean principles: colocation, short iterations, low hanging fruit, and modular design are all discussed. 0000002215 00000 n Or consider principle B9: The Batch Size Death Spiral Principle: 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.
When either goes up significantly, congestion quickly ensues. For me, this chapter packed the largest wallop. These large projects act as magnets attracting additional cost, scope, and risk At the same time, large batches encourage even larger batches. CEO will this bug take 5 minutes or 5 weeks to fix? Each principle gets a page or two of explanations; the diagrams are plentiful and helpful. In addition to evaluating the work, a good nonfiction book review also provides a taste of some of the information the reader will gain. Thank you for being such wonderful hosts absolutely fantastic environment (+ delicious food) to support the learnings.- Sending my husband to the course asap! There is a lot of great material here and the usual mathematical treatment of the topic, which will help the practitioner with better tools to evaluate how work can be optimally sequenced.
Instead, there are a bunch of stories on what individual companies have doneand those stories vary a lot. Leadership feels obligated to assert their authority, while at the same time sending messages that people at all levels should feel free to make appropriate decisions. By sailing one boat against the other, they were able to discriminate small changes in performance very quickly. This explains why today's product developers assume that efficiency is desirable, and that inefficiency is an undesirable form of waste. To give one example, Reinertsen emphasizes the power of measuring thecost of delay(COD) of a new product. 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. Weve created a space, which is designed to meet the high expectations from our driven, creative trainers and consultants, and for you to feel comfortable, almost like home. Team New Zealand completed many more cycles of learning, and they generated more information in each cycle. Here again, we see the use of a more quantitative approach to evaluating this feedback and defining the right metrics to target economic indicators of performance.