Some kanban resources:

• Kanban vs. Scrum: http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf. For the basics, read the “Kanban in a nutshell” section on page 3 and the “Summary of Scrum vs Kanban” section on page 25. 
• Kanban software development resources: http://availagility.wordpress.com/kanban/
• Kanban, Flow and Cadence: http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence. “Very simply, there is a queue of work, which goes through a number of stages of development until [it’s] done.  When work is completed in a stage, it goes into a downstream queue for the next stage.  When someone needs new work to do, they pull it from their upstream queue….Queue limits are designed to avoid premature work…..Work In Progress limits are designed to reduce multi-tasking, [maximize] throughput, and enhance teamwork.”
• Scrum-ban: http://leansoftwareengineering.com/ksse/scrum-ban/. “…a kanban serves two functions: it is a request to do something in particular, but it is also permission to do something in general….One simple technique that brings us much closer to our kanban definition is to set a multitasking limit for individuals….Another common technique is the late binding of tasks to owners….Another enhancement we can make…is to add a ready queue between the backlog and work-in-process….”
• Introducing Kanban Boards and Pipelines: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/08/kanban-in-software-development-part-1-introducing-kanban-boards-and-pipelines.aspx. “[we can create] a pipeline for how our development process works. The work that is done flows through that pipeline based on how often the customer wants to pull features out. As one feature exits the pipeline, another feature can be added into the pipeline.”
• Completing the Kanban Board with Queues, Order Points and Limits: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/08/kanban-in-software-development-part-2-completing-the-kanban-board-with-queues-order-points-and-limits.aspx. “To create a more complete kanban board…we need to allow for a fully functional team - developers, analysts, testers, technical writers, and others. We also need to allow the different team members to work on different parts of the system, as work is needed. The end goal is to enable the system to flow through the process and to ensure the work is ‘done done’ before it goes to the customers….We can account for the team makeup and the potential bottlenecks by introducing the concept of order points and limits…and by creating queues and multiple pipelines to be worked.”
• A Variation on Queues - Pipelines for WIP and Done: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/15/kanban-in-software-development-part-2-5-a-variation-on-queues-pipelines-for-wip-and-done.aspx. “[How would anyone] know when work in one column is done and ready to be pulled into the next column[?]…To facilitate the visualization of the difference between work in progress and work that is ready to be pulled to the next column, we can use the concept of a pipeline and split our existing queues into a [Work in Progress] WIP and Done step….[But not] every queue needs to be a pipeline.”
• Handling Bugs and Emergency Fixes in Kanban: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/19/kanban-in-software-development-part-3-andon-and-jidoka-handling-bugs-and-emergency-fixes-in-kanban.aspx. “[For bugs and fixes, you can engage in] creating an Emergency Fixes pipeline, tacking a smaller bug notice onto an existing card, [or] putting a Bug card in the backlog.”