fishing on the river tay

At Dunkeld, during a snow storm!

kanban

is an excellent book by David Anderson (isbn 978-0-9845214-0-1). As usual I'm going to quote from a few pages:

The essence of starting with Kanban is to change as little as possible.

Failure to make a delivery on a promised date gets noticed much more than the specific content of a given delivery does.

Counter-intuitively, most bottleneck management happens away from the bottleneck.

Speed is most useful if it is in the right direction… If your priority is to find and reduce the constraint you are often solving the wrong problem... The dramatic success of the Toyota Production System (TPS) had nothing to do with finding and eliminating bottlenecks. Toyota's performance gains came from using batch-size reduction and variability reduction to reduce work-in-progress inventory [Don Reinersten]

Kan-ban is a Japanese word that literally means "signal card" in English. In a manufacturing environment, this card is used as a signal to tell an upstream step in a process to produce more work. The workers at each step in the process are not allowed to do work unless they are signalled with a kanban from a downstream step.

Trust is a hard thing to define. Sociologists call it social capital. What they've learned is that trust is event driven and that small, frequent gestures or events enhance trust more than large gestures made only occasionally.

High-trust cultures tend to have flatter structures than lower-trust cultures.

The traditional approach to forming a commitment around scope, schedule, and budget is indicative of a one-off transaction. It implies that there is no ongoing relationship; it implies a low level of trust.

The more groups involved, the longer the meeting is likely to take. The longer the meeting, the less frequently you are likely to hold it…

Buffers and queues add WIP to your system and their effect is to lengthen lead time. However, buffers and queues smooth flow and improve predictability of that lead time. By smoothing flow, they increase throughput, so more work is delivered through the kanban system. Buffers also ensure that people are kept working and provide for greater utilisation. There needs to be a balance, and buffers help maintain it. In many instances you are seeking business agility through shorter lead times, and higher quality partly through lower work-in-progress. However, do not sacrifice predictability in order to achieve agility or quality. If your queue and buffer sizes are too small and your system suffers from a lot of stop-go behaviour due to variability, your lead times will be unpredictable, with a wide spread of variability. The key to choosing a WIP limit for a buffer is that it must be large enough to ensure smooth flow in the system and avoid idle time in the bottleneck.

The first principles of Kanban are to limit work-in-progress and to pull work using a visual signalling system.

You need slack to enable continuous improvement… In order to have slack, you must have an unbalanced value stream with a bottleneck resource.

The width of a bottle's neck controls the flow of liquid into and out of the bottle. We can pour quickly from a wide neck, but often with a greater risk of spillage. With a narrow neck, the flow is slower but it can be more precise… In general, a bottleneck in a process flow is anywhere that a backlog of work builds up waiting to be processed.

As we all know, there really is no such thing are multi-tasking in the office; what we do is frequent task switching.

test code is code but it's different

Here's a bit of code...

def to_roman(n)
  result = ''
  ['V',5,'IV',4,'I',1].each_slice(2) do |ch,unit|
    while n >= unit do
      result += ch
      n -= unit
    end  
  end  
  result
end

And here's a bit of test code...

def test_arabic_integer_to_roman_string
  assert_equal    "I", to_roman(1)
  assert_equal   "II", to_roman(2)
  assert_equal  "III", to_roman(3)
  assert_equal   "IV", to_roman(4)
  assert_equal    "V", to_roman(5)
  assert_equal   "VI", to_roman(6)
  assert_equal  "VII", to_roman(7)
  assert_equal "VIII", to_roman(8)
end

I'm sometimes asked which is more important, the code or the tests? Does it matter if you refactor the code but let debt accumulate in the tests? A question like this tells me that the questioner probably doesn't really understand that test-code is the yin to the yang of the code it tests and vice versa. That they form a co-evolving system. When you feel the tests need refactoring that isn't a sign you did something wrong. That's just part of development! The tests mean that code under test is not as closed a system as it would be without them. And being less closed it can stave off entropy for longer.

That's not to say that code and tests are the same. They're both code, but they're not the same.

For example, suppose I have a metric that calculates a measure of the complexity of code. I use this metric to calculate the complexity of the code under test and also the complexity of its tests. Imagine if the complexity of my tests is greater than the complexity of the code it tests. How do I know the tests aren't wrong? Should I write some tests for the tests? And if the pattern repeats and the complexity of the tests for the tests is higher still should I write some tests for the tests for the tests? No. That way leads nowhere. I don't want complexity in my tests. It want them simple. I want them linear. The complexity of my tests might be greater than one, but it must be smaller than the complexity of what it's testing.
Test code is code but it's different.

Or consider the names of functions. In code under test I want Goldilocks names - names that are not too long, and not too short. On the one hand I want reasonably long names - long enough to express intention. On the other hand, names always occur as sub-expressions of larger expressions. If my names are too long, the full expressions they're part of quickly become unwieldy. It's in the full expressions I really want understandability, so I can turn the name-length-dial down a bit.
But the names of my test functions are different. They are never part of larger expressions. So for them I can turn the name-length-dial up up up - all the way to, deep breath, no_newline_at_end_of_file_msg_is_gobbled_when_at_end_of_common_section
Test code is code but it's different.

the lean startup

is an excellent book by Eric Ries (isbn 978-0-670-92160-7). As usual I'm going to quote from a few pages:

What if we found ourselves building something that nobody wanted? In that case what did it matter if we did it on time and on budget?

I've come to believe that learning is the essential unit of progress for startups.

If you cannot fail, you cannot learn.

Qualitative learning is a necessary companion to quantitative testing.

Pay no attention to the eight people behind the curtain.

When I could think of nothing else to do, I was finally ready to turn to the last resort: talking to customers.

