Over the past year, there has been a growing interest in the application of Kanban practices, often as an extension of Scrum, by experienced Scrum practioners. At the same time, there is a segment of Scrum practioners who are vehemently anti-Kanban (although it often seems that they have misunderstand what Kanban is).

For those new to the concept, the best resources on this subject are probably this blog post, "Kanban over-simplified"

http://agileproductde...

and especially this newly-published book (which can be downloaded in .PDF format for free), with forwards by David Anderson and Mary Poppendieck.

Kanban and Scrum - making the most of both


I'm curious to hear about group member's views on this, and in any first-hand experiences combining Scrum and Kanban.

(small snippet from another thread, "Is it possible to go agile gradually", which seems relevant here)

The value of a "locked sprint" was something I always took for granted too, until I started reading how experienced Scrum teams have been discovering they no longer needed them once they started tracking work in progress, by extending Scrum with Kanban. Using this technique (it seems too lightweight to call it a process or methodology), teams continue to schedule weekly or bi-weekly retrospectives to critique and refine their process, and continue to uphold all the traditional agile practice expectations of self-organizing teams, with rigorous attention to code quality etc. etc., but attempts to estimate how long work items will take in order to try to fit them to a "locked" timebox of arbitrary length gradually gives way to just tweaking the number of items permitted to be in progress at any one time, and tracking the actual average time each item took to complete.

From the product owner's perspective, rather than being expected to agree what should be done in the next two weeks (which may involve feature FRAGMENTS that are difficult for them to evaluate or even care about), they are simply restricted in the number of backlog items they can have "on deck" at any time, for the developers to work on next. Review of completed items can be scheduled separately from developer retrospectives, at points that may be "more natural" to product owners, since they involve entire features.

I found it interesting that teams reported they didn't set out to explicitly try to eliminate estimates, but that the need for them seemed to fall away naturally, as managers were satisfied to receive the information they needed in the form of actual work item "cycle time", and "process" was essentially reduced to seeking to eliminate delays in processing individual backlog items.

Of course, I haven't had the chance to try this in a production environment yet, but it sounds interesting.

This is a part of what I discuss in my talk "Maturing Through Agile: Principles over Practices", which is about how my team came to work the way it does. I'll be proposing this idea today, so if it's interesting, please vote for it!

;ted
--
Ted M. Young
Dev Mgr & Agile Coach
Guidewire Software