%PDF-1.4 % The discussion of creating clear roles and boundaries resonates because too often neither of these is well-defined and clearly communicated in a manner that is actionable by team members at all levels. If we can apply economic principles to the value of features, we can quantify the benefit of continued development and properly assess whether additional features make economic sense. BestBrains Academy er lokaliseret i Kbenhavn og udbyder bdeagile bne IT-kurser, svel som inhouse kurser og skrddersyede workshops til din organisation. Speaking of text books As full as this book is with good ideas, there is another that actually beats it in terms of density. Set Points). They are not. Inquisitive, provocative and results oriented, David is willing to dig into problems until their true essence is understood and the solution is executed. He identifies a dozen fatal flaws that plague existing product development, beginning with a failure to properly identify and quantify the economics of development cycles, and outlines how to address these issues. 0000002215 00000 n Six Sigma and Lean thinking encourage us to stamp out variability. Then, if we seek to minimize total cost, we will only focus on the portion we can see, the efficient use of capacity. And that's also where we need to modify some of the specific practices Reinertsen recommends. [This book] will explain why large queues form when processes with variability are operated at high levels of capacity utilization. The book is structured as a series of principles, logically laid out and briefly discussed - 175 in all. More later about the specific factors listed here. Myths are busted on practically every page, even myths that are associated with lean/agile. As we already know, congestion for product developers means bigger queues, higher capacity utilization, delays and higher costs. Product development in established companies and markets has a clear economic rationale to judge effectiveness and productivity. 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.
This is not to say that we should spend extensive effort on computing economic value to the last dime. How high? 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. Product development deals in designs, which are fundamentally intangible. Many who have had this experience will report the ultimate avoidance of the dreaded device.
Instead, we will explore some of the more advanced ideas used in the world of telecommunications. Reinertsen cautions against mistaking dynamic goals for static goals. ", The Principles of Product Development Flow: Second Generation Lean Product Development, To view or add a comment, sign in One of the hallmarks of this book is the use of some unexpected sources for models of behavior. He reduces uncertainty in the schedule by committing to an 80 percent confidence schedule. Reinertsen is not pulling punches. 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. We want to take Agile training to the next level and believe that effective learning should be just as fun, interactive and inspiring as serious business and hard work. 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. For me, this chapter packed the largest wallop. Fast feedback allows us to remain vigilant for these opportunities. One example offered is that of the bathroom scale purchased to measure weight-loss performance. He points out that in the military, field personnel are given a mission, but since conditions on the ground can change rapidly, advantage goes to the fighting force that can adapt the quickest. 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. 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. Good for economically minded people (CFO, CEO, etc. ]bdRL&Py. Here we see two different projects in which the same variables have different economic impacts. 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. Reinertsen explains how to calculate the optimal batch size from an economic point of view, math and all. After all, they want to do everything in their power to eliminate all excuses for failure. It uses economics, statistics, queuing theory, and concepts from telecommunication network design. Have you had trouble buying a new piece of test equipment? Any activity that promotes learning is progress, and productivity needs to be measured with respect to that. 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. Each principle gets a page or two of explanations; the diagrams are plentiful and helpful. However, Managing the Design Factory (MDF), by Don Reinertsen, has forty-six notes in it! Achieving Product Development Flow takes a different, science-based, approach. 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. 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 If we are blind to queues, we won't know the delay cost, and we will only be aware of the cost of capacity. He points out that we often use surrogate (or proxy) measurements that offer little or no economic connection with the marketplace. Technical Debt: Adding Math to the Metaphor - R SKMurphy, Inc. The unimproved boat would sail against the improved boat to determine the effect of a design change. Its goal is to help us recognize that every artifact of our product development process is really just a proxy variable. But it can be managed with WIP constraints. 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. Many of the startups I talk to - and their boards - seem to equate ability to "hit the schedule" with competence and productivity. 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. Sound familiar? 6. That depends on your experience with Lean Product Developmentand your reading and learning style. The total cost of the subprocess is composed of its cost of capacity and the delay cost associated with its cycle time. 0000002238 00000 n That is what we started with on the Internet 30 years ago. w0a{\1;; eGmycl_[6Tq,k_ S}l{^2J-$0'J09isH#FC6D*vO*O-)x2{j e2j6*wmzE. Stay tuned for Part 6 where we look at other key Lean Product Development principles. 0000000955 00000 n While none of these ideas are new, it is valuable to read about them in the context of maximizing economic value. Reinertsen discusses ways in which to do this. 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. Startups are frequently guilty as charged - the 4-year death march example above could be written about dozens of venture-backed companies slogging it out in the land of the living dead. 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. 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. He starts the book with twelve cardinal sins. 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. 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. For example, many startups would do better by removing buffers from their schedules, embracing the variability of their delivery times, and reducing their cycle times. 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. Learn how to manage and orchestrate development projects following advanced Lean principles. This doesnt work development is a profoundly different domain. Almost all economic factors can be traced back to managing delay. When one principle calls for integration with another, we get a clear picture of how all these principles fit together to form a coherent strategy for building effective product development organizations. This set of principles dispels this misconception. Two things jumped off the pages of this chapter: The Cost of Delay is a premonition of the next category of principles. Thank you for being such wonderful hosts absolutely fantastic environment (+ delicious food) to support the learnings.- Sending my husband to the course asap! The techniques covered are general methods of analysis rather than industry specific rules. Although the book is under 300 pages long, it felt like many 500 page books I have read. 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. We are now four generations beyond that method." 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. An intensive two-day workshop on practical, economically justifiable approaches for improving flow in product development. Reducing batches can have many benefits in a software development environment. The book is organized as 175 principles, organized into chapters by area. Weather happens. People often ask which they should read first. I mention this because Reinertsen is an author who has stood the typical model on its head. The simple diagram below illustrates this perfectly. 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. But, what is the cost of this buffer? (That would have been a lot of sticky notes!). Fortunately, he broke it into sections representing eight key principles of Lean. In product development, batches contain one or more functional elements. Ramp meters control the volume of vehicles on the freeway and thereby increase flow without actually limiting access. Reinertsen does not speak about startups specifically - his book is meant to speak broadly to product development teams across industries and sectors. Two opposing forces create a U-Curve (depicted here as total cost), which gives us a range of good choices near the trough. If variability has both positive and negative consequences, it stands to reason that we should only try to eliminate bad variability. 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. In contrast, the competing American design team used a single boat supplemented by computer models and NASA wind tunnels. (For an introduction to the topic, I still recommend Reinertsens book. 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. Ill give you time to start reading either of Don Reinertsens books and will cover these other two topics in my next post. When they tested improvements in keel designs, they used two virtually identical boats. Even in an organization in which product developers are building tools for internal consumption, there are clear economic drivers that can guide us in good decisionmaking. A day delay has almost no cost, as far as profitability is concerned. This workshop covers the ideas contained in Don Reinertsens bestselling book, The Principles of Product Development Flow. However, different jobs will often have vastly different costs-of-delay. All things being equal, it is best to do the smallest jobs first in order to reduce the cost of delay. Quotes For Entrepreneurs-September 2014 - SKMurphy, Inc. How to get enough information about the detail | Ashridge on Operating Models. If youre wondering how Playbook utilizes these good ideas, you can watch a demo and look for these key points. Approximating this point nets you optimal economic advantage without extreme accuracy. Team New Zealand completed many more cycles of learning, and they generated more information in each cycle. My favorite part of this chapter was the discussion around alignment. By focusing on real economic value, we learn to manage the elements of a project that matter most. 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. Each principle gets a page or two of explanations; the diagrams are plentiful and helpful. 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. No self-respecting Lean approach to product development would be complete without discussing batch size. Reinertsen draws on a variety of areas (economics, queue theory, control theory, the military) to explore the consequences for product development. If you'd like to hear when articles come out, Lean product development can be looked at as flow-based product development. Closely related is the fact that high capacity loading has a serious impact on cycle times. In product development, variability is not always bad. Anyone working in an Agile software development environment is familiar with the benefits of small batch size. He is the author/co-author of three best-selling books on product development. 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. In this chapter, Reinertsen uses traffic control systems because they must adapt to constantly changing and uncertain conditions accidents happen. 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. What will this do?
The chapter concludes with a discussion of resource management. I mention this to encourage you to look beyond the manufacturing domain for approaches to control flow. The reason for this can be represented in the graph below: Here we see two opposing metrics: transaction cost and holding cost. To answer this second question, we must determine how queue size translates into delay cost, which requires knowing the cost of delay. And Im sure there are many more that I left out. Design goals are almost always dynamic. 0000002588 00000 n Each section has numbered principles, and there are 175 in all. Again, you will find some powerful tools to think about how to optimize the use of human and system resources. 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. 11. Yet it's not correct to say that batch sizes should be as small as possible. If we showed the Toyota Production System to an Internet protocol engineer, it is likely that he would remark, "That is a tail-dropping FIFO queue.