15

In kanban, there is a hard work-in-progress limit that stops a discipline working on too much at once. In this example kanban board, the WIP limit includes work listed in the "done" column.

Why, for example, can the analysis discipline, which has concluded one of its tasks, not pull another task from the Next column and begin working on it? What if analysis completes all work but development still can't pull any? Should they stop working?

This doesn't seem like an efficient way of working. You can say, "management should make sure development aren't holding up flow", but when this occurs for the first time, management are going to ask analysis to break their WIP limit while they try to improve development, not down-tools to hold to some process ideal.

Improve this question

6 Answers 6

Reset to default
15

WIP limits are designed to show bottlenecks so management can FIX them.

If the limit is being hit in the "Done" area and the upstream guys can still keep going like nothing has happened, management might not know about it because it is no longer obvious.

The very act of "stopping work because I hit the limit" is the mechanism that triggers the notification process.

Yes, it is cumbersome. BUT it works. A lot of people don't like to talk about work flow hold ups because they think it reflects badly on them or they can't dump that "whining snitch" tag mentally, the WIP limit takes it out of their hands.

In the long run, your team relationships will be less stressed because it's no longer personal, just the stupid board. :-P

Improve this answer
5
  • I see: it's a feature, not a bug, that the analysts have stopped work, rather than the work piling up in front of the developers.
    – tenpn
    Commented Mar 16, 2012 at 12:42
  • I like your answer, but I'm definitely sure that management shouldn't fix all the bottlenecks. I would say that if the team members cannot fix a bottleneck on their own due to some external dependencies, then management should jump in and help out. It is important to avoid micro-management
    – Zsolt
    Commented Mar 16, 2012 at 13:30
  • Yep, in the case of cross functional teams, my experience is that its better to keep it in the team unless you end up with more than one bottleneck. That is typically a sign that the team can't cope. For single bottlenecks, the team leader is normally sufficiently capable of dealing with the issue unless its a numbers thing.
    – Permas
    Commented Mar 16, 2012 at 13:43
  • @tenpn, try not to think of it as "stopped work". Its more of a "I need to fix this or get someone to do it if I can't" situation. It's basically like paying a little production up front to get a smoother work flow for the rest of a looooong journey.
    – Permas
    Commented Mar 16, 2012 at 13:47
  • 1
    You should always work from anything you can do on the right of the board first. If your analysts are held up because of a bottleneck in dev, is there any QA work they can help with? Can they sit with a dev and help them hammer through an issue? Are they actually just done because they are giving crappy requirements to the devs slowing the development down! It might not be the devs fault that work is bottlenecking in their department!
    – CaffGeek
    Commented Mar 16, 2012 at 17:15
10

I was taught a great game that really stressed this concept. It's the paper airplane production game. What it brutally shows is waste when something unexpected happens.

Say you're building five airplanes for a customer. Let's look at two scenarios. In both cases you are paid as each airplane is produced. Once a plane goes to the customer you get paid for that plane.

1- You build them in the classic style. For some reason, the cockpit assembly is taking forever. You get one plane delivered and four more are done except for the cockpits. At that point the customer decides they don't really want these planes and cancels the contract. The cancellation fee doesn't even begin to cover the cost for the four partially built planes and lost man hours. Hope you can find another customer soon.

2- You build each plane under Kanban. Because of the hold up in the cockpit construction, you only have one plane in production when the customer cancels the order. The cancellation fee covers that one plane's cost and if you manage to sell the plane soon, you'll end up ahead out of the deal.

Improve this answer
1
  • +1 If I could favourite an answer I'd favourite this one. This is a really good metaphor.
    – LRE
    Commented Mar 20, 2012 at 20:09
9

It doesn't seem like an efficient way of working because we've all been trained that we should all be utilised as close to 100% of the time as possible.

In the example you give, it's not desirable for your analysis function to keep completing work over the WIP limit because you'll create a queue of work that the developers will not be able to keep up with. This queue will continue to grow and the analysis will grow stale.

Much better for the analyst to help with dev, QA, doing demos or other work that will help remove upstream blockages and get work flowing across the whole workflow, not just their slice of the process.

tl;dr WIP limits encourage optimising the system, not just a process step.

Improve this answer
6

You say this doesn't seem like an efficient way of working. Remember that kanban isn't for optimizing the work of each individual. Rather, it is for optimizing the overall throughput of the system. Sometimes that means a person needs to stop and/or help some other team rather than pull another task.

Improve this answer
5

The done column is limited, as you pointed out, so that the flow keeps flowing: colleagues shall pull from the second,third... latest done column from the right. The goal is to have a lower inventory, avoid overproduction and deliver value. Finished analysis work has no value, until it is implemented.

If the analysis discipline finishes more work than the development do then there is a problem with the organization:

  • either something is wrong with the development, or
  • the business doesn't need that much work to be done

The whole done+pull concept in Kanban comes from the Just in Time principle.

On the other hand, I'm not quite sure that management should intervene until the organization doesn't know where the problem is. Maybe the development department is slow, or they have test/environment issues, or they are simply undersized.

Improve this answer
2
  • I like the just-in-time thing. it's not valuable work if there's a chance it has to be redone or it won't be used by workers further down the stream.
    – tenpn
    Commented Mar 16, 2012 at 12:42
  • Or dev is hampered because analysis is actually just quickly completing garbage the devs can't work with.
    – CaffGeek
    Commented Mar 16, 2012 at 17:17
4

In addition to the other great answers here, I would like to add that analysis can not be done to far ahead of time. (Alltough the limit of 2 and 3 seems a bit low)

If that were the case, the project would be more like waterfall and less agile. Waterfall and Kanban do not get along very well.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.