Kanban as a Software Development Process in Practice

Question

Has anyone used the kanban method for software development management?

I am evaluating kanban as a technique and would be curious to hear from anyone who has actually applied it in practice as to how effective it is. I've seen questions like: is-anyone-using-kanban, kanban-vs-scrum, and apply-kanban-in-an-agile-team but they don't address my concerns.

What I'm interested in specifically is:

1. Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?
2. Is it easy to execute in practice, or does it have logistical challenges that you need to manage?
3. Does it scale well to project teams with many parallel streams of work and many developers?
4. How does it compare to critical path analysis (as implemented in MS Project), how is it different?
5. What other benefits can be gained from applying kanban?

Thanks.

Answer 1

I don't have specific experience with using Kanban in software but I am familiar with the practice from a manufacturing point of view, so I was curious as to the implementation. Reading your link, the thing that struck me as a possible hitch is what felt like an underlying assumption about the same-sized ness of the units of work (features, stories, whatever). While keeping things "story sized" is a good goal, there are often mixes of bigger and little stories floating around, and the small number constraints in their pipeline therefore seem artificial. If the goal is to highlight bottlenecks, I would think that stand ups and sprint planning and retrospectives will do that well enough. If the goal is to facilitate prioritization, I think that putting constraints on numbers of tasks by types wouldn't do that as well as simply ordering them top to bottom.

I guess I don't really see what value its adding; that being said, I don't see the harm in trying it and adopting whatever pieces work.

Answer 2

I also don't have a lot of experience with it, but I think I can offer some insight. 1 & 4: the main difference between Kanban boards and other techniques, like CPM, is that a Kanban board, in a correct implementation, forces you to impose work-in-progress limits. This creates a pull system, since new items are accepted by workers only when they have capacity. This differs from an MS project type project where tasks are assigned to workers before-hand (i.e. pushed).

It is much easier to identify a bottleneck in a pull system, because work items will be queuing up at some stage in the process. In a push system, work is pushed through the system (whether it is 'done done' or not), so its difficult to find bottlenecks.

Another advantage of a pull system is you can start to base work timelines on actual results (lead and cycle time), as opposed to prediction. Yes, the size and granularity of stories does affect this, but with techniques such as cumulative flow diagrams this becomes less important.

2: Most implementations are pretty simple, and therein lies some of the strength of the technique. I think if you're having problems with the logistics of the technique, you're doing it wrong. Have a look here for a nice 'kickstart example'.

Answer 3

http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-3