WIP Limits: El Secreto para Terminar lo que Empiezas

Hacer una pregunta simple en cualquier equipo de trabajo: ¿Cuántas tareas tienen en este momento que comenzaron pero aún no terminaron? La respuesta suele ser alarmante: 5, 10, 20 tareas abiertas por persona.

Esto no es un problema de pereza ni de falta de compromiso. Es un problema sistémico de cómo organizamos el trabajo. Y tiene una solución contraintuitiva pero efectiva: trabajar en menos cosas a la vez.

La Teoría de las Restricciones (Eliyahu Goldratt)

El Dr. Eliyahu Goldratt, en su influyente libro The Goal (1984), demostró que en cualquier sistema, hay al menos una restricción (cuello de botella) que limita la producción total del sistema. La solución no es optimizar todas las partes del sistema, sino identificar y gestionar la restricción.

En términos de flujo de trabajo:

• Si el equipo de desarrollo puede procesar 5 ítems por semana
• Y el equipo de QA solo puede revisar 2 ítems por semana
• Entonces el sistema no puede entregar más de 2 ítems por semana
• Empujar más trabajo al desarrollo no ayuda; solo crea una pila de espera frente a QA

Los WIP Limits hacen visible este cuello de botella: cuando la columna de QA alcanza su límite y no puede recibir más ítems, el equipo de desarrollo debe parar y ayudar a desbloquear QA.

El Costo del Cambio de Contexto

Gerald Weinberg, pionero de la ingeniería de software, cuantificó el costo del multitasking:

Cada proyecto adicional no suma: resta. Trabajar en 5 proyectos simultáneos significa que cada uno recibe solo el 10% de tu capacidad.

No existe una fórmula mágica. Los WIP limits se experimentan y ajustan. Sin embargo, hay puntos de partida útiles:

Método 1: Basado en el tamaño del equipo

Para columnas de trabajo activo (En desarrollo, En revisión):

WIP Limit inicial = Número de personas que trabajan en esa etapa

Si 3 developers trabajan en desarrollo, el WIP limit inicial para esa columna es 3.

Método 2: Basado en el tiempo de ciclo

Si sabes que:

• El equipo procesa (completa) 5 ítems por semana (Throughput)
• Y cada ítem tarda en promedio 5 días en completarse (Cycle Time)
• Entonces por la Ley de Little: WIP = 5 días × 5 ítems/semana × (1 semana/5 días) = 5 ítems

Método 3: Empezar conservador y ajustar

Una regla pragmática:

1. Comienza con WIP = equipo / 2 (muy conservador, para forzar colaboración)
2. Si el flujo se bloquea frecuentemente, sube el límite
3. Si el trabajo se acumula sin terminarse, baja el límite
4. El objetivo es encontrar el número donde el flujo es suave pero el equipo está siempre trabajando

Este es el momento crítico donde muchos equipos fallan. Cuando una columna llega a su límite, la respuesta correcta no es ignorar el límite y añadir más trabajo. La respuesta correcta es:

1. Enjambre sobre el trabajo bloqueado (Swarming)

Si una tarea está bloqueada en Revisión porque nadie puede revisarla, la persona de Desarrollo que quiere añadir más trabajo debería ir a ayudar con la revisión.

Este comportamiento de enjambre (swarming) tiene varios beneficios:

• Desbloquea el cuello de botella
• Distribuye el conocimiento (el developer aprende de QA, QA aprende del developer)
• Termina el trabajo existente antes de empezar uno nuevo

2. Investigar la causa raíz del bloqueo

Si el límite de una columna se alcanza constantemente, es una señal de que hay un problema sistémico:

• ¿La calidad de lo que entra a esa etapa es baja (mucho retrabajo)?
• ¿Hay una sola persona en esa etapa que crea un cuello de botella de recursos?
• ¿Las historias son demasiado grandes y tardan demasiado?
• ¿Hay impedimentos externos (dependencias de otros equipos)?

3. Comunicar el bloqueo

