Kanban es un marco de trabajo ágil centrado en la visualización, la eficiencia del flujo y la mejora continua. A continuación, exploramos en detalle su historia, su filosofía de trabajo y cómo gestiona el ciclo de vida de los entregables.
1. Historia de Kanban
El origen de Kanban se remonta a la industria automotriz japonesa de la posguerra:
- Década de 1940 – El Origen Industrial (Toyota): Taiichi Ohno, ingeniero industrial de Toyota, diseñó el sistema Kanban inspirado en la logística de los supermercados estadounidenses. En un supermercado, los estantes se reponen solo cuando los clientes consumen un producto. Ohno aplicó este concepto a la línea de ensamblaje para evitar la sobreproducción, creando tarjetas físicas (kanban) para señalar la necesidad de material en la cadena de montaje. Este fue el pilar de la filosofía Just-In-Time (JIT) y del Toyota Production System (TPS).
- 2004 en adelante – Adaptación al Conocimiento y Software: David J. Anderson adaptó los principios de Toyota al trabajo de conocimiento, desarrollo de software y gestión de operaciones.
- 2010 – Publicación del Marco Moderno: Anderson publicó el libro “Kanban: Successful Evolutionary Change for Your Technology Business”, estableciendo de manera formal el Método Kanban tal como se utiliza hoy en la gestión de proyectos y servicios digitales.
2. Filosofía de Kanban
La filosofía de Kanban reposa en la optimización del flujo y el cambio gradual mediante la colaboración. Sus pilares filosóficos fundamentales son:
A. Sistema “Pull” vs. Sistema “Push”
En los sistemas tradicionales (Push), el trabajo se asigna y “empuja” hacia las personas independientemente de su capacidad real. Kanban opera como un sistema Pull (de tirón): los miembros del equipo “tiran” o toman una nueva tarea únicamente cuando tienen capacidad disponible para ejecutarla.
B. “Deja de empezar, empieza a terminar”
Kanban prioriza la finalización de tareas sobre el inicio de nuevas iniciativas. Reducir la multitarea baja el estrés del equipo, disminuye los costos de cambio de contexto (context switching) y acelera la entrega de valor.
C. Filosofía Kaizen (Mejora Continua Evolutiva)
Kanban rechaza las reestructuraciones drásticas o disruptivas. En su lugar, promueve el principio de Kaizen: pequeños cambios incrementales continuos acordados por el propio equipo a partir de datos reales de su desempeño.
3. Gestión del Ciclo de Vida del Trabajo en Kanban
A diferencia de marcos iterativos como Scrum (que organizan el trabajo en bloques fijos o Sprints), Kanban gestiona el ciclo de vida del trabajo como un flujo continuo de valor.
[ Compromiso ] [ Entrega ]
| |
v v
+---------+ +-------------+ +--------------+ +-------+
| Backlog | --> | En Progreso | --> | En Verificación| -->| Hecho |
+---------+ +-------------+ +--------------+ +-------+
^ ^ ^
| | |
(Punto de (Límite (Límite
Entrada) WIP: 3) WIP: 2)
Etapas del Ciclo de Vida
- Definición y Selección (Punto de Compromiso Inicial): Las tareas o peticiones ingresan a una lista de espera u opción (Backlog). No hay compromiso formal de desarrollo hasta que la tarea cruza el Punto de Compromiso (Commitment Point), momento en el cual el equipo acepta la responsabilidad de completarla.
- Ejecución y Flujo Guiado por Límites WIP: La tarea avanza a través de las diferentes fases del proceso (por ejemplo: Análisis, Desarrollo, Pruebas).
- Cada fase tiene un Límite de WIP (Work in Progress) estricto.
- Si una fase alcanza su límite de WIP, no se pueden ingresar más tareas a esa columna hasta que se libere espacio al completar o mover una tarea existente.
- Gestión de Bloqueos y Cuellos de Botella: Cuando una tarea no puede avanzar (por una dependencia externa o un fallo), se marca visualmente como Bloqueada directamente en el tablero. El equipo enfoca sus esfuerzos en desatascar las tareas bloqueadas antes de tomar trabajo nuevo.
- Finalización y Entrega (Punto de Entrega): Una vez que el elemento cumple con la definición de completado (Definition of Done), cruza el Punto de Entrega (Delivery Point) y se traslada a la columna de Hecho/Desplegado.
Métricas del Ciclo de Vida
El ciclo de vida en Kanban se mide continuamente para garantizar la previsibilidad del sistema:
- Lead Time (Tiempo de Entrega): Mide el tiempo total desde que la tarea es creada o solicitada hasta que se entrega.
- Cycle Time (Tiempo de Ciclo): Mide el tiempo desde que el equipo realmente comienza a trabajar en la tarea (punto de compromiso) hasta que se completa.


