kanban push-me-pull-you

I've been thinking some more about kanban and visualization. A while ago I blogged about my security-scan kanban idea of introducing proper physical kanban onto the board. Instead of writing a work-in-progress limit of 5 at the top of a column you introduce 5 physical "empty-tray" kanbans. Different columns use different coloured kanban. For example, here's a very simple kanban board with a Wibbling limit of 4 yellow trays and a Fubaring limit of 5 red trays. The stories are in blue and must always be in a tray.

I mentioned how this allows genuine pulling. For example, the Fubarers can signal they're ready to pull a story from the Wibblers by moving an empty red kanban tray into the Wibbling column.

I said that the Wibblers could simply move a done blue story from its yellow kanban into an empty red kanban. Something about that bothered me and I think I now know what it is. Once again it's about visualization. What bothers me is that there is no representation of whether a blue story is done until it's moved into an empty kanban. There is no visual display of whether a blue story actually is "in-progress" and being worked on, or whether its "in-queue" and waiting for an empty red kanban. That feels wrong.

More recently, I blogged about about the common pattern of splitting each column; one for ongoing, one for done, like this. Something about the done column didn't feel quite right either.

So here's what I'm thinking. As well as moving empty-kanbans upstream to signal a pull, you can also move full-kanbans downstream to signal a push. For example, when a Wibbler finishes a blue story they don't leave it in their Wibbling column, waiting for a red kanban pull signal, they move it, still in its yellow kanban, into the Fubaring column, like this:

Ideally, the departing full-yellow-kanban will be just-in-time to meet an arriving empty-red-kanban between the columns...

...and the blue-story will flow from the full-yellow-kanban into the empty-red-kanban:

On the other hand, if the Wibblers are working much faster than the Fubarers then the Fubarer's column will fill up with full-kanban push-requests:

As the Fubarer's column fills up with full-kanban push-requests from upstream it's likely it will also be filling up with empty-kanbans pull-requests from downstream (in green say):

Push-me-pull-you is very visual:

• There's one representation of flow ; thin columns with kanban of one colour only.
• There's a different representation of lack of flow ; fat columns filling up (at the bottleneck) with two or three different coloured kanbans.

Push-me-pull-you points to problems:

• If the yellow Wibblers work faster than the downstream red Fubarers, the Wibbler's full yellow kanban get stuck downstream in the Fubarer's column, inviting the Wibblers to help the Fubarers.
• If the red Fubarers work faster than the upstream yellow Wibblers, the Fubarer's empty red kanban get stuck upstream in the Wibbler's column, inviting the Fubarers to help the Wibblers.

Push-me-pull-you has helped me understand:

• pull does not preclude push; you can have push and pull.
• wip-limits are not limited to pull systems; wip-limits would help in push systems too.

smart swarm

is an excellent book by Peter Miller (isbn 978-0-00-738297-2). As usual I'm going to quote from a few pages:

As successful foragers return to the nest with seeds, they're met at the nest entrace by foragers waiting in reserve. This contact stimulates the inactive ants to go out. Foragers normally don't come back until they find something. So the faster the foragers return, the faster other ants go out, enabling the colony to tune its work force to the probability of finding food.

Instead of attempting to outsmart the desert environment, the ants, in a sense, were matching its complexity with their own.

Instead of trying to keep fine-tuning a system so it will work better and better, maybe what we really ought to be looking for is a rigourous way of saying, okay, that's good enough. [Deborah Gordon]

If a scout bee was impressed by another scout's dance, she might fly to the box being advertised and conduct her own inspection, which could last as long as an hour. But she would never blindly follow another scout's opinion by dancing for a site she hadn't visited.

J. Scott Turner considers the mound's function as a respiratory system so essential that the termites couldn't live without it. In a sense, he argues, the mound is almost a living part of the colony.

If individuals in a group are prompted to make small changes to a shared structure that inspires others to improve it even further, the structure becomes an active player in the creative process.

Unlike our systems, which are tuned for efficiency, the termites' systems have been tuned for robustness, which they demonstrate by building mounds that are constantly self-healing.

What really made the lights go on was the realization that termites don't pay attention to the environment itself but to changes in the environment.

