And Im sure there are many more that I left out. Of course, this then makes the package even larger and of higher priority. There got to be so many pages marked that I started putting the stickies on the side of the page so I could tell the new ones from the old ones. Each principle gets a page or two of explanations; the diagrams are plentiful and helpful. There is also a very interesting section of this chapter that discusses how to sequence work. Reinertsen argues that queues are the most important factor in maintaining optimal product development flow.

The Principles of Product Development Flow: Second Generation Lean Product Development, Developing Products in Half the Time: New Rules, New Tools, 2nd Edition, Copyright 2020, Reinertsen & Associates, Covid-19 Testing Scarcity: A Self-Inflicted Wound, Sample Pooling: An Opportunity for a 40x Improvement in Covid-19 Testing, Technical Debt: Adding Math to the Metaphor, The Four Impostors: Success, Failure, Knowledge Creation, and Learning, Sample Pooling: An Opportunity for a 40x Improvement in Covid-19 Testing | Blog.CarlRobitaille.org. When they tested improvements in keel designs, they used two virtually identical boats. As with any methodology, applying the principles faithfully may require modifying the practices to fit a specific context. 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. Here are a couple examples: B2: The Batch Size Queueing Principle: Reducing batch size reduces cycle time; F8: The Cadence Batch Size Enabling Principle: Use a regular cadence to enable small batch sizes. Clearly, big iterations require big queues. 0000003091 00000 n It will be particularly useful to companies that are reaching the point of diminishing returns using conventional approaches to product development and lean product development. This set of principles dispels this misconception. The following chart shows compelling evidence of the efficacy of WIP constraints. I push this technique quite often, because traditional product development tends to work in batches that are much too large. But, what is the cost of this buffer? Six Sigma and Lean thinking encourage us to stamp out variability. It would be difficult to outline the forty-six (or 175!) 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. Anyone familiar with Lean thinking understands the importance of queues. 6. Don Reinertsen points out that were in business to make a profit, so decisions made during the development process should be made by considering how theyll impact profit.

In the manufacturing world, variability is almost always bad. Although the book is under 300 pages long, it felt like many 500 page books I have read. It becomes a death march where all participants know they are doomed, but no one has the power to stop. 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. Two opposing forces create a U-Curve (depicted here as total cost), which gives us a range of good choices near the trough. Reducing batches can have many benefits in a software development environment. Find a way to get it into the requirements of the "golden" projec. In fact, the author argues that just getting close delivers almost all of the value of measurement with a fraction of the effort. Then, if we seek to minimize total cost, we will only focus on the portion we can see, the efficient use of capacity. Initial attempts to apply lean methods in product development simply copied behaviours that worked in manufacturing. In this chapter, Reinertsen uses traffic control systems because they must adapt to constantly changing and uncertain conditions accidents happen. If youre wondering how Playbook utilizes these good ideas, you can watch a demo and look for these key points. One of the challenges that R&D has that manufacturing doesnt is that most of the work is invisible, which makes it difficult to see the queues. Yet it's not correct to say that batch sizes should be as small as possible. The book is organized as 175 principles, organized into chapters by area. The opposite can also be true. Clearly, there comes a point at which additional features cost more than the benefit that is derived from them. 0000002588 00000 n One example offered is that of the bathroom scale purchased to measure weight-loss performance. And there are already stories of companies that have tried the wrong things and failed. In my own experience, companies that implement decentralized control often exhibit a mild form of schizophrenia. Institutionalization of large batch sizes. Hopefully by now youre convinced that some form of Lean or Agile product development process is worth pursuing. There are no easy answers to this conundrum, but adaptability to a changing situation is paramount. Myths are busted on practically every page, even myths that are associated with lean/agile. 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. An intensive two-day workshop on practical, economically justifiable approaches for improving flow in product development. Throughout this book, ideas are integrated from different chapters. 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. Reinertsen cautions against mistaking dynamic goals for static goals. 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. The unimproved boat would sail against the improved boat to determine the effect of a design change.

