Here are some useful Kanban links:

__
o http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html

o http://www.infoq.com/articles/hiranabe-lean-agile-kanban

o http://www.methodsandtools.com/archive/archive.php?id=104

o http://en.wikipedia.org/wiki/Kanban_(development)
_


Kanban is an excellent corrective to some bad Agile habits, particularly in Scrum.  Kanban makes makes progress much more visible and keeps expectations realistic.  No one worries so much about sizing stories and tracking their velocities in points.  Instead, teams learn how to make stories the right size so that they move across the board in a reasonable time.  Kanban avoids over-commitments and inefficient multi-tasking.  Unbalanced staffing is more obvious.  If someone agrees to work on something new, then it is more obvious what will be sacrificed instead.

I have however seen a tendency for each column of a Kanban board to become a phase gate, with strict requirements for passing forward, never to step backward again.  This can encourage stories to be overspecified and broken into tasks too early.   Worse, tasks may be assigned to developers or testers without their prior involvement.

We do not want one or two people defining stories and assigning tasks.   I think a one-sentence "minimally marketable feature" is exactly the right detail for a story before development begins.  Extra specification can actually be counter-productive and lock in hasty decisions.  A "story" is just an agreement to talk about a particular user problem and come up with the best solution.  You will find this argument in books on Agile, XP, Scrum, and Kanban.

Developers should adopt stories and work with everyone to make sure that the story makes sense and that the solution will satisfy the entire team.   Reconciling requirements and implementations is how we come up with great solutions, and avoid brute-force ugly features.  By the time a story is finished, we should have our acceptance criteria and the rest of our paperwork, without strain.  No one should be surprised by what finally appears in the application.  It should feel elegant, obvious, and inevitable.

We want agile teams, not a queue.  We want to make sure that no one gets stuck with the same assignments over and over.  Creativity declines quickly, otherwise.   We should encourage everyone to volunteer for something different at any time, especially if someone else obviously knows more about it.  Experts need to share their knowledge.   If you find yourself the only person familiar with a particular part of the application, insist that someone else collaborate on the next story that uses it.  At least two developers should be comfortable with any new code.   Any single person will miss something obvious to anyone else in the group.

We should never implement something that seems poorly motivated just because "that is what they said they want."   The right solution may be to approach the problem differently.  That is how we make breakthroughs and game-changers.  No single person on a team can see the entire picture, and no one should try to do it alone.

Bill Harlan, December, 2012