Queues

Queues are everywhere. Every time you stand in line, you are in a queue. The British know this already, but for my non-British friends, understand that a line of people is a queue. A stack of work sitting there waiting for someone to actively work it is also a queue. Examples of queues:

• Message Inbox. A stack of emails that you need to read and process with an action, simply file it away, delete it, or create a rule to prevent the sender from bothering you further is a queue. Likewise your text messages you have not handled are a queue. A physical postal mailbox contains a stack of mail that requires processing. Some of it will be bills to pay and file. Some of it is junk to throw away.
• Any line of people at Disney World. I feel like when my family went to Disney World in Orlando we were paying money to ride a ride called “Stand in a really long line for a really, really long time.” The last time we went, my cynicism got the better of me and I started creating something akin to a value stream map. I wanted to know the amount of time spent riding rides vs the amount of time spent standing in line, eating, resting, standing around in confusion looking at a map, and walking to the next thing.

The kinds of queues that I want to highlight for you are the queues at work. When your company has an idea of something to do differently in the marketplace such as release a new product, a new feature for a product, remove a product, or some other sort of business release like maybe an advertisement, there is a process that such work goes through. And surprise, the work idea itself gets caught in many queues on its way through that system before it can be released.

Invisible Queues

Most queues in product development are invisible. Because work is often electronic, and because the process is also tracked using electronics, it is easy for a queue to form that no one, or perhaps only one person, can see. Visualization systems such as Kanban attempt to make the system and the flow of valuable work through it visible so that queues become visible and can be managed.

Notice that I wrote that we manage queues. You cannot eliminate queues from life or work. They are everywhere, and some are necessary or even desirable.

Examples of invisible queues:

• Hand-offs. A software developer finishes some code and hands it to someone else to test, but they are busy. They set the request aside and finish what they are doing. The item that was set aside is now in a queue.
• Dependencies. A software team needs another team to perform some foundational work that they will rely upon for their own work. Their own work goes into a queue, waiting for the dependency to be resolved before they build their part and it starts working.
• Bottlenecks. A person approves all of the work that a team does. Everyone hands them their work faster than that person can process it. A queue forms in front of them – the equivalent of their inbox for work.
• Distant Planning Horizons. The farther out you plan work, the larger and more complex the work becomes. Risk increases. And because of the large size of the work, it creates queues everywhere it goes.
• Excessive processing. Many larger companies have trauma from past actions that had consequences. People got in trouble, heads rolled, departments were closed, promotions were lost, or there was a good yelling-at by the boss. To prevent these things from happening in the future, the company adds approval, checks, audits, and controls. These slow work down as it gets caught in the queues these steps create. Often, these steps cost more than the risk of the consequences they exist to prevent.
• Defects. Defects cause and expand queueing. When a defect is found in some product, that portion of the product swims back upstream. Sometimes it travels to development for a fix, and sometimes it travels all the way to the drawing board for a total rethink.

How to See Queues

Queues with people standing in line are easy to see, though most people don’t understand what they are seeing. You know you have a queue when work is moving from one place to another and it comes to a rest and stops moving until someone picks it up and starts working on it again. Signs that there are queues include paper tickets with numbers and a sign saying “Now serving number 23,” hold music on phones, waiting rooms, you sitting around playing with your phone waiting for someone to arrive, any line of people, and any message that says, “All of our agents are currently assisting other customers. Your call is important to us.”

The Cost of Queues

Queues cost time and therefore money. Anything we may want to release to the market for a business purpose will take time to deliver. Queues will make that time longer. In fact, we can measure how much work is costing us to not be released to the market using Cost of Delay. The Cost of Delay is the amount of money we are losing every day that some valuable activity is delayed in development instead of released into the hands of our customers.

Queues have costs we don’t measure because accounting is about cost history, but queues are a leading indicator, so they only show up embedded in the cost of development and sales. Accounting cannot see them!

