In 1910, the builders of early telephone systems faced a serious challenge. They needed to predict how many phone lines, circuits, and switchboard operators they would need, yet the volume and individual lengths of calls were both quite variable. It wasn’t at all obvious how to best utilize the equipment and make the minimum investment to meet their needs.
A Danish mathematician named Ågner Krarup Erlang applied statistical methods to solve this set of problems, inventing queueing theory. His solutions can be applied to any system in which randomly arriving, variable packets of work flow through a finite system of activities or resources.
Queueing Theory Proves Useful
Erlang’s work was fundamental in managing work which has to wait in line. (In Britain, this is known as a queue). For instance, a bank has multiple tellers but only one line. Why? Because queueing theory tells us that this will serve the most people with the shortest waiting times. One teller might spend 10 minutes on a single complicated transaction while the other customers all quickly go through the other two tellers.
This may seem obvious when you see it, but in general the solutions of queueing theory aren’t obvious before-hand, and sometimes seem counter-intuitive. Traffic management in particular tends to boggle the mind. However, since the 1920s, queueing theory has been used extensively in telephony, circuit design, traffic management, and other fields to successfully design optimal systems which deliver substantial improvements in throughput and reliability.
Meanwhile, on the Manufacturing Floor…
Starting in the 1940s or so, manufacturing engineers developed what we now call Lean methods by experimentation, apparently without knowing about queueing theory. Some of the solutions predicted by queueing theory were discovered, but often without fully understanding why they worked. For instance, single-piece flow was recognized as a very good thing in manufacturing, but then people tried to apply it in other fields and couldn’t see why it didn’t work.
In the late 80s or early 90s, a few people made the connection. Queueing theory explained why Lean manufacturing worked – and it explained why Lean manufacturing practices didn’t always work in other fields. Even better, queueing theory suggested other practices which did work. This proved hugely valuable. Don Reinertsen captured this crossover thinking in Managing the Design Factory in 1997.
Software Development Joins the Queueing Theory Party
By 1997, the agile software revolution was in full steam as well. Like the Lean manufacturing experts, agile experts had developed methods to manage the flow of – you guessed it – randomly arriving variable chunks of work. The early agilists didn’t know that queueing theory could explain why their methods worked. They captured their discoveries in maxims, just as in Lean manufacturing.
In the mid-2000s, a few agilists including Mary Poppendieck, David Anderson, and a bit later Dean Leffingwell, realized that queueing theory beautifully explained why agile worked. And they saw that queueing theory also explained why “not really agile” methods sometimes got agile results anyways, and why some practices which appeared agile failed.
For instance, agile results can be had without releasing every sprint to the end customer – if this particular project can stay on the right track without constant feedback from the customer. Firmware developers had realized this for some time but couldn’t explain it. On the other hand, “done done” is fundamental. Countless agile projects have run into trouble because they defined “done done” as “ready to go to system test”. Without queueing theory, it’s hard to explain why that won’t work.
A Decade of Mutual Growth
In 2009, Reinertsen published a much more usable compendium of queuing theory principles and tools as The Principles of Product Development Flow. More people applied queueing theory and systems thinking to their agile methods, allowing them to safely adapt methods to fit their situations. In the last decade we also saw some agile practices percolating into Lean, primarily those involving how to manage people and communication rather than the flow of work. For instance, stand-up meetings and tools for visual planning boards are popping up in other fields.
The cross-fertilization has been fruitful on all sides. One of the products of that cross-fertilization is the Rapid Learning Cycles framework, which gets agile results by managing knowledge acquisition using tools derived from queueing theory and some of the communication practices from agile development. Because the Rapid Learning Cycles framework and agile software share the same roots in queueing theory, they can be coordinated using queueing theory tools such as cadence.
I hope you’ve enjoyed this bit of history.