Los 4 principios de Kanban (no reemplazan, evolucionan)
Kanban parte de una premisa distinta a Scrum: no impone un framework nuevo, evoluciona el proceso que el equipo ya tiene. Sus principios son: empieza con lo que haces ahora, acuerda perseguir cambios incrementales, respeta los roles y responsabilidades actuales, y fomenta el liderazgo en todos los niveles.
Por eso Kanban se adopta rápido en equipos de soporte, operaciones o mantenimiento: no hay que reorganizar roles ni imponer Sprints donde el trabajo llega de forma impredecible.
Las 6 prácticas clave de Kanban
El método se sostiene en seis prácticas concretas que cualquier equipo puede empezar a aplicar sobre su flujo actual:
- Visualizar el flujo — un tablero con columnas (Por hacer, En curso, Revisión, Hecho) donde todo el trabajo es visible.
- Limitar el trabajo en curso (WIP) — un número máximo de tarjetas por columna, para forzar a terminar antes de empezar algo nuevo.
- Gestionar el flujo — medir cuánto tarda una tarjeta en cruzar el tablero (lead time) y destrabar cuellos de botella.
- Hacer explícitas las políticas — reglas claras de 'cuándo algo está listo para pasar de columna'.
- Implementar ciclos de feedback — reuniones de flujo, reposición y revisión de estrategia, con frecuencia flexible (no timeboxes fijos).
- Mejorar colaborativamente, evolucionar experimentalmente — cambios pequeños y medibles, no rediseños totales del proceso.
¿Qué es el límite WIP y por qué importa?
El límite de Work In Progress (WIP) es el número máximo de tareas que pueden estar en una columna al mismo tiempo. Si el límite de 'En curso' es 3 y ya hay 3 tarjetas, nadie toma una tarea nueva hasta liberar espacio.
Parece simple, pero es la práctica que más cuesta sostener: expone que el equipo está haciendo multitasking, que hay cuellos de botella reales y que 'estar ocupado' no es lo mismo que 'estar entregando'. La resistencia a bajar el límite WIP suele ser más humana que técnica.
Kanban vs Scrum: la confusión más común
No son competidores, resuelven contextos distintos. Scrum funciona mejor cuando el trabajo se puede agrupar en incrementos de valor con fecha fija (un Sprint). Kanban funciona mejor cuando el trabajo llega de forma continua e impredecible — tickets de soporte, incidentes, solicitudes ad hoc.
Muchos equipos combinan ambos en lo que se conoce como Scrumban: la cadencia de eventos de Scrum con la visualización y límites WIP de Kanban.
Unidad de trabajo
- Scrum
- Sprint con fecha fija
- Kanban
- Flujo continuo, sin fecha fija
Roles definidos
- Scrum
- Sí (PO, SM, Developers)
- Kanban
- No — usa los roles existentes
Cómo limita el trabajo
- Scrum
- Sprint Backlog cerrado
- Kanban
- Límite WIP por columna
Mejor para
- Scrum
- Equipos de producto
- Kanban
- Soporte, operaciones, flujo variable
Lo que un tablero Kanban no te enseña
Kanban te da visibilidad total del flujo: qué se está haciendo, dónde se traba y cuánto tarda. Lo que no te da es la disciplina para respetar el límite WIP cuando el jefe pide 'solo una cosita más', ni la capacidad de decir que no cuando el tablero ya está lleno.
Esa disciplina — sostener un límite bajo presión, priorizar con criterio cuando todo parece urgente — no se lee en un manual de Kanban: se entrena. Por eso RECOProgramando creó Ágil de Verdad, un taller presencial de 2 horas en Lima centrado en tu reacción real cuando el plan (o el tablero) se desborda.
Preguntas frecuentes
Un método ágil de flujo continuo que visualiza el trabajo en un tablero, limita cuántas tareas están en curso a la vez (WIP) y evoluciona el proceso existente en vez de reemplazarlo.