Lean development #5

(More on Lean Development by Mary Poppendieck; available as a review copy here.) She talks about queue theory, which was quite interesting. At banks you often have one queue for all tellers, and in shopping centers there’s often an express lane for people with 10 items or less. At a bank you can’t anticipate which customers will take more time, as you can in a shopping center. In software projects, queues form for example when features are handed over to testers, or when a customer decides which features should be implemented.

To prevent congestion, Poppendieck writes, you need to move things around at a steady rate (little variability), in small batches. This translates to fixed iterations (better to defer features to the next iteration than to extend the current iteration with a few days) that aren’t too long (a few weeks). Slack is also important, and as I interpret this, the reason is that as a feature moves from one “station” to another, it should be likely that the person there is ready to take care of it (that is, no queues). The last thing you need to do is to “move variation downstream”. I’m not sure I understood this, but I think it means that it’s better for queues to form late in the project, than early (since it tends to accumulate for each cycle, resulting in longer and longer queues). She uses the analogy of people leaving a football match, queueing to leave the stadium, to enter the parking lot, driving out of the parking lot, and finally as they are about to enter the freeway. In this case, it would be better if queues only formed at the freeway entrance. I guess the total queue time is lower.

With iterations, though, the end of an iteration might be downstream within the context of the current iteration, but it is upstream for all future iterations. In other words, long queue times in acceptance testing is not acceptable, since the results of acceptance testing is feedback to the next iteration.