Professional Programmer Notes

or just call this my soapbox

What I learned about Kanban from Linda Cook

with 3 comments

Last night, Jan. 13, 2009, Linda Cook visited the Agile RTP user group and did a presentation on Kanban. I was an attendee.

Linda Cook’s presentation was my formal introduction to Kanban, as well as one of the few presentations that featured Lean principles.  So, here is what I learned:

Kanban is a Japanese word meaning sign board or billboard.  It describes a signaling system to trigger action.  And, it describes a “pull” system where workers/employees pull work from the system, as opposed to work being assigned to a worker.

Work in managed in queues.  Once queue management is optimized, a Kanban team will improve incrementally.

Kanban does not require:

  • big upfront planning
  • estimates
  • fixed cycles (iterations)
  • a dedicated team (team members can use part of their time for Kanban projects)

Linda mentioned the “Train Station Model” that one of her teams employed.  It is the idea that code is waiting at the station to be deployed.

Challenges & Criticism

  • Kanban is sort of like Waterfall
  • It is difficult to determine when to do a retrospective in an iteration-less workflow
  • How do you focus on small changes when the team wants a whole new system
  • There are limited tools available to support Kanban

Flow rate = the average time it takes for a task to go from creation to completion.  Flow rate can help determine estimates of future work.  *I wonder if this can lead to dynamic estimates?  As flow rate changes, projections on future work should change also.

Tools and supplies

For one of Linda’s teams, she used the following tools to manage the Kanban process:

  • A Whiteboard
  • Stickies, three colors (Yellow to record tasks, Pink to record problems, and Green to record acceptance criteria)
  • Marker pens
  • A rubber date stamp (to stamp the “born-on-date” on the stickies)

In practice, she suggests the following:

  • Measure flow rate constantly
  • Graph your flow rate
  • Planning is ad hoc and should not require a meeting
  • Plan constantly
  • Allow stories to be added when they are discovered
  • Don’t allow changes to anything that is in the Work-In-Progress queue
  • Per task, only use the necessary people for the task to plan

General Kanban process

  • All tasks are stored in a “pool”
  • The Business moves items from the pool into the Backlog queue
  • Workers/Employees move items from the Backlog queue to the Work-In-Progress queue (someone suggested using a Specify queue between the Backlog and WIP queue for task-specific requirements gathering)
  • After WIP, the tasks are moved to a Testing queue
  • From Testing, the tasks move to Done
Advertisements

Written by curtismitchell

January 14, 2009 at 10:13 am

Posted in Agile

Tagged with , , ,

3 Responses

Subscribe to comments with RSS.

  1. Interesting idea. I had heard of the name, but not much more than that. Thanks for the summary.

    Eric Davis

    January 14, 2009 at 7:48 pm

  2. Response to some of the listed challenges:
    * It is difficult to determine when to do a retrospective in an iteration-less workflow

    There are no retrospectives from what I read about it.

    * How do you focus on small changes when the team wants a whole new system

    Via the XP-like Feature-Story-Task breakdown. See:
    http://www.infoq.com/news/2007/08/agile-kanban-boards

    * There are limited tools available to support Kanban

    Dry-erase board, post-its, and markers can be found at many stores and online. 🙂

    Anonymous

    January 15, 2009 at 9:54 am

  3. One other response to the listed challenges:
    * I wonder if this can lead to dynamic estimates? As flow rate changes, projections on future work should change also.

    Not exactly. If you graph your flow rate you may see trends that would affect estimates. For example, the flow on average for the past 5 years could have been 10 tasks/month, but when a developer leaves and is replaced the flow could change as the new developer learns and the team adjusts (or doesn’t). Outside factors like changes to the work environment or to the customer or to the work required in-general could change the flow rate. Basically, if you look at the graph, you could see trends. However, since all sticky notes on the board are the same size, there is really no estimation, outside of the grouping that can be done if desired into features/stories/tasks. Managers can start at the graphs and probably get some info out of them, but I don’t think it would be a simple calculation to determine a rate that could be used for future estimates easily.

    Anonymous

    January 16, 2009 at 12:20 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: