So now I consider it part of my job to help the business understand that there’s a difference between efficiency and productivity. I think it’s a long, but worthwhile, effort.

That exercise is a wonderful way to teach people TOC, and I recommend all readers go through it themselves!

Also, my experience with the exercise is that people learn local optimization at the expense of quality very quickly in Operation 2. People tend to pick up 10 sheets at a time and fold them all at once, which creates pain for downstream resources as they often have to re-fold sections due to lousy seams.

Nice work!
Brandon

In answer to your first question, I’d say that slowing down is a good thing to do whenever something is being produced faster than it can be consumed. If requirement changes are happening too quickly, slowing down is a good first step. A good second step would be to see if the development process can be made to respond more quickly to the changes.

As to your second question: Yes, slowing down can make a developer less efficient, but is the efficiency of an individual developer really what you want? As far as the business is concerned, it’s more desirable to have an effective overall process and make a profit than to have efficient developers and incur a loss.

The “speeding up”, however, was actually part of the original exercise, and showed up as follows: In the first shift, it took longer and longer to produce each successive airplane because each one had to wait its turn in the ever-growing pile of inventory in front of the slowest operation. In the second shift no inventory build-up occurred, so each airplane was produced in the same amount of time (hence the speedup).

It works like this: Let’s say it takes 30 seconds to perform Operation 4 (the bottleneck), and that airplanes under construction arrive at that operation every 10 seconds. The first airplane in the line doesn’t have to wait at all, but the second one sits in the pile for 20 seconds while Operation 4 works on the first plane. It gets worse with the third plane, which has to sit in the pile for 40 seconds (10 seconds waiting for plane 1 plus 30 seconds waiting for plane 2). The time to perform Operation 4 on each plane grows progressively longer, as follows:

Plane 1 - 30 seconds
Plane 2 - 50 seconds (30 second operation + 20 second wait)
Plane 3 - 70 seconds (30 second operation + 40 second wait)
Plane 4 - 90 seconds (30 second operation + 60 second wait)

I’ll attempt to answer the rest of your questions in a subsequent comment.

The “grabber” about your assembly line analogy is that things are not what one would think them to be in advance; that one should slow down to speed up. The degree to which the reader is convinced then depends on the description that follows in the article.

The setup of the assembly line and the alteration of the rules for the second trial are clear. The evaluation of slowing down might be better understood if more detail about the bookkeeping were included, so that the reader could learn precisely what changes occurred and could evaluate the benefit of the changes. This might serve to answer some questions that occur.

If a dozen airplanes were produced in five minutes in both situations, does this represent speeding up?

If they were produced in five minutes in both situations, what provides the improvement in salary? (The financial benefits are said to be based on material and salary.)

The difference in the two approaches seems to boil down to partially assembled airplanes stacking up at the bottleneck. One does not know from the description what value was put on material and on storage cost, and how the value was determined. Was material “on-hand” but not used because the first guy in the assembly line worked slower included in the calculation?

If any of these suggestions were implemented, the purpose would be to give the reader the information necessary to come to a conclusion on his own.