Kanban as Alternative Agile Implementation

Although I'm fan of Kanban and am in fact using a Kanban board to manage house hold tasks. I would caution people not to transition if they're are experiencing problems with the traditional agile methods. On a newsgroup recently one poster cited a number of problems with their team. Kanban might help address one or two of those problems, but not others. I would only consider switching over when I had enough agile experience to feel my returns were diminishing.



In addition unlike David Laribee I think that most teams still need regular retrospectives to help them focus on improvement. I've yet to meet a team that was ready to drop them. Perhaps this is a reflection of my coaching abilities.

I have collected further Kanban links to various articles and blogs at availagility.wordpress.com/kanban

The above sounds very similar to what you end up with in Jeff De Luca's FDD if the team is too small to have more than one chief programmer. Not surprising, I guess, when David Anderson was the ui designer on the first FDD project in Singapore in 1997/8.

See FDD Community Site and My FDD intro

Stephen - I only know FDD a little bit. Would you help make the linkage a little more clear?

I found the James Shore article to be one of the first good overviews of Kanban. Prior to that, I'd only found bits and pieces (apologies to Kenji Hiranabe for missing his sessions in Toronto).

The attribute of Kanban boards I like the most is the limitation to how many items can be in flight at once. I'm trying to slowly transition my company to agile (stealth transition) and I find this limitation important when your company is afflicted with doing to many things in parallel. By limiting to 5 major projects/stories in parallel, it forces the team to focus and calls attention directly to those items. It was hard for my CEO to name ONLY 5 things, but it is already helping.

Kevin E. Schlabach
agile-commentary.blogspot.com/

I think the other key attribute is limiting the size of the backlog. Essential you're saying we can only get this much done in the next four weeks (or whatever your size). Do hard work further ahead than that is waste. It really forces people to clarify their priorities.

As I understand it, Kanban is the process of workers pulling work from a queue of ready work items. With Scrum/XP that is exactly what you are doing when you pull the highest priority story off the story board. Perhaps this article is referring to Kanban as used at Toyota for Motor vehicle manufacture, but that is not the only way Kanban can be used. Any system where workers pull work from a queue at their own pace is a Kanban system as I understand it. This has nothing to do with whether you choose to punctuate your work with time boxed iterations or not.

Skimmed Jims article and read this:

en.wikipedia.org/wiki/Kanban

It confirmed what I thought. A Kanban itself is a token used as a signal. When The queue from where work is being pulled as reached a certain threshold then the token is used to signal to the upstream process that more work items are needed. Kanban is a means of creating a demand driven process based on customer "pull", with minimal inventory and work in progress.

I fail to see what this has to do with iterations. As I understand it iterations are a means of punctuating the work and creating opportunities to inspect and adapt. I respect Jim Shore and perhaps it just comes down to terminology, but Kanban as defined in wikipedia is more widely applicable then suggested in this article.

Paul - you are correct. Kanban has nothing to do with iterations, other than it allows work to be scheduled without iterations.

To me, it seems to be a narrow focus on a decision making process that should come naturally when practiced as a part most of the practical agile 'methods'. Having said that, the focus of agile is to get people to accept and internalize the values and principles, then as a starting point use the suggested practices. Of course, great developers have known what good values and principles are since the beginning of software development, but many do not and agile attempts to make them more explicit.

Whether or not you choose to use multiple iterations or one long iteration with multiple produce release phases is up to you and what works for you. Similarly, what or how many features to work on first is between you and your customer to decide - I don't see this as something that isn't already a free choice covered by other agile methods/techniques. They all have some useful ideas to contribute, and kanban seems to be another potentially useful tool in the box. I like to put the emphasis on thoughtful decision making, backed up by empirical feedback and experience.

More sites where you can find book reviews, lists of articles and blogs on Kanban: Limited Wip Society
Kanban Library