Not only does this complicated structure represent an indirect collaboration among millions of individuals, it also embodies a kind of ongoing conversation between the colony and the world outside. The mound might look like a structure, but it's better thought of as a process.

We should think of it [the termite mound] as a dynamic system that balances forces both inside and outside its walls to create the right environment for the termites.

When you feel like you belong to something, it gives you so much more freedom and so much more energy that might otherwise be used up in anxiety, to do other things.

On January 12, 2006, several hundred thousand pilgrims had gathered in a dusty tent city at Mina, three miles east of Mecca...
By noon... about a half-million or more pilgrims filled the Jamarat plaza in front of the bridge... The pressure inside the crowd was crushing... More than an hour later, victims were piled up seven layers deep: 363 men and women were dead.
"Those in charge need to remember the root cause of the problem: too many people trying to get through too small a space. The ingress rate at the bridge was 135,000 per hour. The thoughput rate of the pillars was only 100,000 an hour. You can't put a pint into a half-pint jug." [Keith Still]

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.

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.

The principles of product development flow

is an excellent book by Donald Reinersten (isbn 978-1-935401-00-1). As usual I'm going to quote from a few pages:

Operating a product development process near full utilisation is an economic disaster.

When we emphasise flow, we focus on queues rather than timelines.

Almost any specialist can become a queue.

We grow queues much faster than we can shrink them.

When queues are large, it is very hard to create urgency.

Queues amplify variability. Moving from 75 to 95% utilisation increases variability by 25 times.

Sequential phase-gate processes have inherently large batch transfers.

Large batches encourage even larger batches.

Reducing batch size is usually the single most effective way to reduce queues.

Companies inevitably feel they can computerise this whiteboard, however, they almost always create a more elegant but less useful system.

The speed of feedback is at least two orders of magnitude more important to product developers than manufacturers.

The human effect of fast feedback loops are regenerative. Fast feedback gives people a sense of control; they use it, see results, and this further reinforces their sense of control.

Homeostasis is the tendency of a system to maintain its current state.

In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.

Opportunities get smaller with time, and obstacles get larger.

The scarcest resource is always time.

To align behaviours reward people for the work of others.

It has been said that one barbarian could defeat one Roman soldier in combat, but that 1,000 Roman soldiers could always defeat 1,000 barbarians.

The Marines, and all other elite organisations, maintain continuity in their organisational units.

Curry velocity

Some people's introduction to curry begins with them ordering the hottest dish on the menu. They discover the dish is beyond their curry-capacity and they can't finish it. Amazingly, they often repeat this behaviour. Lots of curry goes to waste. Dishes are frequently only half-eaten. Curry velocity remains at zero.

Other people's introduction to curry begins with them trying something nearer the cooler end of the Scoville scale. They find the dish is below their curry-capacity. They finish it! No curry is wasted. Their curry velocity is above zero. The next time they may decide to try something a little hotter. But they are in control of the curry, rather than the curry being in control of them.

Out of the crisis

is an excellent book by W. Edwards Deming (isbn 0-911379-01-0). As usual I'm going to quote from a few pages:

All industries, manufacturing and service, are subject to the same principles of management.

Quality comes not from inspection, but from improvement of the production process.

Today, 19 foreman out of 20 were never on the job that they supervise.

Fear amongst salaried workers may be attributed in large part to the annual rating of performance.

Absenteeism is largely a function of supervision. If people feel important to a job, they will come to work.

He that would run his company on visible figures alone will in time have neither company nor figures.

There has never been a definitive study of quality in the dental profession; nor is there likely to be one. Partly because they tend to work alone, dentists resist the idea of being evaluated, or even observed, by others.

Where there is fear, there will be wrong figures.

It is well known that rework piles up: no one wishes to tackle it.

This company had been sending a letter to every driver at every mistake. It made no difference whether this was the one mistake of the year for this driver, or the 15th: the letter was exactly the same. What does the driver who has received 15 warnings, all alike, think of the management?

sprints, time-boxing, and capacity

A team is doing Scrum with 3 week sprints. Suppose at the end of a sprint they've got nothing to done. What should they do? There's a strong temptation to ask for more time. To make this sprint a 4 week sprint. Most of the work in progress is 90% done, they say. Another week and things will have got to done, they say. It seems reasonable.