Product development queues are more insidious because they tend to be invisible. Finally, decentralization is a key principle for managing and optimizing complex systems. Reinertsen discusses ways in which to do this. Ramp meters control the volume of vehicles on the freeway and thereby increase flow without actually limiting access. 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. Often functionality that seems like it will require minimal design and development effort ends up being anything but. Reinertsen also provides a number of ways to visualize and monitor WIP to know when to deploy WIP control measures. A3s, Batch Sizes, Build Measure Learn, Cadence, Collocation, Constraints, Cost of Delay, Critical Chain Project Management, Decentralization, Early Learning, Fast Feedback, Flexible Product Development, Flow, Kanban, Knowledge Driven Product Development, LAMDA, Lean Six Sigma, Multitasking, OODA, PDCA, Project Economic Models, Queueing Principles, Rapid Learning Cycles, Risk Management, Scrum, Set-Based Concurrent Engineering, Standup Meetings, Value Stream Maps, Visual Project Boards, WIP Constraints. Just show it will benefit the "golden" project and you will get approval. Reinertsen does not speak about startups specifically - his book is meant to speak broadly to product development teams across industries and sectors. In a manufacturing environment, work in process (WIP) inventory build up is easy to see. With so many options to choose from, its no wonder theres confusion. And that's also where we need to modify some of the specific practices Reinertsen recommends. The principles of product development flow draw on insights from Lean Manufacturing as well as examples from the Telecommunications and Computer Operating Systems industries. This explains why today's product developers assume that efficiency is desirable, and that inefficiency is an undesirable form of waste. His latest awarding winning book, 'The Principles of Product Development Flow: Second Generation Lean Product Development', has been praised as, quite simply the most advanced product development book you can buy., Don ReinertsenPresident of Reinertsen & Associates, a consulting firm specialized in the management of product developmentendal, "Very good, but also quite theoretical. Under such conditions, management will almost automatically support anything that appears to help the "golden" project. And while its impossible for me to say whats best for your particular situation, I can share what we have found to be the most useful starting point. Let me preface this review by stating for the record that I read a lot of non-fiction books. As I was trawling the internet for some brain fodder on Lean,I came across a good book that tackles usual questions of batch handling in the lean space.This one is from Donald Reinertsen-he also has couple of you tube videos as well.Am reproducing an excerpt from Eric Ries. 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 designed the yacht that won the America's Cup. If variability has both positive and negative consequences, it stands to reason that we should only try to eliminate bad variability. Stay tuned for Part 6 where we look at other key Lean Product Development principles. Design goals are almost always dynamic.

Lean Product Development the Opportunity of the Century. Inquisitive, provocative and results oriented, David is willing to dig into problems until their true essence is understood and the solution is executed. Continuing the theme of ascribing economic value to costs of delay, the chapter on WIP discusses how said cost can be minimized by controlling WIP. If you have been doing agile for a while it is a good way to put your everyday praxis in perspective.". Technical Debt: Adding Math to the Metaphor - R SKMurphy, Inc. More later about the specific factors listed here. Hence the need for partitioning our resources into a separateproblem team and solution team. 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. By the time a book gets on my radar, it probably has some new information to offer. Creating short feedback loops is nothing new to the Agile practitioner. How high? However, different jobs will often have vastly different costs-of-delay. 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. As more is learned, we must be prepared to throw out our most fundamental beliefs about why we are doing the project and what we need to accomplish. Capacity utilization is revisited with an eye towards determining the correct margin to leave available to ensure higher flow rates. The R&D factory isnt creating a product, its creating knowledge, which comes from information that is understood. 221 0 obj << /Linearized 1 /O 225 /H [ 1106 1132 ] /L 1346405 /E 969463 /N 32 /T 1341866 >> endobj xref 221 11 0000000016 00000 n

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. Relying on extensive central command slows things down, puts decisions in the hands of those with the least knowledge of the situation on the ground, and risks miscommunication when orders are returned. This workshop covers the ideas contained in Don Reinertsens bestselling book, The Principles of Product Development Flow. But its also well written and Don Reinertsen speaks a little more strongly when he talks about how present day product development methods are backwards.

", The Principles of Product Development Flow: Second Generation Lean Product Development, To view or add a comment, sign in Today, only 15 percent of product developers know the cost of delay. trailer << /Size 232 /Info 214 0 R /Encrypt 223 0 R /Root 222 0 R /Prev 1341855 /ID[<1a5eb9fbc7621f479f718e415c5dd1e8>] >> startxref 0 %%EOF 222 0 obj << /MarkInfo << /Marked true >> /Metadata 213 0 R /PageLabels 210 0 R /Pages 212 0 R /StructTreeRoot null /Type /Catalog /ViewerPreferences << /Direction /L2R >> /AcroForm 224 0 R >> endobj 223 0 obj << /Filter /Standard /R 3 /O (2*c #h e5-J-3T\n) /U ([| ) /P -1340 /V 2 /Length 128 >> endobj 224 0 obj << /Fields [ ] /DR << /Font << /ZaDb 207 0 R /Helv 208 0 R >> /Encoding << /PDFDocEncoding 209 0 R >> >> /DA (v'm}wo) >> endobj 230 0 obj << /S 1030 /V 1343 /L 1365 /Filter /FlateDecode /Length 231 0 R >> stream These large projects act as magnets attracting additional cost, scope, and risk At the same time, large batches encourage even larger batches. 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. Its goal is to help us recognize that every artifact of our product development process is really just a proxy variable. In product development, batches contain one or more functional elements. Fast feedback allows us to remain vigilant for these opportunities. If anything, he left me wanting more stories that would further illustrate the mountain of golden nuggets he has provided. In product development, variability is not always bad. Reinertsen is keenly aware of what makes product development different from other business functions, like manufacturing, that we sometimes use as a metaphor. Reinertsen, in typical fashion, offers lots of ways to evaluate the characteristics of managing decentralized control by integrating ideas from all the preceding chapters. One of the hallmarks of this book is the use of some unexpected sources for models of behavior. Even worse, and unlike their established counterparts, startups often experience a non-quantifiable cost of delay. There are dozens, if not hundreds, of options for starting points. Instead, we will explore some of the more advanced ideas used in the world of telecommunications. All things being equal, it is best to do the smallest jobs first in order to reduce the cost of delay. %PDF-1.4 % 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. By sailing one boat against the other, they were able to discriminate small changes in performance very quickly. Each section has numbered principles, and there are 175 in all. Small batches (or short iterations) provide fast feedback (more on this later), but they also have the effect of reducing queue size. Again, you will find some powerful tools to think about how to optimize the use of human and system resources. This doesnt work development is a profoundly different domain. But it can be managed with WIP constraints. Some of these things happen on a schedule that can be anticipated and others cannot. 8. The chart above shows how different control variables have different economic impacts and should therefore have different tolerances for variation (i.e. A number of tactics for controlling WIP are put forth. As great as these ideas are, we borrowed a few other methods from other sourcesAgile, and Theory of Constraints. 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. That is often a bad trade (although, as I'm sure Reinertsen would hasten to add, not always!). In addition to evaluating the work, a good nonfiction book review also provides a taste of some of the information the reader will gain. For most companies, the biggest impact to profit is the cost of delay. This is not to say that we should spend extensive effort on computing economic value to the last dime. So if its a good book, Ill actually finish it. This snippet is characteristic of Reinertsen's writing style and reasoning. To view or add a comment, sign in. That depends on your experience with Lean Product Developmentand your reading and learning style. The reason for this can be represented in the graph below: Here we see two opposing metrics: transaction cost and holding cost. To motivate you to buy this book, I want to walk you through some of Reinertsen's indictment of the status quo in product development, which is based on his extensive interviews, surveys, and consulting work. And somewhere along the way I loaned it to Paul and Eric so I dont really know how many times we read it altogether. Reinertsen uses a series of mathematical formulas to illustrate how high levels of capacity utilization on an ongoing basis increases queue size and derails product development efforts. A day delay has almost no cost, as far as profitability is concerned. What we learn from this example is that flow is a product of speed and density. But, more importantly, it is easy to quantify. Second, what is the cost of these queues?

