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.