That which optimizes one part of the system necessarily undermines the system as a whole.

Large batches tend to grow over time.

The paradoxical Toyota proverb "Stop production so production never had to stop."

We routinely asked new engineers to make a change to the production environment on their first day... They would ask, "What will happen to me if I accidentally disrupt or stop the production process?" ... We told new hires, "If our production process is so fragile that you can break it on your very first day of work, shame on us for making it so easy to do so." If they did manage to break it, we immediately would have them lead the effort to fix the problem as well as the effort to prevent the next person from repeating the mistake.

Switching to validated learning feels worse before it feels better... the problems caused by the old system tend to be intangible, whereas the problems of the new system are all too tangible.

certain to win

is an excellent book by Chet Richards (isbn 1-4134-5376-7). As usual I'm going to quote from a few pages:

Man is the child of custom, not the child of his ancestors. [Ibn Khaldun, 1377 A.D.]

Financially massive organizations warp the environment they inhabit much like the way gravitationally massive bodies warp space-time in physics.

Since what you're looking for is mistakes, a general rule is that bad news is the only kind that will do you any good.

A similar effect, a breakdown in the quality of energy, is well known to students of physics as "entropy". The energy is still there, but it isn't available for doing work. The insidious thing about entropy is that within a closed system, it always increases. In other words, closed systems run down.

The more you try to control people, the less control you get.

If a just-in-time production line had to wait for a formal decision process to work, it would hardly move at all, and it would never improve.

Complex methodologies can turn the attention of the company inwards.

We polish individual techniques and also train as a group.

It is not a matter of "getting it", it's a matter of doing it.

Mutual trust comes from mutual experience.

Most readers are familiar with the dualities that seem to inhabit everything oriental, the best known being the yin / yang. Yin signifies such things as endurance and the maintenance of the present states, while yang represents vitality and change. In the Taoist cosmology that underlies eastern strategy, neither can exist without the other, and the familiar symbol shows each depending on and containing the seed of the other.

security scan kanban

There's something about the typical kanban board I see that feels wrong. Let me try to explain. It's to do with what kanban means; what a kanban is. A true kanban is a physical thing used to regulate supply and demand. For example, consider putting your hand-luggage through an airport security scanner. You put your hand-luggage into empty trays. The trays go through the scanner. At the other side you take your hand-luggage out of the trays. The emptied trays go back to the start (often on a separate conveyor belt underneath) for someone else to put their hand-luggage into. Often you're ready to put your hand-luggage through the scanner but you have to wait because there are no empty trays. The number of trays represents the capacity of the system. Each tray is a kanban.

Now let's take a look at a typical kanban board such as the one on the left. It has two columns; one column for the activity of Wibbling which has a work-in-progress (WIP) limit of 5, and one column for the activity of Fubaring which has a work-in-progress limit of 4. There are 3 blue stories being Wibbled and 4 blue stories being Fubar'd.

How is this board supposed to be used? I count the number of blue stories currently being Wibbled - 1,2,3. I look up to the top of the Wibbling column and see its WIP limit is 5. I know 3 is less than 5 so I know there is some spare Wibbling capacity. If I want to know how much I can do the math, 5-3==2. And repeat... I count the number number of blue stories currently being Fubar'd - 1,2,3,4. I look up to the top of the Fubaring column and see its WIP limit is 4. I know 4 is the same as 4 so there is currently no spare Fubaring capacity.

It seems odd to have two columns that look exactly the same when one has spare capacity and the other does not!

My problem is that 5 and 4 are abstractions!
5 is not the same as 5 trays.
5 is just 5.
But 5 trays is [Tray Tray Tray Tray Tray].

What's important about the 5 isn't the 5.
What's important about the 5 is that it represents 5 trays.
What's important about the 5 is the relationship between the 5 and the number of blue stories it limits. The Wibbling blue story WIP limit is abstracted to a 5 but the blue stories are not. I have 1,2,3 blue stories in the Wibbling column but I'm not representing them with a 3, I'm representing them with 1,2,3 actual blue story cards.

Here's the alternative 'scan kanban' I'm thinking of.
I remove the 5 WIP limit from the top of the Wibbling column. Instead I put in 1,2,3,4,5 orange  Tray s.
I remove the 4 WIP limit from the top of the Fubaring column. Instead I put in 1,2,3,4 red  Tray s.

I add the rule that every  Story  must always be in a tray.

Now I can instantly see the Wibbling column has some spare capacity because there are some  Tray s with no  Story  in them. I can count the spare capacity if I want -  1 ,  2 . No math needed. Easy. I can instantly see the Fubaring column has no spare capacity because all the  Tray s contain a  Story .

Now I have a kanban board that actually has kanban on it!
Each tray is a kanban.
Now I can experience pull.

Suppose the workers to the right of the Fubaring column use green  Tray s. They send an empty  Tray  to the Fubaring column to signal they're ready to pull a  Story .

The workers in the Fubaring column move a done  Story  from their  Tray  into the empty  Tray .

The workers to the right of the Fubaring column pull the  Story  in its  Tray  back into their column.

The workers in the Fubaring column now have an empty  Tray .

The workers in the Fubaring column can send their empty  Tray  to the Wibbling column to signal they're ready to pull a  Story .

Thus each  Story  flows left to right while each empty  Tray   Tray   Tray  moves right to left.

Once we have a system under control we can try to improve. For example, we can see what happens when we reduce the WIP limit by 1 in the Wibbling column. We simply remove a  Tray .





Caveat Emptor: I've never seen this style of kanban in actual use. It's just an idea so far. As always, if anyone has any feedback it would be much appreciated.

Update! Here's a follow up blog entry.