Executives coming to my product development classes report operating at 98.5 percent utilization in the precourse surveys. Fast feedback provides a reinforcing cycle that keeps our inventory of design variations low. Today's developers incorrectly try to maximize efficiency Any subprocess within product development can be viewed in economic terms. [This book] will explain why large queues form when processes with variability are operated at high levels of capacity utilization. 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. Reinertsen's book shares 175 principles of product development that challenge all conventional wisdom of how software products are built. The book is structured as a series of principles, logically laid out and briefly discussed - 175 in all. This ultimately enabled them to triumph over a much better funded American team. The goal is to increase profitability by making high-ROI investments in new products. But it was so many that the corners are worn out like a classic college text book. Speaking of text books As full as this book is with good ideas, there is another that actually beats it in terms of density. Let's take a look at each of the eight categories in brief. )", "Go! This can be particularly true with software development projects because we often establish goals for the project in the early stages and become locked into our believe that deviations from those goals are categorically bad. Reinertsen explains how to calculate the optimal batch size from an economic point of view, math and all. As the name implies, the book is broken down into a series of principles that have been categorized into eight major groups with several sub-classifications for each. It is what they refer to as the ramp meter..

See if any of these sound familiar: 1. He also introduces this idea: when it is imprudent to eliminate variability, the better choice is to minimize its cost. However, Managing the Design Factory (MDF), by Don Reinertsen, has forty-six notes in it! Despite the fact that much of the content has been covered by other texts on Lean and Agile development, Reinertsen brings a rigor to these practices that is often missing from other offerings. How to manage this? By focusing on real economic value, we learn to manage the elements of a project that matter most. Anyone working in an Agile software development environment is familiar with the benefits of small batch size. 0000002238 00000 n What will this do? (That would have been a lot of sticky notes!). Even though Lean and Agile are fairly new topics in terms of hardware product development methods, there are already dozens of books on the subject. To answer this second question, we must determine how queue size translates into delay cost, which requires knowing the cost of delay. It is a central principle and the entire philosophy tends to revolve around arranging work to get fast feedback. He reduces uncertainty in the schedule by committing to an 80 percent confidence schedule. Most of the really good books get just a few pages marked. Reinertsen weaves together ideas from lean manufacturing, maneuver warfare, queuing theory, and even the architecture of computer operating systems and the Internet. To give one example, Reinertsen emphasizes the power of measuring thecost of delay(COD) of a new product. Instead, there are a bunch of stories on what individual companies have doneand those stories vary a lot. As we already know, congestion for product developers means bigger queues, higher capacity utilization, delays and higher costs. Ideas such as cadence, forecasting and synchronization are discussed. Unfortunately, many people assume that the principles that apply to the repetitive cadence of manufacturing have no place in the less predictable world of product development. (For an introduction to the topic, I still recommend Reinertsens book. That is what we started with on the Internet 30 years ago. The total cost of the subprocess is composed of its cost of capacity and the delay cost associated with its cycle time. Well, heres a partial list of topics you can choose from. Does this sound familiar? They are not. ), and the resulting extreme uncertainty that is, incidentally, the environment where startups thrive. People often ask which they should read first. People who work together develop tight communications based on common context and language. CEO

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.

Sitemap 28