¿Qué es Kanban?

Kanban es un método Lean para gestionar y mejorar el flujo de trabajo en procesos de producción, desarrollo de software y gestión de servicios. Se centra en la entrega continua sin sobrecargar al equipo de trabajo, utilizando un sistema visual para monitorear el avance de las tareas y optimizar la eficiencia organizacional.

A diferencia de otros marcos de trabajo como Scrum, Kanban no prescribe roles, eventos ni cadencias fijas. En su lugar, se basa en principios y prácticas que permiten a los equipos evolucionar gradualmente desde su forma actual de trabajo sin necesidad de una transformación radical.

El método Kanban es aplicable a cualquier tipo de trabajo de conocimiento, desde el desarrollo de software y la gestión de proyectos hasta operaciones de marketing, recursos humanos y soporte al cliente. Su flexibilidad y enfoque en la mejora continua lo convierten en una de las metodologías más adoptadas en la industria tecnológica.

Kanban en Toyota y Lean Manufacturing

Kanban fue desarrollado inicialmente en la década de 1940 por Taiichi Ohno en Toyota como parte del Toyota Production System (TPS). La palabra kanban proviene del japonés y se traduce literalmente como "tarjeta visual" o "señal". En el contexto original de manufactura, las tarjetas kanban funcionaban como señales que indicaban la necesidad de reabastecer materiales en una línea de producción.

El sistema kanban de Toyota formaba parte del enfoque Lean Manufacturing, cuyo objetivo fundamental era eliminar el desperdicio (muda), reducir la sobreproducción y optimizar los procesos de fabricación mediante un sistema de producción just-in-time.

David Anderson y el Kanban Method

La adaptación de Kanban al trabajo de conocimiento y al desarrollo de software se debe principalmente a David J. Anderson. En 2004, mientras trabajaba en Microsoft, Anderson aplicó los principios del sistema kanban de Toyota al desarrollo de software en el equipo de mantenimiento de aplicaciones de XIT Sustained Engineering.

En 2010, David Anderson publicó su libro "Kanban: Successful Evolutionary Change for Your Technology Business", que formalizó el Kanban Method como un enfoque para gestionar y mejorar servicios profesionales. Este libro estableció los principios y prácticas fundamentales que definen el método Kanban tal como lo conocemos hoy.

Anderson propuso que Kanban no fuera una metodología prescriptiva, sino un método para gestionar el cambio de forma evolutiva, partiendo del proceso actual del equipo y mejorándolo incrementalmente.

El Kanban Method se sustenta en dos conjuntos de principios: los principios de gestión del cambio y los principios de entrega de servicios.

Principios de gestión del cambio

1. Empieza con lo que haces ahora: Kanban no requiere una reestructuración radical. Se parte del proceso existente y se mejora progresivamente.
2. Acuerda perseguir la mejora a través del cambio evolutivo: los cambios deben ser incrementales y graduales, no revolucionarios.
3. Fomenta actos de liderazgo en todos los niveles: la mejora no es responsabilidad exclusiva de la dirección; todos los miembros del equipo pueden y deben contribuir.

Principios de entrega de servicios

1. Comprende y enfócate en las necesidades y expectativas del cliente: todo el trabajo debe orientarse a entregar valor al cliente.
2. Gestiona el trabajo, no a las personas: el enfoque está en optimizar el flujo de trabajo, no en controlar a los individuos.
3. Evoluciona las políticas para mejorar los resultados: las reglas del proceso deben revisarse y ajustarse regularmente.

El tablero Kanban es la herramienta central de visualización del método. Su propósito es hacer visible el trabajo, el flujo y las políticas del proceso para facilitar la comunicación, la colaboración y la toma de decisiones.

Estructura básica

Un tablero Kanban básico contiene al menos tres columnas:

• Por hacer (To Do): tareas que están en la cola de trabajo pendiente.
• En curso (In Progress / Doing): tareas que se están realizando activamente.
• Hecho (Done): tareas completadas.

Estructura avanzada

Los equipos maduros suelen utilizar tableros más detallados que reflejan su flujo de trabajo real. Un tablero avanzado de desarrollo de software podría incluir columnas como:

Columna	Descripción	Límite WIP
Backlog	Elementos priorizados pendientes de desarrollo	Sin límite
Análisis	Refinamiento y especificación del requisito	3
Desarrollo	Codificación activa	4
Revisión de código	Code review por otro desarrollador	2
Testing / QA	Pruebas funcionales y de regresión	3
Despliegue	En proceso de paso a producción	1
Done	Entregado al cliente	Sin límite

