Kanban as Alternative Agile Implementation

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”.

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.”

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.

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.

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.

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.

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.

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.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.