Kanban as Alternative Agile Implementation

by Mark Levison on Oct 23, 2008 |

Kanban systems for software, derived from the Toyota Production System, are an iterationless approach for scheduling work. Instead of using a time boxed iteration and planning meeting, the pulls stories from the backlog only when it has completed its previous work.

According to Dave Nicolette, an Agile coach with Valtech: “Some in the agile community seem to be turning into shadetree handymen. They've got a single model for agile work that they apply to every situation. When all you've got is duct tape, everything looks like a duct.” He thinks that its important to expand our repertoire beyond the basics of Scrum/XP and become familiar with other tools like Kanban.

There are variety of approaches to implementing Kanban in software development teams. James Shore, author of The Art of Agile Development, writes about one: “The team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time.” According to James there several key elements in to making a Kanban system work:

Minimally Marketable Features (MMF): An MMF is the smallest feature that has value to the market. MMF’s are maintained in queue (much like the Scrum Product Backlog), but with a strict limit to the size of queue (James prefers two to three, Arlo seven).
Work In Progress: The team works on the most important item until its completed. They only work one item at a time, breaking it down into many small discrete tasks.
Estimation: Instead of using formal planning and estimation its assumed that MMF’s all have approximately the same size. By tracking the average time to complete a feature it is possible to come up with an good idea of the waiting time for each item in the queue.
Urgent Items: Occasionally emergency work crops up. A single slot is kept for emergency work – this slot bypasses the backlog and the team works to complete the work as quickly as possible. If additional urgent work appears it goes through the regular backlog.
Bugs – are fixed immediately if the feature is in progress. Otherwise they’re placed in the backlog.

David Anderson, author of Agile Management and Kanban proponent, says that his recipe for success is: “Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize”.

Corey Ladas answers the question of Why Pull? Why Kanban? by saying:

People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy. … I think kanban solves this problem more efficiently than the known alternatives.

David Laribee, introduced Kanban at his former employer Xclaim because, after two years of using XP he was having trouble surfacing the impediments and problems. In addition he felt that was a lot of waste involving over processing in the planning, retrospectives and demos. He feels in the end every good agile team will derive its own process: “Of course we can't get there from day one. We need to setup a good baseline with the practices we know have broad applicability, acceptance, and tolerance: TDD, rolling wave planning, etc. Good Agile teams, however, continually adjust their process to fit their product and the needs of their customers.”

Kanban discussion happens on the Kanban mailing list.

Previously on InfoQ on Kanban: Future Directions for Agile, Visualizing Agile Projects using Kanban Boards, Scrum-ban Paper Adds Kanban to Scrum

Related Editorial

Infographic: Just How Big is the Nerd Economy

Five Key Practices to Agile ALM

Application Performance Management Buyer's Guide

Agile Maturity Model Applied to Building and Releasing Software

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

A word of caution by Mark Levison Posted

Further Links by Karl Scotland Posted

Re: Further Links by Justyna Laskowska Posted

Just like chief programmers do in Feature-Driven Development... by Stephen Palmer Posted

Re: Just like chief programmers do in Feature-Driven Development... by Mark Levison Posted

Limiting flight flow is important... by Kevin E. Schlabach Posted

Re: Limiting flight flow is important... by Mark Levison Posted

Kanban is already part of Scrum/XP etc by Paul Beckford Posted

Check Wikipedia by Paul Beckford Posted

Re: Check Wikipedia by Karl Scotland Posted

An interesting discussion of Kanban, but... by Andrew Walker Posted

A word of caution by Mark Levison

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.

Further Links by Karl Scotland

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

Just like chief programmers do in Feature-Driven Development... by Stephen Palmer

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

Re: Just like chief programmers do in Feature-Driven Development... by Mark Levison

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

Limiting flight flow is important... by Kevin E. Schlabach

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/

Re: Limiting flight flow is important... by Mark Levison

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.

Kanban is already part of Scrum/XP etc by Paul Beckford

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.

Check Wikipedia by Paul Beckford

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.

Re: Check Wikipedia by Karl Scotland

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

An interesting discussion of Kanban, but... by Andrew Walker

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.

Re: Further Links by Justyna Laskowska

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