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.
News
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
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
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Five Key Practices to Agile ALM
18 agile and lean practices for effective software development governance
Case Study: IBM's Agile Transformation
Agility at scale, become as agile as you can be
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
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
-
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.
10 comments
Watch Thread Reply