Tarjetas Kanban

Cada elemento de trabajo se representa mediante una tarjeta que contiene información relevante como:

• Título y descripción de la tarea
• Persona asignada o responsable
• Fecha de entrada al sistema (para medir el Lead Time)
• Clase de servicio o prioridad
• Bloqueos o impedimentos visibles
• Fecha de compromiso y fecha de entrega esperada

Uno de los pilares más importantes y diferenciadores de Kanban es la limitación del trabajo en curso, conocido como WIP (Work In Progress). Limitar el WIP significa establecer un número máximo de elementos que pueden estar en una fase del proceso simultáneamente.

Por qué limitar el WIP

La Ley de Little establece una relación directa entre el WIP, el throughput y el Lead Time:

Lead Time = WIP / Throughput

Esto significa que al reducir el WIP (manteniendo constante el throughput), el Lead Time disminuye. En otras palabras, cuantas menos tareas tenga un equipo en curso simultáneamente, más rápido completará cada una de ellas.

Beneficios de limitar el WIP

• Reduce el cambio de contexto: al limitar las tareas simultáneas, los miembros del equipo pueden concentrarse mejor.
• Mejora la calidad: menos multitarea implica menos errores y mayor atención al detalle.
• Aumenta la previsibilidad: los tiempos de entrega se vuelven más estables y predecibles.
• Identifica cuellos de botella: cuando una columna alcanza su límite de WIP, el trabajo se detiene y se evidencian los problemas del proceso.
• Fomenta la colaboración: los miembros del equipo ayudan a desbloquear tareas antes de empezar nuevas.

Cómo establecer límites de WIP

No existe una fórmula universal para establecer los límites de WIP óptimos. Una regla práctica común es empezar con un límite igual al número de personas del equipo menos uno, o la mitad del tamaño del equipo. Lo importante es experimentar, observar el flujo y ajustar los límites basándose en datos reales.

El sistema Pull es un principio clave de Kanban que establece que el trabajo nuevo solo se inicia cuando existe capacidad disponible. En lugar de empujar (push) trabajo hacia los equipos, son los propios equipos quienes tiran (pull) de los elementos cuando terminan una tarea y tienen espacio disponible según los límites de WIP.

El flujo de trabajo en un sistema Pull se interpreta de derecha a izquierda: antes de iniciar una nueva tarea, se busca si hay trabajo acumulado en las fases posteriores del proceso que necesita atención. Este enfoque prioriza la finalización de trabajo sobre el inicio de trabajo nuevo, lo que reduce el inventario de trabajo en curso y mejora el flujo general.

Kanban se basa en datos cuantitativos para la toma de decisiones y la mejora continua. Las métricas principales son:

Lead Time

El Lead Time mide el tiempo total desde que un elemento de trabajo entra al sistema hasta que se entrega al cliente. Es la métrica más importante desde la perspectiva del cliente, ya que refleja cuánto debe esperar desde que solicita algo hasta que lo recibe.

Cycle Time

El Cycle Time mide el tiempo que un elemento pasa en proceso activo, desde que se comienza a trabajar en él hasta que se completa. Es una métrica operativa clave para el equipo.

Throughput

El throughput es la cantidad de elementos de trabajo completados por unidad de tiempo (por ejemplo, historias por semana o tickets por día). Refleja la capacidad de entrega del equipo.

Cumulative Flow Diagram (CFD)

El CFD es un gráfico que muestra la cantidad de elementos en cada estado del flujo a lo largo del tiempo. Permite visualizar tendencias, identificar cuellos de botella y detectar acumulación de trabajo en determinadas fases.

Aging Work in Progress

Esta métrica muestra cuánto tiempo llevan los elementos de trabajo en curso. Ayuda a identificar elementos que están estancados o bloqueados y que necesitan atención inmediata.

Service Level Expectation (SLE)

El SLE define el nivel de servicio esperado, expresado como un percentil del Lead Time. Por ejemplo, "el 85% de los elementos se completarán en 10 días o menos".

Aunque Kanban no prescribe eventos obligatorios como Scrum, David Anderson definió un conjunto de cadencias (reuniones regulares) que facilitan la evolución del sistema:

Cadencias de nivel de equipo

