Slow down to boost profits

A team in which everyone works at top capacity has got to be the most productive, right? This article explains why it ain’t necessarily so.

(Note: I didn’t invent the exercise described here. I first saw something like it presented at the Agile2006 conference by Ashley Johnson and Rich Phillips of Valtech Technologies, Inc.)

The assembly line analogy

I recently conducted an exercise with the folks at North Bay Agile in which two teams formed assembly lines for folding paper airplanes. Each assembly line consisted of a number of distinct operations, as follows:

  • Operation 1 – Get raw material (a sheet of paper) from stock.
  • Operation 2 – Fold inward lengthwise, then unfold.
  • Operation 3 – Fold top corners inward.
  • Operation 4 - Fold sides inward, fold in half, fold wings down.

In the first shift, every member of each team worked at top capacity. The result: Each team produced about a dozen airplanes in 5 minutes.

But then I had each team fill out a “profit and loss” statement. They got credit for “selling” all planes produced, but they were also debited for the labor and material costs of uncompleted airplanes (which stacked up in front of Operation 4, the bottleneck). The financial news: Both teams incurred a loss.

In the second shift, the teams were instructed to slow down to match the rate of the slowest operation. This was accomplished by creating a “buffer zone” before each operation and following a rule which said, “you can’t pass your work on to the next operation until that operation’s buffer zone is empty.” The result: Each team still produced around a dozen airplanes in 5 minutes.

When the profit and loss statements were filled out a second time, each team showed a profit. This was directly due to the fact that no work-in-process inventory built up, thus reducing the amount spent on materials and labor.

The most obvious difference in the overall activity of the assembly lines from shift to shift was that, in the second shift, the upstream operations were sometimes idle. By slowing the upstream operations to match the rate of the slowest operation, both assembly lines increased their productivity.

Increasing productivity stepwise

After the first shift in the exercise, the inclination of several participants was to try to find ways to improve the performance of the slowest operation. As the second shift demonstrates, however, a simpler first step is to just slow down all of the upstream operations to match the rate of the slowest operation.

The business novel The Goal outlines a process for increasing the productivity of a manufacturing system:

  • Step 1 – Identify the system’s bottlenecks.
  • Step 2 – Decide how to exploit the bottlenecks (e.g. don’t let a bottleneck be idle).
  • Step 3 – Subordinate everything else to the above decision (e.g. throttle back the upstream operations).
  • Step 4 – Elevate the system’s bottlenecks (e.g. speed up a slow operation).
  • Step 5 – If, in a previous step, a bottleneck has been broken (i.e. a bottleneck is no longer a bottleneck) go back to Step 1.

 As you can see, the recommendation is to slow down all non-bottleneck operations before trying to speed the bottlenecks up.

How does the assembly line exercise relate to software development?

Although software development is not the same as manufacturing, there are situations in development that exhibit the characteristics of an assembly line. Suppose, for example, that you are a developer building components for use by other developers. If you (the upstream operation) produce components at a rate faster than the other developers (the downstream operations) can understand and use them, you can create a bottleneck, causing excess “inventory” to build up.

Software development is about creating and sharing knowledge

Here are some simple things to remember when considering whether it is more profitable to work at top capacity or to be idle part of the time:

  • Knowledge is the inventory of software development
  • People consume knowledge at their own rate
  • Creating knowledge faster than it can be consumed causes excess inventory
  • Excess inventory reduces profits

In other words, working at your own top capacity may not be the positive thing you think it is. If you’re producing software components at a rate greater than the rate at which they can be put to use, you could be hurting the bottom line.


  1. Dale Bockman:

    Tailoring a process to proceed most efficiently, whether developing software or building airplanes, is desirable. In this article suggesting a principle for streamlining the development process, a brief description of an exercise used to demonstrate the method is used. I would like to address some details that might improve reader understanding and acceptance.

    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.

  2. Steve Bockman:

    Thanks for your comments, Dale. In answer to your first question: No, the article didn’t really cover the “speeding up” part of the exercise. Accordingly, I’ve changed the name of the article from “Slow down to speed up” to “Slow down to boost profits”.

    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.

  3. Shekhar Gulati:

    Good Article. Can the other reason to slow down be to meet the ever changing requirements in software lifecycle as that will help reduce rework also in case things don’t went according to plan?
    Second question:- Dont you think slowing down can make developer less efficient?

  4. Steve Bockman:

    Good questions, Shekhar.

    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.

  5. Twitted by ArntB:

    [...] This post was Twitted by ArntB [...]

  6. Brandon:

    I wouldn’t say that the business thinks it is more desirable to have an effective overall process. I think that the business SHOULD think that way unfortunately, my experience is that if the developers are not fully utilized then they think the can throw more work at them.

    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!

  7. Steve Bockman:

    Thanks, Brandon. I’ve been interested in the Theory of Constraints (TOC) ever since I participated in this exercise at Agile2006, and am always looking for ways to apply it to software development.

    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.

Clicky Web Analytics