I'd rather play golf

In two previous posts, part un and part deux, I briefly summarized three of the important themes Don Reinertsen describes in The Principles of Product Development Flow [1]: Economics, Queuing, and Variability. In this final part, I’ll briefly summarize two other themes, Batch Size and WIP constraints, and present some closing remarks.

Batch Size

Understanding the consequences of batch size is exceedingly important in product development. Here’s a quote from Chapter 5, pp. 123:

In fact, many of the most important improvements in product development: concurrent engineering, rapid prototyping, agile software methods, are recognizable as batch size reductions. However, because developers fail to recognize the underlying mechanism of action behind these improvements, they lose the chance to apply this principle much more broadly throughout the development process.

Principle B1 on page 124 states one of Reinertsen’s fundamental theses: reducing batch size reduces cycle time. The following graph (Figure 5-1, used with permission) uses a Cumulative Flow Diagram (CFD) to depict a queue with a steady arrival rate but with different batch sizes. With a CFD the size of the shaded area is the size of the queue, and is directly proportional to batch size. For any distribution of arrivals and service times, queuing theory says that the average size of the queue is proportional to the average cycle time. Hence one can reduce cycle time simply by reducing batch size–and in the example below (used with permission) the two graphs share the same arrival and departure rates, but differ substantially in queue size:

Batch size reduction is, therefore, a simple way to shorten a project’s cycle time. Even if the queues are not Markovian (consisting of independent projects with random arrival and cycle times), there are distinct, measurable advantages to reducing batch size. One is that reducing batch size lowers variability, because it prevents periodic overloads (Principle B2). Batch size reduction also accelerates feedback (Principle B3) and decreases risk (Principle B4). In contrast, large batches reduce motivation and productivity (Principle B7), and contribute to exponential growth in project cost (Principle B8).

Then what is the optimal batch size for any specific product development process? Once again, Reinertsen draws us back into economic principles: it all depends on the economic factors associated with the process, most particularly COD (cost of delay). Invariably the optimal batch size is the bottom of a parabola, since there are tradeoffs between holding costs (retaining larger batches) and transaction costs (the ability to service smaller units of work). Here is Figure 5-5 from page 135, again used with permission, that illustrates this point:

An important point that Reinertsen repeats several times throughout the book is that the Total Cost parabola has a relatively flat bottom. In Reinertsen’s experience such situations are common, and this characteristic can be exploited because one can achieve a near-optimal value on the y-axis at a range of points on the x-axis. In practice this means that even gross estimation errors can still yield near-optimal performance.

By far the most important principle concerning batch size is Principle B21, the “Batch Size First Principle” (pp. 147-8). Here’s an excerpt:

Developers often ask if they should begin by changing capacity utilization or by reducing batch size. In theory, I could tell you to choose the approach that produces the most economic benefit for the least economic cost. However, the practical answer is much simpler: start with batch size……

…..Unfortunately, bottlenecks are terribly seductive. It is very easy to convince product developers that queues are caused by bottlenecks, because this explanation is much more intuitively appealing than blaming batch size. The average developer does not manage or even measure batch size. In contrast, a whole industry has emerged based on Goldratt’s Theory of Constraints, convincing people that their first priority should be to find and fix bottlenecks…..

….So, in practice, I always suggest reducing batch size before adding capacity at bottlenecks. Batch size reduction is cheaper than adding capacity, it is easy to sell to top management, and it massively reduces queues. It is always our weapon of choice for reducing queues.

WIP Constraints

Because random variations in product development tasks can occur despite the best of intentions, and as shown above have a significant impact on cycle time, a set of constraint mechanisms are necessary to ensure that queues do not spin viciously out of control. Work-in-process (WIP) constraints is the name given to these mechanisms.

The simplest of these, described in Principle W1 on page 159, is to block arrivals to a queue when the queue becomes large. If k is the maximum queue size, the notation to describe this queue is M/M/1/k. Capping a queue reduces average cycle time, since cycle time is proportional to queue size with a Markovian queue, a reasonable assumption for most queues in product development. However, the significant tradeoff to this is that capacity utilization is reduced. Consequently it is worthwhile to set the level of k to maximize profitability, given estimates for the cost of delay, capacity costs, and the opportunity cost associated with blocked tasks.