Cuales son los actores en Kanban?
Kanban no define actores o roles obligatorios, los roles dependen de la organización. Generalmente participan el cliente, responsables del producto y el equipo encargado de ejecutar el trabajo.
considera que Kanban sería más adecuado que Scrum para un equipo pequeño con pocos recursos y tareas que cambian constantemente?
y por que?
segun yo si, por motivos de que no se necesitan roles definidos y si hay tareas disponible se toma esas tareas cuando hay capacidad disponible, tambien se evita reuniones al ser un grupo pequeño para mi es mas adecuado usar kanban
¿Cómo se puede combinar Kanban con Scrum en la realidad para obtener lo mejor de ambos?
No terminé de entender del todo cómo funciona el límite WIP en Kanban, porque si una columna como “En Progreso” ya llegó al máximo de tareas permitidas y aparece una nueva tarea que es urgente o muy importante, entonces ¿el equipo necesariamente tiene que esperar hasta terminar alguna de las tareas actuales o existe alguna forma de hacer una excepción sin romper la lógica del sistema Kanban y sin generar nuevamente acumulación de trabajo?
¿Cómo debería determinar un equipo de desarrollo de software los límites WIP adecuados para cada etapa del proyecto sin que estos límites reduzcan la productividad o generen tiempos de espera innecesarios?
¿De qué manera influyen las métricas de Lead Time y Cycle Time en la identificación y resolución de cuellos de botella dentro de un tablero Kanban, y cómo puede el equipo utilizar ambas para diferenciar problemas de eficiencia interna frente a retrasos en la entrada de requerimientos?
Tengo una duda sobre la diferencia entre el Lead Time y el Cycle Time, porque ambos parecen medir el tiempo que tarda una tarea en completarse, pero uno comienza desde que la tarea es solicitada y el otro desde que el equipo realmente empieza a trabajar en ella, entonces ¿para qué sirve medir los dos por separado y cuál de los dos sería más importante para saber si el equipo realmente está trabajando de manera eficiente?
Porque Kanban prioriza la finalización de tareas sobre el inicio de nuevas iniciativas.?
Creo que lo que más me convence de la metodología es que no exige reorganizar todo como Scrum: se aplica sobre el flujo que ya tenés y mejorás visualizando y limitando el WIP ¿en qué casos lo recomendaría por encima de Scrum?
¿si Kanban trabaja con un flujo continuo y no utiliza Sprints como Scrum, ¿cómo determina el equipo cuándo debe priorizar una tarea y cuándo debe detenerse para mejorar el flujo de trabajo?
Qué podría suceder con la productividad de un equipo si todos comienzan tareas nuevas pero pocas llegan a terminarse
¿Que hace que Kanban sea considerada una metodologia y scrum no?.
¿cómo se supone que elija qué tarea agarrar del Backlog sin romper el flujo o saturar las columnas con límite de WIP?
¿Cómo maneja Kanban las tareas urgentes que llegan de improviso, si no existen Sprints que protejan el trabajo en curso?
¿Qué elemento es fundamental para la gestión visual en un sistema Kanban?
Kanban permite visualizar de forma clara el avance de las tareas desde el Backlog hasta Hecho, estableciendo límites de trabajo en progreso (WIP) para evitar que el equipo tenga demasiadas tareas abiertas al mismo tiempo. También es importante identificar los bloqueos y priorizar su solución para evitar retrasos y cuellos de botella.
Además, comprendí que las métricas como Lead Time y Cycle Time ayudan a medir qué tan eficiente es el flujo de trabajo. Esto es importante porque permite al equipo detectar problemas, mejorar continuamente el proceso y tener una mejor idea de cuánto tiempo puede tomar completar y entregar una tarea.