• Kanban Meeting (diaria): reunión breve frente al tablero para revisar el flujo, identificar bloqueos y coordinar el trabajo del día. Se enfoca en el trabajo, no en las personas.
• Replenishment Meeting: reunión para seleccionar y priorizar nuevos elementos de trabajo que entrarán al sistema.
• Delivery Planning: planificación de cuándo y cómo se entregarán los elementos completados.

Cadencias de nivel organizacional

• Service Delivery Review: revisión periódica de métricas y rendimiento del servicio.
• Operations Review: análisis de la cadena de valor completa y la interacción entre servicios.
• Strategy Review: evaluación de la dirección estratégica y ajuste de objetivos.
• Risk Review: identificación y gestión de riesgos que afectan al flujo.

Kanban y Scrum son dos de los enfoques ágiles más populares, pero difieren significativamente en su filosofía y aplicación:

Aspecto	Kanban	Scrum
Cadencia	Flujo continuo, sin iteraciones fijas	Sprints de duración fija (1-4 semanas)
Roles	No prescribe roles específicos	Scrum Master, Product Owner, Developers
Cambios	Pueden incorporarse en cualquier momento	Solo al finalizar el Sprint
Planificación	Continua, basada en capacidad	Sprint Planning al inicio de cada Sprint
Métricas	Lead Time, Cycle Time, Throughput	Velocidad, Burndown
WIP	Límites explícitos por columna	Limitado por el Sprint Backlog
Estimación	No es obligatoria	Story Points o similar
Tablero	Persistente, flujo continuo	Se reinicia cada Sprint
Enfoque del cambio	Evolutivo e incremental	Requiere adopción del framework completo

Cuándo usar Kanban vs Scrum

Kanban es ideal cuando:

• El trabajo es impredecible o no puede planificarse en sprints (soporte, mantenimiento, operaciones).
• Se necesita flexibilidad para cambiar prioridades frecuentemente.
• El equipo ya tiene un proceso establecido y quiere mejorarlo gradualmente.
• Se busca optimizar el flujo y reducir tiempos de entrega.

Scrum es ideal cuando:

• Se desarrollan productos nuevos con requisitos que pueden organizarse en incrementos.
• El equipo necesita estructura y cadencia regular.
• Se requiere un marco completo con roles y responsabilidades claras.
• La previsibilidad a corto plazo es importante para la planificación.

Scrumban

Muchos equipos combinan elementos de ambos enfoques en lo que se conoce como Scrumban: utilizan los roles y eventos de Scrum junto con las prácticas de visualización y límites de WIP de Kanban.

Las clases de servicio son políticas que determinan cómo se priorizan y tratan diferentes tipos de trabajo. Las cuatro clases de servicio estándar en Kanban son:

1. Expedite: trabajo urgente que necesita atención inmediata (bugs críticos en producción, incidencias de seguridad). Tiene su propio carril y puede romper los límites de WIP.
2. Fixed Date: trabajo con una fecha de entrega inamovible (requisitos regulatorios, lanzamientos de mercado coordinados).
3. Standard: la mayoría del trabajo regular que se gestiona según el orden de prioridad habitual.
4. Intangible: trabajo importante a largo plazo pero sin urgencia inmediata (reducción de deuda técnica, mejoras de infraestructura).

Las herramientas digitales más utilizadas para implementar Kanban incluyen:

Jira

Jira de Atlassian es la herramienta de gestión de proyectos más utilizada en la industria del software. Ofrece tableros Kanban configurables con límites de WIP, informes de métricas (CFD, control charts), integración con flujos de desarrollo y capacidades avanzadas de filtrado y automatización.

Trello

Trello es una herramienta visual basada en tableros que destaca por su simplicidad. Es ideal para equipos pequeños o proyectos con flujos de trabajo sencillos. Ofrece tarjetas arrastrables, listas personalizables y múltiples integraciones con otras herramientas.

Asana

Asana proporciona vistas de tablero Kanban junto con otras vistas como líneas de tiempo, listas y calendarios. Es especialmente útil para equipos que necesitan gestionar proyectos complejos con dependencias y objetivos.

Azure DevOps

Azure DevOps de Microsoft incluye tableros Kanban nativos con límites de WIP, carriles (swim lanes), estilos de tarjeta personalizables y métricas integradas como CFD y Lead Time.

Otras herramientas

Existen también herramientas especializadas como Kanbanize (ahora Businessmap), SwiftKanban y LeanKit, diseñadas específicamente para implementar el método Kanban con todas sus prácticas y métricas.

Para implementar Kanban en un equipo o servicio, se recomienda seguir estos pasos:

