So imagine this scenario:

There is only 1 developer, who also is the bottleneck (testers, etc are busy on other contracts). There is a nontrivial backlog of tickets, most of which are blocked for not being reproducible, unintelligible requirements, unsolvable (with current ideas, staff and technologies).

Is there any particular benefit to creating a system that parcels out the tickets to the sole developer one or two at a time? The system so far has immediately created slack on account of delays in assigning new tickets after current tickets are worked. When blocked tickets are assigned, they now sit on the developer's desk blocked until they are moved back to unassigned tickets.

Are there any benefits to this "artificial low-WIP" system and how could/should it have been implemented?

  • 1
    I dont understand the question. The developer can surely only work on one thing at a time? – Dave Hillier Jun 23 '14 at 15:42
  • I guess the main difference is that when you get to the end of a ticket, you're blocked waiting for a ticket to be assigned. And if one just picks a new ticket automatically, then the whole process is a farce since the tickets might as well all be assigned to the sole developer. – MatthewMartin Jun 23 '14 at 15:45
  • "Assigned to" and "in progress" should be different states, no? This doesn't seem like a real kanban problem, just one with your ticketing system. – Dave Hillier Jun 23 '14 at 15:48
  • Not really-- tickets are essentially done/not done. Backlog items are either assigned to the sole developer, or the PM (who isn't actively doing anything with the ticket) – MatthewMartin Jun 23 '14 at 15:51
  • The question occurred to me while reading a book on Kanban. I wouldn't accuse this process system I'm describing of being a Kanban system. – MatthewMartin Jun 23 '14 at 15:52

The idea behind limiting the WIP count in kanban is to provide everyone the opportunity to properly focus on the few items assigned to them and to progress those items to the next stage as efficiently as possible.

The problem with just piling all the work on that one developer is that the typical reactions are

  • Try to work on "everything" at the same time, thereby losing efficiency in the context switches between issues
  • Becoming overwhelmed by the amount of work and losing focus as a result of that.

Both have the end result that the developer becomes more of a bottleneck.

The biggest flaw in your implementation is that "unworkable" items get assigned to the developer, who then spends valuable time investigating the issue, only to come to the conclusion that he still doesn't understand it or can't do anything about it.

The biggest improvements can be made by ensuring that blocked issues don't get assigned to the developer.

  • Issues that can't be solved within the current system constraints should either be closed as "Won't Fix", or should be put in a special 'Hold' status.
  • Unclear issues/requirements should be assigned to the originator (or someone who can act on behalf of the originator) for clarification. It is the responsibility of everybody involved to avoid that these issues start bouncing back-and-forth.
  • Issues that can't be reproduced should be assigned to a tester for reproduction and a description on how to reproduce. If it is really a one-off, it should be prioritized accordingly.

The system should allow some level of cherry-picking for the developer in the issues he wants to take up. After working on some very hard issues, it is nice to get rid of some low hanging fruit to get the backlog down a bit and give your brain a bit of rest at the same time.

| improve this answer | |

It would look to me that you want to implement a Pull mechanism - so that the developer self-assigns new unblocked tickets to himself/ herself as soon as he is done with the ones he is working on, instead of someone else assigning tickets to him. That way, he remains occupied and focuses on finishing what he started and taking up new work when he is ready for it.

Also, if something he is working on needs to blocked for any of the reasons you mentioned, he should block it so that it is visible to him as well as to others in the team - so they can all pitch in to help resolve the block and help close the ticket successfully. They should ideally not be moved back to backlog (unassigned status) since there must have been good reason to pick it up in the first place. Only in exceptional cases should blocked tickets be moved back to backlog.

A formal WIP limit ensures that in-process tickets (including blocked ones) get dealt BEFORE others get taken up - and over a period of time, ensures that work flows from Backlog to Completion, instead of remaining in the system for prolonged periods of time.

| improve this answer | |

Real Kanban - as practiced outside the software industry - doesn't have this problem. Kanban in the software world is largely a "push" system, exactly contrary to Ohno's original model.

In proper Kanban, the developer can't start another ticket because the quota of untested fixes downstream from them is too high. That calls attention to a need for more testers, more efficient testing, or some other improvement in the testing process. Unless the reason fixes aren't being tested is that the testers are blocked by their downstream consumer. And so on. That is one of the key ideas of Kanban - that waste built into the process becomes obvious and can be fixed.

| improve this answer | |

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