Taiichi Ohno identificó 7 tipos de desperdicio en la manufactura Toyota — actividades que consumen tiempo y recursos sin aportar valor al cliente. En el desarrollo de software, estos desperdicios se manifiestan de formas distintas pero igualmente costosas. Kanban, al hacer visible el flujo de trabajo, los expone antes de que se cronifiquen.
01Inventario: trabajo sin terminar
En el desarrollo de software, el inventario son las funcionalidades a medias, los branches sin mergear, las historias refinadas pero no desarrolladas. El WIP es el inventario del software. Cada elemento a medio hacer tiene un coste de contexto, un riesgo de desactualización y un coste de coordinación.
Kanban ataca este desperdicio con los límites WIP: forzar al equipo a terminar antes de empezar reduce el inventario en curso y hace que el trabajo fluya en lugar de acumularse.
02Sobreproducción: construir lo que nadie pide
Construir features que los usuarios no usan es el mayor desperdicio del desarrollo moderno. Ocurre cuando los equipos optimizan para velocidad de producción en lugar de valor entregado. Kanban, al hacer explícita la cola de trabajo y el criterio de priorización, hace visible la pregunta: ¿por qué estamos haciendo esto ahora?
03Esperas: tiempo muerto entre pasos
Las esperas son el desperdicio más visible en un tablero Kanban: tarjetas que esperan revisión, aprobación, despliegue. Las columnas de espera o buffer en el tablero hacen explícito cuánto tiempo pasa una tarjeta esperando — y esa visibilidad es el primer paso para eliminarlo.
04Transporte: handoffs innecesarios
Cada vez que el trabajo pasa de un equipo a otro — de análisis a desarrollo, de desarrollo a QA, de QA a operaciones — hay una transferencia de información que puede perderse o degradarse. El Value Stream Mapping aplicado al flujo Kanban revela estos handoffs y permite diseñar flujos con menos intermediarios.
05Movimiento: cambios de contexto
Los cambios de contexto son el equivalente al movimiento innecesario en manufactura. Cada vez que un desarrollador cambia de tarea, pierde tiempo en cargar el contexto del nuevo trabajo. Los límites WIP reducen los cambios de contexto forzando al equipo a completar antes de cambiar.
06Defectos: bugs y retrabajos
Los defectos descubiertos tarde son mucho más caros que los descubiertos pronto. Kanban, al limitar el WIP y hacer visible el flujo, reduce la cantidad de trabajo "en vuelo" y facilita ciclos de feedback más cortos — lo que significa que los bugs se detectan antes.
07Sobreprocesado: más proceso del necesario
Reuniones que no aportan, documentación que nadie lee, procesos de aprobación con cinco firmas cuando bastaría una. Las políticas explícitas de Kanban hacen visible el proceso real y permiten cuestionar cada paso: ¿este paso añade valor o solo añade tiempo?