What I was reading this morning . . . Kanban

We were using this back in the 90’s to build airplanes; it’s now been pushed into the realm of Agile software development.  Kanban means literally ‘billboard’.  In manufacturing, each part has a Kanban card and the work stations pull parts into the work process.  Output has a card and is queued up for the next work station.  When cards run low, you order more parts.

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

Summary:
1) Visualize what you do – make it public –  use Kanban cards, boards etc.
2) Limit what you’re working on at one time.  Less process switching creates less ‘thrashing’
3) Manage workflow through the system.  Lower WIP levels allows bottlenecks to be found.
4) Explicit and concrete policies.  You can’t improve if you don’t have clear documentation.
5) Continuous feedback throughout the process.
6) Collaborative improvement based on data and scientific testing. Small, continuous improvement, not top-down sweeping change.

For development, you let the executing teams pull cards from the work backlog, work on them without interruption, then move the card to the next lane - from design, development, testing and more.  As you see cards stacking up you can identify backlogs; visualization helps make it happen.  Very compatible with Agile development and can be used even in oldschool waterfall development.

More detailed background:
http://www.infoq.com/articles/hiranabe-lean-agile-kanban 

Further reading – SCRUM vs Kanban :
http://www.agileconnection.com/article/what-best-scrum-or-kanban 

Examples of Kanban boards in Development:
http://www.infoq.com/articles/agile-kanban-boards

Even more reading:
http://www.methodsandtools.com/archive/archive.php?id=104

Fascinating stuff, really…