• Increases Time to Market. The total time it takes for any idea to end up in a customer’s hands increases as queues increase.
• Reduces feedback frequency. As the Time to Market grows, we get feedback less frequently from customers increasing our risk.
• Reduces feedback timeliness. As feedback becomes less frequent, it is possible now for us to receive it too late to act on it effectively.
• Reduces efficiency of problem detection. As delays increase, our cadence for inspect and adapt becomes less frequent. Now problems can start slipping through because we are inspecting larger work with longer planning horizons.
• Increases risk exposure. As delays increase, morale drops, and a sense of urgency drops along with it. Knowing things go slow around here, we plan for infrequent release and make larger plans and plan for farther horizons. Big, long-term plans are big batch work and create queues like cigarettes cause cancer. When you release your big project after all of that time, you have created a rather large bundle of complex risk that can explode with a large blast radius. The goal of being agile is to lower risk through small, frequent releases that lower the potential blast radius.
• Causes work starvation in downstream processes. I have seen a group with a huge queue in front of them that they were slow to process starve a downstream team so badly that the team was laid off for lack of work. When the bottleneck was finally resolved and work started flowing, a rehire was necessary to handle the flow.
• Causes batch size inflation. As queues develop and things start to slow down, it naturally causes people to start to bundle things together for the long journey. As a product manager, I am not sending a small, tiny change to a development team that will take months to develop it. I am sending them everything I can think of, because I cannot wait months for feedback on a tiny change.
• Obscures true capacity. How much can we actually get done? We cannot see when there are many queues and the system is slow. A lot of our capacity is hidden by defect processing and the extra management overhead of large projects with many requirements bundled into large releases.
• Delays Learning. As Time to Market increases, the organization learns too many things too infrequently. They are unable to respond to and change all of those things. Most of the learning ends up as waste or arrives too late for anyone to make good use of it.
• Security Risk. Companies that overutilize their employees tend to do so everywhere. Terminations go into a queue, and disconnecting access to company secrets or sensitive customer data is delayed creating massive risk of a breach. Worse, security issues are held in queues and hackers take advantage while the company’s incredibly long Time to Market works its black magic.
• Abandonment. Decisions and work get held up in queues and people give up on them! Decisions are never made and things just happen randomly. People leave and decide they will work around the queue or just surrender to the cynical realization that things will never happen.

I cut off this list because basically queues are causing just about everything that is going wrong in your business. Consider this story. A company was having trouble retaining employees. People were quitting like crazy. It was obvious why: management was rude to employees, and there was a culture where work/life balance was toxic and pay was too low. This was caused by queueing.

What?!?

Yes! The company had such an over-utilized process filled with queues for handling quitting employees that by the time they attempted an exit interview, the employee was already gone. Queues caused the company to fail to disable access to email and company documents from personal devices in a timely fashion. Queues caused complaints from line managers to be held up while the exodus continued. The queues were so bad that complaints about management were lost in a huge list no one could manage. Top management didn’t detect the problem until the company was so famous for being a bad employer that any action they took was a desperate attempt to save a sinking ship.

Queues are Emergent

There’s a big difference between product development and manufacturing. Manufacturing uses fixed machinery and work stations to repeatedly produce the same thing. Product development uses people working together to produce many different unique things. Product development cannot size all work the same. It’s not possible. Also, it is impossible to address THE bottleneck in the system. In product development, queues are emergent as are bottlenecks. They come, and they go.

I Can See! I Can See!

Once you become aware of queueing, you cannot unsee all of the queues everywhere. You might think, “There aren’t enough people or machines here.” Believe it or not, that is usually not the problem. The problem is poorly managing the queues. How do you manage queues? Reduce work batch size thereby reducing planning horizons and as a consequence risk, time to learn, and time to market. Reduce work-in-process and reserve capacity for speed and handling variability (surprises that we all know are coming). Identify and manage bottlenecks, reduce dependencies by eliminating them wherever possible, remove excess processing such as controls to prevent that problem from ten years ago.

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.

This is the book to get if you are looking for more information about queueing and product development. Most applicable to software development. If you are trying to do Scrum (most people are trying and not succeeding), then this is the book to explain the Lean Thinking portion of the Scrum Guide.

Goldratt, E. M., & Cox, J. (2004). The goal: A process of ongoing improvement (3rd ed.). North River Press.

Another great book about queueing theory. However, be aware this book is focused on manufacturing. It can help some ideas become clear and is more accessible than Reinertsen’s book, but, if you work in software, you will never try to fully utilize a developer the way a factory will try to keep a machine busy. People are not machines, and such utilization helps in the factory but kills a product development pipeline.

Last updated 2026-02-17