Search This Blog

Wednesday, January 27, 2010

Queuing Theory

I have been reading the book Scaling Lean and Agile Development. This chapter I am on is deep, and my head is spinning. It is all about queuing theory.

As utilization goes up in a system with lots of variability, average cycle time gets worse, not better.

I think what he is talking about here is that it is better to not try to push your people to be 100% utilized. If you do this you will actually get less work done. Imagine an interstate where you need to get 50,000 cars home from work. It is better to stagger them and only let so many go at a time. If you put them all on the road at the same time, no one is going to go anywhere. You will just sit there in a traffic jam. So it is better to waste a little time by staggering because you will more than make up for the waste in the long run. The same thing goes with scheduling people. You need to give them a little slack time to keep things running smoothly.

As work-item size or batch size increases, variability increases. ... The reality is a nonlinear increase in cycle time.

What he is saying here is that you can prove mathematically that you need to keep your stories small. There is non-linear increase in how long takes to build something if you increase the size of the story. So if you had an 8 point story that normally takes a week and increased that to 80 points, it would take a lot longer than 10 weeks to complete. His estimate is that if your people are 50% utilized then it could take as long as 50 weeks.

To reduce average cycle time, all apparently ‘single’ large items (requirements) in the Product Backlog need to be (eventually) split into many small and roughly equal-sized items. This is easily achieved by representing backlog items as user stories.

So this is basically saying that large items are bad and variably sized items are bad. You need to chunk everything up into little equally sized nuggets.

If you are a business person who has invested ten million euros to create a gigantic pile of partially done Stuff sitting on the floor, not making any money, you walk by it and see it and you feel the pain and urgency to get it moving. And you think about no longer making big piles of partially done stuff. But product development people do not really see and feel the pain of their queues.

Basically he is saying here to not build a big pile of functional specifications or a big pile of code that is not in production. It is better to build a small piece of functionality and get it out there instead of letting your investment sit there wasting away. This is why we use cards in release planning so people can see how much work they are asking for. When you put these requirements in a computer system it is hard to see the vastness of what you are asking for. Cards on a wall don't lie though.

A metaphor shared in lean education: lake and rocks. The depth of the water may represent the inventory level, batch size, iteration length, or cycle time. When the water is high (large batch or inventory size, or iteration length), many rocks are hidden. These rocks represent weaknesses.

This is a cool metaphor. If you develop your code for too long without releasing there will be big problems lurking under all that code. If you release soon you won't have anywhere to hide those problems and you will have to deal with them early.

Queuing theory predicts that irregularly loading large high-variability batches of big requirements onto groups and then pushing for high levels of utilization or multitasking increases cycle time. Avoid that. On the other hand, queueing theory predicts that utilization can be higher without negative cycle-time impact if there was leveling or removal of variability in all elements.

This sums up all he has said before. I should have just posted that in the first place. If you go back to the highway example, imagine a world where everybody drove Honda Civics at the speed limit and stayed in their lanes driving responsibly. We could get home a lot faster.

the journey of applying “basic Theory of Constraints” is to find that one dominant constraint or bottleneck, reduce it so it is no longer dominant, and then look for the new primary constraint. Repeat forever.

I love this theory. I have tried to apply it to all kinds of problems. The book warns against it. I don't completely understand why. It advocates removing queues all together instead of just trying to manage and reduce them.

No comments:

Post a Comment