1. Visualizar el flujo de trabajo actual: mapear las fases reales del proceso, desde la solicitud hasta la entrega, y crear un tablero que las refleje.
2. Hacer explícitas las políticas: definir y documentar las reglas del proceso, como los criterios para mover una tarjeta de una columna a otra.
3. Establecer límites de WIP iniciales: comenzar con límites conservadores y ajustarlos basándose en la observación.
4. Medir el flujo: comenzar a recopilar datos de Lead Time, Cycle Time y Throughput desde el primer día.
5. Gestionar el flujo activamente: utilizar las reuniones diarias frente al tablero para identificar y resolver bloqueos.
6. Implementar bucles de retroalimentación: establecer las cadencias necesarias para revisar y mejorar el proceso.
7. Evolucionar experimentalmente: aplicar la filosofía Kaizen de mejora continua, realizando cambios pequeños y midiendo su impacto.

Kanban promueve la filosofía Kaizen, que enfatiza la mejora continua mediante cambios pequeños e incrementales. El ciclo de mejora en Kanban sigue estos pasos:

1. Observar: analizar las métricas y el flujo de trabajo para identificar problemas o áreas de mejora.
2. Hipótesis: formular una hipótesis sobre qué cambio podría mejorar el flujo.
3. Experimentar: implementar el cambio de forma controlada.
4. Medir: recopilar datos sobre el impacto del cambio.
5. Adaptar: decidir si mantener, ajustar o revertir el cambio basándose en los resultados.

¿Qué significa la palabra Kanban?

Kanban es una palabra japonesa que se traduce como "tarjeta visual" o "señal". En el contexto original de manufactura en Toyota, las tarjetas kanban funcionaban como señales físicas que indicaban la necesidad de reabastecer materiales o iniciar la producción de un componente.

¿Es Kanban una metodología ágil?

Técnicamente, Kanban se define como un método, no como una metodología ni un framework. A diferencia de Scrum, no prescribe roles, eventos obligatorios ni artefactos fijos. Sin embargo, es compatible con los valores y principios del Manifiesto Ágil y se considera parte del ecosistema ágil.

¿Se puede usar Kanban sin herramientas digitales?

Sí. Muchos equipos comienzan con tableros físicos utilizando pizarras y notas adhesivas. Los tableros físicos tienen la ventaja de ser más visibles y fomentar la interacción cara a cara. Sin embargo, para equipos distribuidos o remotos, las herramientas digitales son indispensables.

¿Cuál es la diferencia entre Kanban y un tablero Kanban?

Un tablero Kanban es simplemente una herramienta de visualización. El método Kanban es mucho más amplio e incluye principios, prácticas, métricas y cadencias para gestionar y mejorar el flujo de trabajo de forma continua. Usar un tablero no significa estar aplicando Kanban.

¿Kanban requiere estimaciones?

No. A diferencia de Scrum, Kanban no requiere estimar el tamaño de los elementos de trabajo. En su lugar, se basa en datos históricos de Lead Time y Throughput para hacer previsiones probabilísticas sobre cuándo se completará el trabajo.

¿Se puede combinar Kanban con Scrum?

Sí. La combinación de ambos enfoques se conoce como Scrumban. Esta combinación utiliza la estructura de roles y eventos de Scrum junto con las prácticas de visualización, límites de WIP y métricas de flujo de Kanban. Es una opción popular para equipos que buscan lo mejor de ambos mundos.

¿Qué certificaciones existen en Kanban?

Las principales certificaciones en Kanban son las ofrecidas por Kanban University, la organización fundada por David Anderson. Las más reconocidas incluyen Team Kanban Practitioner (TKP), Kanban Management Professional (KMP) y Kanban Coaching Professional (KCP).

¿Qué papel juega el WIP en la calidad del trabajo?

Limitar el WIP tiene un impacto directo en la calidad. Cuando los equipos tienen demasiadas tareas en curso, la atención se dispersa y aumentan los errores. Al reducir el WIP, cada miembro del equipo puede dedicar más concentración a cada tarea, lo que resulta en un trabajo de mayor calidad y menos retrabajo.

¿Cómo se mide el éxito de la implementación de Kanban?

El éxito de Kanban se mide a través de la mejora sostenida de las métricas de flujo: reducción del Lead Time, estabilización del Cycle Time, aumento del Throughput y disminución del trabajo bloqueado. También se evalúa la satisfacción del cliente y la previsibilidad de las entregas mediante el Service Level Expectation (SLE).