Have a look at that shape. Take your time, there is no need to hurry. Which side of that shape is in the front? Is it the one which top left corner is the as the top left corner of the shape? Or, is it the one, which bottom right corner is the same as the bottom right corner of the shape?

Did you move your head to see the shape from a different perspective so that you can see the different sides? Did it work? Do you have a more suitable answer now than a minute before? Most probably not, but here is an interesting idea: what if I tell you that the shape is not a cube.

You were thinking about a cube, weren’t you? But it can be a two dimensional shape with lines, triangles, rectangles and other shapes. I didn’t tell you that it was a cube.

An infinite queue is a column on the Kanban board somewhere between the Queue and Live columns, one that doesn’t have a WIP limit and into which one can put many work items as one wants. A column without a WIP limit sounds like a bad practice, because if there is no WIP limit what will ensure that the work items are moving - being pulled - forward? Nothing really, so having infinite queues may not be a good idea after all. However, there are situations when we need them, because they have an important purpose: they connect flows. It was said before that an infinite queue cuts the flow into two pieces, but I argue that it connects the two pieces rather than cuts them.

I’m going to speak at two conferences this spring: on the 10th and 11st of April at ACCU 2013 and on the 15th of April at ACE! 2013. At ACCU, I’m going to talk about how to narrow down what to test and how to measure and manage flow:

I was adding a new functionality to one of my applications when I realised that I wrote this piece of code:

1
2
3
4
5
6
7
8
9

if condition1 && condition2
  # do what is necessary
  # ...
  # ...
else
  # I don't if when this will happen and what to do
  #
  # send me a mail anyway
end

If you have read the coin game post (in case you haven’t, click here, read it - it is a quick and good read by the way -, and come back), you may wonder why the batch size of 6 produced the shortest completion time in the example game. Let’s find out. If we have a look at the flow of the game, we can find two major components: turning over the coins and moving them around (transfer). If you think about it, the time the players need to turn over all the coins is almost the same in each round. This action is so simple and we get so used to it that improving it during the game - in the given time frame - is nearly impossible. So, it is safe to state that the time spent on this component is constant during the game. However, if it is the case that the group finishes one round in 1 minute and 10 seconds, and another in 1 minute and 40 seconds, the variable must be the other component, which is the transfer time. It seems that there is a connection between the batch size and the time we need to move the batches around. Fortunately, Donald G. Reinertsen can explain this connection, and show us why the batch size of 6 produced the shortest transfer time and not 1 or 50.