Trying to run systems beyond their capacity is not a good idea. In this situation Scrum's fixed-duration time-box constraint has served it's purpose admirably. The problem is not the choice of 3 weeks. Changing 3 weeks into 4 weeks is not addressing the problem. The problem is the team planned to pull in an amount of work and get it to done in 3 weeks. But they're not yet in control of their process - they don't know what their capacity is. They pulled in more than 3 weeks worth of work. Probably a lot more. But we just don't know!

In The Toyota Way, Jeffrey Liker writes:

Taiichi Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes.

Advice from a genius with a lifetime's experience. Toyota manufactures cars. It makes cars. Its production line is an actual line. If manufacturers are prone to overproduction imagine how much more prone software developers are! The things we make are not even physical things. In software, things are mostly invisible. It's difficult to manage what you can't see. In Quality Software Management volume 2, First-Order Measurement, Jerry Weinberg writes:

Without visibility, control is not possible.
If you can't see, you can't steer.

Rather than asking for another week, the team should really be thinking about addressing their real problem. Their real problem is that they're pulling in too much work. They have to somehow learn to pull in less work. So they can start to be in control of their process rather than their process being in control of them.

Butter sighted at Olve's house

This is a photo of a pack of butter belonging to my good friend Olve Maudal. Olve has exactly 157 packs of butter in his house right now. All safely housed in his new super-sized fridge. Many of his 157 packs have been flown in specially by relatives visiting from abroad. Olve would only allow one pack out of the fridge for the photo. Even then he insisted it be taken out under the watchful eyes of the two security guards he's specially hired to guard the fridge - Lars by day and the other Lars by night. Well, you can't be too careful right now. Butter is selling for crazy money on the black (or should that be yellow) market.

Yes, it's just one small example of the butter shortage here in Norway at the moment. Apparently the cause is a new fat-rich fad-diet sweeping the population combined with the seasonal tradition of making butter-rich Xmas cookies.

Shortages like this are, as Stephen Fry might put it, quite interesting. At one point there was probably a very mild shortage. Word of the mild shortage started to spread (sorry) and anyone buying butter bought a few extra packets just to be safe. The shortage got a bit worse. Word of the worsening shortage spread further and faster. People bought even more. A self-fulfilling dynamic was thus set in place. Soon the shelves were stripped of all butter.

The shortage the customers are experiencing is, no doubt, fractally mirrored by the shops selling (or rather not selling) butter. Butter wholesalers just don't have enough butter to meet the orders from shops. Shops that get any butter get less than they ordered. Any butter the shops do get is bought in a flash (but only by relatively few people because of the bulk butter buying behaviour) and they're out of stock again. You can imagine the shop keepers pulling their hair out in exasperation. If only they could get more butter they could make a small fortune. But right when there's the most demand they have none on their shelves! They increase the size of their wholesale reorder hoping to cash in.

What will happen in a few weeks time? One possible (perhaps even likely) outcome, is that the wholesalers will finally get enough butter to meet their over-inflated orders. The shop keepers pile the butter onto their shelves and wait for the Krona to roll in... Some of the butter is sold. But not very much. After all, Xmas is now over. The fat-rich fad-diet has gone the way of all fads and the glossy magazines are now preaching a low-fat diet. And lets not forget that a fair percentage of the population has, like Olve, over 100 packets of butter in their new fridges. They're certainly not going to be buying butter any time soon.

The shop keepers then face the daunting prospect of vast butter-walls sitting unsold on their shelves, fast approaching its sell-by date. Lowering the price doesn't help. It all has to be thrown away. Again the same thing will be fractally mirrored at the smaller scale. Lots of people, such as Olve, will have more butter than they can possibly use in time. They too will have to throw out loads of butter as it goes past its use-by date.

The same lurching from one extreme to another can happen when the number of people trying to make phone calls starts to approach network capacity. People can't get through. So they try again. And when they do get through the line gets dropped. So when they do get through they stay on a bit longer. It happens on roads too.

It's dangerous to run systems at full capacity. They reach a tipping point and topple into a death spiral. Busy work and inventory pile up. That causes even more busy work and even more inventory. But almost no butter is being bought or sold. There is no flow.