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.
| 
ABOUT DON
REINERTSEN