Reinertsen describes a total of 23 techniques to employ WIP constraints on queues. Several of these are straightforward management techniques, such as transferring less-important resources to an emerging (large) queue (Principle W9), or utilizing part-time or contract help to handle peak queue volume (Principle W10). In each case, however, economic cost is presented as the metric upon which to analyze the specific tradeoffs.

Summary

In the material above, I’ve highlighted several themes within The Principles of Product Development Flow: Economics, Queues, Variability, Batch size, and WIP constraints. Much of the background for this material has appeared in Reinertsen’s two previous volumes [2,3]. However, The Principles of Product Development Flow does not supersede these two prior volumes; rather, they are complimentary. In particular, Developing Products in Half the Time presents substantial material on estimating the cost of delay, a vital prerequisite to understanding the economic relationships among the various facets of product development.

Above all, this current volume is about product development flow; avoiding impediments that cause delay, and because the cost of delay is rarely if ever zero, reduction in profitability. Here is another quote from Chapter 7, page 214:

It is critical to remember that we block a resource whenever we service a job. The benefit of giving immediate service to any job is its cost of delay savings, and the cost is the amount of time we block the resources. Both cost and benefit must enter into an economically correct sequencing.

This idea is exemplified by Principle F17 (pp. 213-4). When task durations and delay costs are different, Reinertsen suggests the Weighted Shortest Job First (WSJF) scheduling strategy, where jobs are weighted by their cost of delay and task priority is based on delay cost divided by task duration. Reinertsen argues that scheduling in this way makes more sense than, for example, prioritizing based on Return on Investment (ROI). This is because the total profit of a high ROI project may be less sensitive to schedule delay than another project with a lower ROI. Here is Figure 7-11 from page 213, used with permission:

A significant emphasis of this book is the management of queues. Reinertsen utilizes queuing theory to explain the relationship between delays and queue size, and offers a mathematical foundation for assessing queue management problems, always based on an economic framework. What the book is not, however, is a cookbook of “best practices”. In this 1997 interview, Don Reinertsen stated:

I am against the notion of ‘best practices’ because it implies that there is a single best way of doing anything. Embedded in the idea is the tacit assumption that following the ‘best practice’ always results in the ‘best outcome’. Since I have never met a really experienced manager who believed this was true, I am not sure I am really being very radical. I simply believe that all practices are ‘tools’ that are useful to achieve certain objectives in certain contexts.

Another key theme that Reinertsen stresses is that while product development does share some similarities to manufacturing, the two are very different with respect to their economic tradeoffs. In manufacturing, one can achieve economic value from every product that rolls off the assembly line. Moreover, profit can be maximized by systematically reducing variability in each phase of the manufacturing process. In contrast, in product development variability is constant and cannot be eliminated outright; rather, it has to be managed. Product development is about risk-taking; value can be achieved only from changing designs to create new products, which implies a tradeoff between risk and reward. Reinertsen’s thesis is that this tradeoff can be managed only through the analysis of economic factors.

The pragmatic principles contained within this book are intended as tools to assist with everyday decision-making, utilizing the pertinent economic factors that are unique to each enterprise. The lessons are as applicable to software product development as they are to any other industry. The Principles of Product Development Flow is a worthy follow-on to Managing the Design Factory, and all three Reinertsen volumes belong on every product manager’s bookshelf.

[1] Donald G. Reinertsen (May 2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, Redondo Beach, California. ISBN 1-935401-00-9.

[2] Donald G. Reinertsen (1997). Managing the Design Factory. Simon and Schuster, New York, New York. ISBN 0-684-83991-1.

[3] Preston G. Smith and Donald G. Reinertsen (1998). Developing Products in Half the Time: New Rules, New Tools (2nd edition). John Wiley and Sons, New York, New York. ISBN 0471-292524.