Esta es nuestra experiencia sobre esta metodología para la gestión de proyectos. Después de mucho buscar, documentarnos y otros sufrimientos, empezamos a utilizar KANBAN en los procesos de implantación y personalización de un nuevo CRM para nuestra empresa en septiembre del 2009.
Habitualmente utilizamos SCRUM para la gestion de proyectos técnologicos, pero entendimos que necesitabamos un sistema de gestion aún más ágil, preveiamos constantes repriorizaciones, nuevas peticiones a diario, un entorno de incertidumbre y de continua gestion del cambio (responsable).  Kanban era nuestra "Silver bullet".
Si Taichi Ohno  (el padre del Sistema de Producción "Just in Time" de Toyota) ya utilizaba este sistema, nosotros no íbamos a ser menos.
Pero, vayamos por partes (que decía Jack el Destripador)

Kanban para no Kanbianos

No vamos a repetir lo que es Kanban, solo algunas referencias a gente que ya lo ha hecho (y muy bien) para que tengamos una idea clara de porqué escogimos este sistema.

Kanban (del japonés: kanban, usualmente escrito en kanji 看板 y también en katakana カンバン, donde kan, 看 カン, significa "visual," y ban, 板 バン, significa "tarjeta" o "tablero") es un sistema de información que controla de modo armónico la fabricación de los productos necesarios en la cantidad y tiempo necesarios en cada uno de los procesos.

Wikipedia
Como definición, prefiero esta

The Kanban Method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improving the system

Wikipedia (en)

Kanban para el desarrollo de software es la reducción del número de reglas y obligaciones respecto a otras metodologías: nada de planificación de producto, nada de scrum diario, nada de retrospectivas; sólo flujo productivo, priorización y limitación del número de tareas en curso en un momento dado (WIP o Work In Progress)

Kanban vs Scrum Henrik Kniberg. Traducción Proyectalis

Un sistema visual kanban puede emplearse para facilitar información, trazar la gestión de un procedimiento, controlar su ejecución, o una combinación de ellas.

Gestión Visual Kanban Navegapolis.net

Kanban es un enfoque ágil para la gestión de proyectos, que se basa en el flujo continuo de trabajo (a diferencia del desarrollo iterativo propuesto por Scrum)
5 buenos motivos para usar Kanban

1. Poder realizar entregas en cualquier momento
2. Poder cambiar las prioridades al vuelo
3. No hay necesidad de iterar
4. No hay necesidad de estimar
5. Visualización perfecta del flujo

También hay muy buenos ejemplos de cómo hacer Kanban.

• Visualizing Agile Projects using Kanban Boards. InfoQ.com
• KANBAN 101. Presentación de Dennis Stevens
• Kanban en el día a día. Guia muy grafica dosideas.com 
• Kanban en acción. dosideas.com 
• Gestión Visual Kanban Navegapolis.net

Nuestra experiencia
Desde el primer momento, KANBAN funciono bien como gestor de tareas.
Teníamos un tablero (una pared) con la tipicas columnas de Pendiente, Desarrollo y Terminado, todas con su limite de Work In Progress ( WIP Trabajo en curso).



Realmente, no nos fue muy difícil encontrar el equilibrio necesario para marcar unos limites del WIP con el que estuviéramos cómodos y fuésemos productivos. En la columna desarrollo, comenzamos por un WIP por cada componente del equipo, y fuimos ajustandolo hasta un 1,5  por componente. En la columna Terminado, fuimos mucho más restrictivos, con la idea de enfocarnos a que si una tarea esta realizada, mejor pasarla a producción, antes de empezar otra tarea. Empezamos con un WIP de 0,5 por componente del equipo. Y así se quedo.
Las tareas las apuntamos en notas tipo post-it y las enganchamos en la columna Pendiente. Anotamos persona y fecha de petición, y cada vez que hacíamos pull (arrastramos a otra columna) apuntábamos la fecha, por ejemplo, tareaX Pendiente desde el 2/5/2011, en Desarrollo el 5/5/2011 y Terminada el 7/5/2011.
Desde el principio usamos unos códigos de colores para diferenciar las tareas por tipos. Verde=Novedad, Naranja=mejora (que no cambio;) Amarillo=Formación, Rosa=Incidencia(que no error) lo que hace que el tablero este más bonito y despues nos da información adicional (Kanban 101)


Dividimos el tablero en tres filas horizontales, para mostrar las tareas según la persona del equipo que la realizaba. En la fila superior programación, en la fila del medio soporte y en la fila inferior formación. Primero poníamos los nombres en las notas pero nos quedamos con esta segunda opción.
De esta manera tendríamos información sobre quien hace qué o la carga de trabajo de cada componente de forma visual.

Tambien heredamos o reutilizamos algunoa artefactos y roles de SCRUM.

Por ejemplo, hacemos el daily scrum meeting, donde el equipo revisa delante del tablero las tareas, se comenta lo realizado y lo pendiente.
Se hace una reunión con el Propietario de cada tarea como la del Sprint planning, donde se pregunta todo lo necesario para realizar la tarea (historia de usuario)
Hacemos retrospectivas mensuales, pero con carácter general, con el objetivo de mejorar la adaptación de la metodología.
Existe el Rol de ScrumMaster que resuelve posibles impediments y cuida de la correcta aplicación de la metodología.

Y ya esta! de una forma muy visual, podíamos ver lo que quedaba por hacer, lo que estabamos haciendo, quien lo estaba haciendo y que clase de tareas nos encargaban.
Pero claro, no existen las "Siver bullets"  ;(  Este planteamiento, mostraba perfectamente el flujo del trabajo en curso, pero pronto mostro serias limitaciones que fuimos solucionando y mejorando durante los siguientes meses. Pero esto lo ponemos como otro post, que este ya se va haciendo cansino.