I have a few thoughts on the issue of queues that I would like to share. Queues may be the single most understood aspect of application lifecycle management and this is in no way intended to alleviate that. However, I hope to mitigate a bit, and encourage you to look deeper. Making the switch from managing utilization to managing queues is fundamental to increasing value flow.
Development queues are invisible
This is a huge, huge problem that doesn’t get nearly the attention it deserves. Each thing in each of your queues has value (or at least it should have value), and an associated cost of delay. As a quick mental exercise, think through all of the user stories, requirements, bug fixes, planned projects, and other things sitting around in queues in your enterprise. Now, how valuable would your product/service/whatever-you-sell line be if all of those things were finished tomorrow? No need to be accurate, just a rough ballpark figure will do nicely.
That is the price of your queues.
If that hurt, it might be time to figure out a way to turn your queues visible. Never fear, I have a simple yet effective way of doing just this.
Queue Visualization with Boxes
- Get a bunch of moving boxes.
- Write the name of each item in a queue on its own box.
- Stick the boxes next to whoever is supposed to be working on them.
You can even get really fancy and alter box sizes by the size of the task, and color coordinate them. You could write the cost of delay on the items in big red markers to make sure everyone knows how much it costs to let that box sit there. You could put things in them, draw on them and all in all have a jolly good time.
If you’re currently thinking a) that this would take an insane amount of time and b) that all of those boxes would have to be incredibly tiny or they wouldn’t fit in your office you probably have a queue problem.
(This is in no way the only horrible, terrible, and abhorrent thing that queues cause. They drastically increase cycle time, risk, bad kinds of variability, decrease quality, and suck the motivation out of your teams.)
Queues can be good
What? Didn’t you just bludgeon us with mountains of boxes?
This is of course quite true. And in all likelihood, you need fewer queues with drastically fewer things in them. However, like everything in the software development world the extreme is well, extreme. Reducing queues comes with a price tag, sometimes slightly lowered utilization rates (although this is usually greatly exaggerated and only occurs if you drastically reduce work in process and queue size), perhaps in some different form. One company told me they couldn’t reduce their backlog because they wouldn’t be able to tell their customers that the obscure feature they wanted was “on the backlog”… Whatever the cost is, the point is that queue decisions are another U-Shaped decision.
Effective management of queue size will control lead times and utilization rates, and help control variability.