InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Kanban as Alternative Agile Implementation

Posted by Mark Levison on Oct 23, 2008

Sections
Process & Practices,
Architecture & Design
Topics
Agile Techniques ,
Agile ,
Methodologies
Tags
Lean ,
Kaizen ,
Kanban

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

10 comments

Watch Thread Reply

A word of caution by Mark Levison Posted
Further Links by Karl Scotland 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
  1. Back to top

    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.

  2. Back to top

    Further Links

    by Karl Scotland

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

  3. Back to top

    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

  4. Back to top

    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?

  5. Back to top

    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/

  6. Back to top

    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.

  7. Back to top

    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.

  8. Back to top

    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.

  9. Back to top

    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.

  10. Back to top

    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.

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.