Si el desarrollador no puede ayudar con la revisión y no puede tomar trabajo nuevo porque el WIP está lleno, la respuesta correcta es hacer visible el bloqueo en la reunión diaria y buscar solución colectiva.

En Kanban avanzado, los equipos diferencian las reglas de WIP por tipo de trabajo. Esto se llama Clases de Servicio:

Clase de servicio urgente (expedite):

• Trabajo que tiene consecuencias serias si no se completa rápidamente
• Generalmente bypass del WIP limit normal (1 ítem urgente puede entrar aunque el WIP esté lleno)
• Se marca visualmente de forma diferente (post-it rojo, indicador de llama)

Clase de servicio de fecha fija:

• Trabajo con una fecha de entrega comprometida externamente
• Recibe prioridad adicional conforme se acerca la fecha

Clase de servicio estándar:

• El trabajo normal que sigue las reglas regulares de WIP

Clase de servicio intangible:

• Trabajo de mejora interna, documentación, infraestructura
• Puede tener WIP limit separado para asegurarse de que se hace aunque hay mucho trabajo urgente

Error 1: Tratar el WIP Limit como sugerencia
Si el límite es 3 y nadie lo respeta, no hay WIP limit. La disciplina de respetar el límite es lo que genera el beneficio.

Error 2: WIP Limits demasiado altos
Si el límite es 20 y el equipo tiene 5 personas, el límite no sirve para nada. Un WIP limit efectivo se alcanza regularmente y crea la tensión creativa necesaria para priorizar.

Error 3: WIP Limits que nunca se ajustan
Los límites iniciales son solo el punto de partida. Deben revisarse en cada retrospectiva basándose en los datos de flujo.

Error 4: Ignorar el WIP de tareas no rastreadas
Si el equipo tiene tareas en el tablero pero también muchas reuniones, correos urgentes y peticiones verbales que no están rastreadas, el WIP real es mucho mayor que el visible.

Error 5: WIP Limits individuales en lugar de sistémicos
Algunos equipos ponen límites por persona en lugar de por columna. Esto puede perpetuar los silos: cada persona trabaja en sus tareas sin ayudar a desbloquear las tareas de otros.

Implementar WIP Limits no es solo un cambio técnico; es un cambio cultural. Requiere:

Pasar de empujar a jalar: En lugar de que el PM asigne trabajo, los miembros del equipo jalan trabajo cuando tienen capacidad.

Pasar de estar ocupado a terminar cosas: La métrica de éxito no es cuántas tareas tienes abiertas, sino cuántas completaste.

Pasar de individuos a sistema: El éxito del sistema (el equipo completa ítems) es más importante que la eficiencia individual (yo tengo muchas tareas abiertas).

1. Toma un inventario: Haz que cada miembro del equipo liste todo el trabajo que tiene en curso actualmente. Suma el total por columna en tu tablero.

2. Reacciona a lo que ves: ¿Hay columnas con 10+ ítems? ¿Hay personas con 7+ tareas abiertas? Ese es tu punto de partida.

3. Propón los límites: Calcula el WIP limit usando el método del equipo (número de personas en cada etapa).

4. Acuerda con el equipo: Los WIP limits no deben imponerse; deben acordarse. Explica el razonamiento.

5. Monitorea durante 2-3 semanas: Observa qué pasa cuando se alcanza el límite. ¿El equipo hace swarm? ¿Se ignora el límite? ¿Qué bloqueos emergen?

6. Ajusta y repite: Basado en la observación, ajusta los límites y el proceso.

Resumen de la Lección

• Los WIP Limits son el número máximo de ítems permitidos en una columna del tablero.
• El costo del multitasking es real: trabajar en 5 proyectos simultáneos deja solo un 10% de capacidad para cada uno.
• Cuando el WIP Limit se alcanza, la respuesta es enjambrarse sobre el trabajo bloqueado, no ignorar el límite.
• Los WIP Limits hacen visibles los cuellos de botella sistémicos.
• Los límites iniciales son un punto de partida; se ajustan con la experiencia y los datos.

En la próxima lección, aprenderás las métricas clave de Kanban: Lead Time, Cycle Time y Throughput.