An Interview with Don Reinertsen (1/2)
Applying Batch Size to Product Development:
Unconventional Wisdom about Speed and Flexibility - Part 1 PDBPR: Recently, you presented some
surprising data suggesting that very few developers wait until they have most requirements
before starting design work. Where did your data come from and what is it telling us?
Reinertsen: The data comes from 500 attendees of my
class at CalTech over the last 10 years. It’s a statistically robust sample from many
different industries. It shows that most design work begins long before all requirements
are known. For every developer who waits until 80 percent or more of requirements are
known, there are 6 developers who have already begun designing.
PDBPR: Given
that most people are beginning the design phase with incomplete knowledge of requirements,
what’s the indication that you know enough to begin design?
Reinertsen: The question I would always ask is this:
‘Do I have enough information to do useful work?’ The notion that you
need all of the requirements before you begin designing is tied to the concept that
requirements are a monolithic entity that can only be complete and usable, or incomplete
and unusable. In reality, requirements can be decomposed into subsets of data of differing
importance, and which are needed at different times. Therefore, it makes sense to finalize
the requirements on the portion of the design that we need to work on first, and proceed
with this work while we resolve other less urgent requirements.
For example, if I’m designing a cell phone, I
eventually must decide what words will appear on the display. However this can be decided
very late in the process since it can be easily modified in the software. But, I cannot
postpone deciding how big the screen is going to be. The size of the LCD display affects
the package size, the chips I use to drive the display, etc. You don’t want your
marketing people researching what words to use until they freeze screen size. The general
principle is to focus first on the characteristics of the phone that are preventing the
designers from working on the design.
PDBPR: And
this relates to the way in which you apply "batch size" to product development.
Reinertsen: Exactly. If you go to the average
product developer today and ask, ‘what is the batch size you’re using in
product development and why?’ their response would be ‘what do you mean
by batch size and why would I be interested in it?’ It’s simply not a
conceptual frame through which most developers look at their process. Yet, the notion that
we need all requirements prior to the design phase is analogous to saying that the
only batch size in which I can deliver requirements is 100% of the work product. Because
they are unaware of batch size most product developers use larger batch sizes than they
should.
PDBPR: And
in product development, what we’re generally dealing with is batches of information
– the batch sizes in which information is transferred.
Reinertsen: Yes. Many product developers only think
of batch size as it applies to physical objects. Yet, the same concept applies to the size
of the batches with which we handle information. For example, if we write 5,000 lines of
code before we run a test, our batch size is ten times higher than if we write 500 lines
before we run a test.
PDBPR: But
isn’t it the case that as you decrease the batch size in which information is
transferred, you’re increasing the quantity of information transfers? It seems that
there must be risks and costs to increasing the number of transfers you’re doing, for
example, version control problems, the likelihood of introducing errors, and a potential
overall increase in chaos and confusion. How do you address this?
Reinertsen: I will lump together all of the problems
you mentioned and call them transaction costs. Transaction costs are linearly
proportional to the number of transactions. All processes have another cost, which is the
cost associated with not doing a batch transfer, which I call the holding cost.
The smaller the batch size you use, the smaller the holding cost. One is a hyperbolic
function and the other is a linear function. They combine to create the "U"
shaped curve for total cost. If you keep decreasing batch size without paying attention to
transaction costs you will be overwhelmed by transaction overhead. Smaller batch size is
only better when it moves you towards the optimum of the "U" curve – which
is at the trough of the "U."
A good model is what has happened in software development.
Forty years ago, the waterfall model for software development said that we should define all
requirements before we begin any design; complete all design before we do any
coding; and complete all coding before we do any testing. That was a classic
large-batch transfer model. Now we find people using what are called daily build-test
cycles. They write code, submit it by four o’clock in the afternoon and have the
bug reports back by eight o’clock the next morning. If you used the old methodology
for testing, where it took you two weeks to set up a test, then you would end up getting
buried in testing costs if you tried daily testing cycles. Daily build-test cycles have
become feasible because developers have lowered transaction costs by automating the
testing process. Once you recognize that doing a lot of small batches is good, then you
can justify automating it, and this automation lowers the transaction cost per batch by
orders of magnitude. This makes it economically feasible to do testing in many small
batches. The point is that the underlying philosophy that product development should be
done in large batches tends to block the investments that enable it to be done in small
batches.
PDBPR: It
seems to be the case that, as product developers optimize their batch sizes – and you
suggest that, in most cases, this means making them smaller – there needs to be more
and not less discipline involved if we wish to control transaction costs.
Reinertsen: You would think that a small batch
process requires great discipline but, in fact, it requires a form of discipline that is
surprisingly easy to achieve. Small batch sizes provide immediate feedback, which almost
automatically improves quality and discipline. To extend the software analogy, suppose I
make a bad assumption about the structure of a protocol in the software that I’m
writing. I write bad code, and the next morning I get feedback that says it doesn’t
work. I very quickly find out what the bad assumption was and I haven’t written
ninety days worth of code with a bad assumption embedded within it.
This is exactly what happened in manufacturing when we
reduced batch size and shrunk the inventory between process stages in our factories. The
inventory was there to compensate for the variation we had in the process – machines
breaking down, people producing bad parts, etc. But, inventory raised overhead. I once
worked with a plant which had large batch sizes and large amounts of inventory. We did a
weekly production schedule to plan when each work order would arrive at each process
center. Because the cycle time in the factory was 16 weeks, we had 100 times as many work
orders to plan as we would in a JIT environment, with a cycle time of 24 hours. We were
trying to keep track of 20,000 work orders on the factory floor, and each of them was
going to cross many process centers. The weekly plan spanned a 16-week period, and you
would end up throwing out fifteen-sixteenths of it, unused, at the end of each week. But
as you shift to JIT, smaller batch sizes, and flow-based operations, you’re no longer
planning 16 weeks. You’re planning for the 200 work orders of that day.
When it took 16 weeks for a part to move through the
factory, you needed a check-in point every time the part moved so that you knew where it
was. You’d have 30 move transactions in the course of that process just to keep track
of things. When we reduced cycle time to only 24 hours, we eliminated almost all of these
transactions. The old system, with the large batch sizes and a very long cycle time,
actually required much more paperwork and paperwork discipline. While a process with
smaller batch sizes does require discipline because it is sensitive to certain variances
that are hidden by a process with large batches, this discipline is easier to achieve
because you spend less time on non-value added tasks. It is easier to achieve discipline
when cycle times are shorter.
PDBPR: What
you’re suggesting is that, from one perspective, we can talk about smaller batch
sizes, while from another perspective we can look at the same thing and speak about the
value of fast feedback loops…
Reinertsen: Yes, feedback is inherently faster when
batch sizes are small. This rapid feedback has significant psychological payoffs because
immediate feedback has a more powerful effect on behavior. The longer the time between
when something is done and when the feedback on it is received, the more you break down
this link of causality between the action taken and the negative result, which, in turn,
breaks down the sense of control over outcomes and over behavior. The faster the feedback
the more people end up believing that they can actually control something.
Part
II >
This article originally appeared in the May 2003
issue of PDBPR
 To join our
e-mail list and receive future updates on "Lean Product Development, click here.
|
