Qué es el Método Kanban y por qué importa
En este cuerpo de conocimiento, Kanban significa el Método Kanban: un enfoque para gestionar y mejorar servicios de trabajo del conocimiento, organizado por David J. Anderson a partir de mediados de los años 2000. La idea central cabe en una frase. Haces visible el trabajo, limitas cuánto trabajo queda en curso al mismo tiempo y usas lo que observas para cambiar el sistema en pasos pequeños y seguros.
El método parte del proceso que el equipo ya usa, sin roles, artefactos ni eventos predefinidos que reemplacen lo que existe. Por eso se describe como un método de cambio evolutivo, y no como un framework de proceso. Un cambio que no amenaza el cargo ni la identidad de las personas encuentra menos resistencia y dura más.
Lo que Kanban no es
Hay tres confusiones frecuentes:
- Kanban no es solo el tablero. Un tablero con “Por hacer, Haciendo, Hecho” es una visualización. Sin límites de WIP, políticas explícitas y cadencias de feedback, muestra el trabajo, pero no cambia el comportamiento del sistema.
- Kanban no es ausencia de compromiso. Un sistema Kanban bien diseñado tiene un punto de compromiso claro, expectativas de plazo basadas en datos y acuerdos explícitos con quien solicita el trabajo.
- Kanban no es “Scrum sin sprint”. El método no define iteraciones ni roles obligatorios. Un equipo que usa Scrum puede aplicar el Método Kanban sobre lo que ya hace, y muchos lo hacen.
Conceptos clave
Principios de gestión del cambio
El primer grupo de principios trata de cómo ocurre el cambio:
- Comienza con lo que haces hoy. Entiende el proceso real, cómo ocurre de verdad, y respeta los roles y responsabilidades actuales.
- Acuerda que la mejora será evolutiva. Las personas aceptan cambiar mediante ajustes incrementales, observables y reversibles.
- Fomenta el liderazgo en todos los niveles. Cualquier persona que vea un problema en el flujo puede proponer un experimento, sin esperar la iniciativa de la gerencia.
Principios de entrega de servicio
El segundo grupo mira el servicio que presta el equipo:
- Entiende lo que el cliente necesita y espera, incluidos plazo, calidad y previsibilidad, y no solo la lista de pedidos.
- Gestiona el trabajo, no a las personas. Cuando el flujo es visible y las reglas son claras, las personas se autoorganizan en torno a él.
- Revisa con regularidad la red de servicios y sus políticas, porque el resultado depende de las reglas del sistema más que del esfuerzo individual.
Prácticas generales
Las prácticas generales son lo que efectivamente haces en el día a día:
- Visualizar el trabajo y el flujo, incluidas las colas y los bloqueos.
- Limitar el trabajo en curso, para crear el sistema pull.
- Gestionar el flujo, observando el tiempo, la acumulación y el envejecimiento de los ítems.
- Hacer explícitas las políticas, como los criterios de entrada y salida de cada etapa.
- Implementar ciclos de feedback, mediante las cadencias.
- Mejorar de forma colaborativa y evolucionar mediante experimentos, usando modelos (teoría de colas, teoría de restricciones, Costo del Retraso) para formular hipótesis.
Nadie adopta las seis a la vez y en profundidad. Un equipo de soporte puede empezar visualizando tickets y bloqueos y recién en el segundo mes introducir límites de WIP.
Sistema pull
En un sistema push (de empuje), el trabajo entra porque alguien decidió que debe entrar: el gerente reparte doce tickets a cada analista el lunes. En un sistema pull (de arrastre), el trabajo entra cuando hay capacidad libre, y la señal de esa capacidad es el límite de WIP. Cuando la etapa “En análisis” tiene límite 3 y está con 2 ítems, hay un espacio, y alguien arrastra el siguiente ítem de la cola. En el trabajo del conocimiento, el propio límite cumple el papel de la tarjeta de señalización: por eso se habla de sistema kanban virtual.
El efecto práctico es que el equipo deja de empezar y pasa a terminar: menos cambio de contexto, colas más pequeñas y plazos más cortos y estables. Puedes sentir ese efecto en pocos minutos en la experiencia de límite de WIP.
De Toyota al trabajo del conocimiento
La palabra kanban viene del Sistema de Producción Toyota, en el que unas tarjetas señalaban la necesidad de reponer piezas, limitando el inventario entre las etapas. El Método Kanban hereda dos elementos de ese origen: la señal de arrastre y el límite de inventario intermedio. No hereda la premisa de que los ítems son iguales. En el trabajo del conocimiento, cada ítem es diferente, buena parte del trabajo es descubrimiento y la variabilidad es alta. Por eso el método prefiere expectativas probabilísticas, como “el 85% de los ítems está listo en 9 días o menos”, a las estimaciones puntuales de cada ítem.
Errores comunes
- Copiar el tablero de otro equipo. El tablero debe retratar tu flujo, no el de un ejemplo de internet.
- Reestructurar roles el primer día. Eso contradice el principio de comenzar con lo que existe y genera resistencia innecesaria.
- Tratar el límite de WIP como meta de ocupación. El límite es un techo que expone problemas, no un número que hay que llenar.
- Medir personas en lugar del flujo. Comparar la productividad individual incentiva empezar muchos ítems y esconder bloqueos.
Cómo aparece esto en el examen
Las preguntas de este dominio te piden reconocer qué principio está en juego en una situación concreta. Por ejemplo: una gerente quiere implantar Kanban y propone, en la misma semana, crear nuevos cargos y cambiar la herramienta. Tienes que identificar qué choca con el cambio evolutivo y cuál sería el primer paso coherente. También aparecen situaciones para separar una visualización de un sistema Kanban y para distinguir un sistema pull de uno push a partir de la descripción de cómo entra el trabajo.
Preguntas frecuentes
¿El Método Kanban es una metodología ágil?
Es compatible con los valores ágiles y muy usado por equipos ágiles, pero no depende de ellos. El Método Kanban es un método de gestión del cambio y de mejora de servicios. Funciona en desarrollo de software, operaciones, marketing, área legal y cualquier área en la que el trabajo llega como pedidos y debe entregarse con previsibilidad.
¿Tengo que abandonar Scrum para usar el Método Kanban?
No. Como el método comienza con lo que haces hoy, puede aplicarse sobre un proceso Scrum. En la práctica, los equipos Scrum suelen agregar límites de WIP a las etapas del sprint, medir el Cycle Time y usar pronósticos probabilísticos en la planificación.
¿Cuál es la diferencia entre un tablero Kanban y un sistema Kanban?
El tablero es la visualización. El sistema Kanban incluye el tablero, los límites de WIP que crean el flujo pull, las políticas explícitas, las métricas y las cadencias de revisión. Un tablero sin límites muestra el trabajo; un sistema cambia el comportamiento del flujo.
