Software Quality Insights

Jun 7 2010   3:36PM GMT

Exploring Kanban, agile development’s new rising star

Yvette Francino Yvette Francino Profile: Yvette Francino

Tags:

I’ve heard a lot of buzz about Kanban, a concept related to lean, recently.  At the agile ALM conference I attended last month there was a lot of talk about lean methodologies, and Kanban has been a heavily-discussed topic at the last three Boulder Agile Software User Group (BASUG) meetings I’ve attended. So, what’s the dish on this newly-popular approach?

Jim Reed, organizer and leader of the BASUG, shed light on Kanban terminology and concepts in an in-depth presentation during a recent BASUG meeting.

Kanban is a concept related to lean methodologies which originated in manufacturing. However, these concepts are being applied more and more in software development environments. Kanban is a Japanese word meaning “signboard.”  A Kanban Board is a visual display in which the movement of objects, in the case of a development project, user story cards, will trigger action. The idea is that there’s continuous flow as the objects are moved across the board to completion.

Kanban is considered an agile methodology, though more adaptive than most. In other words, there aren’t a lot of rules. A slide from the presentation  showed the differences in agile methodologies. Rational Unified Process (RUP), with over 120 rules, was considered the most prescriptive. XP followed with 13 rules. Scrum was next on the adaptive scale with nine rules. Kanban was considered the most adaptive with only three rules:

  • Visualize the Workflow
  • Limit Work-in-Progress (WIP)
  • Measure and Optimize Lead Time

Reed described an example of a development project in which the Kanban board was split into the following groupings:

  • Backlog
  • Selected
  • Develop
  • Deploy
  • Live!

The Backlog holds all the stories, but these are prioritized and moved first into the Selected bucket which triggers action. If the Work in Progress (WIP) Limit is set to two, then there should be no more than two stories in any of the groups in which work is being done.  If a bottleneck occurs in one of the groups, then process rework should be done to alleviate that bottleneck rather than continuing work in earlier phases. This helps to identify bottlenecks and leads to optimization of the whole value chain.

Todd Sheridan from Rally Software, now immersed as a “Scrum Master” at Rally using Kanban,  was a voice of experience at the meeting,   I asked if his group was mixing Scrum and Kanban, and he said they were using pure Kanban, but that many of the concepts and roles from Scrum carried over. He is acting in the same capacity as a Scrum Master; since there is not a defined role or term in Kanban, they continue to use that term to describe the team facilitator.

Here’s how Sheridan explains the meaning of Kanban:

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: