Límites de WIP en Scrum: los errores de Kanban que estancan el Sprint
Muchos Equipos Scrum han añadido un tablero Kanban y límites de trabajo en curso (WIP) a su flujo de trabajo, y la Kanban Guide for Scrum Teams de Scrum.org respalda precisamente esto. Bien hechos, los límites de WIP exponen los cuellos de botella y empujan al equipo a terminar el trabajo en lugar de empezarlo. Hechos sin cuidado, generan fricción sin mejorar el flujo. Tras un año de trabajo distribuido, donde un elemento detenido puede quedarse días sin que nadie lo note en la cola de una oficina en casa, acertar con esto importa más que nunca. Estos son los errores que los equipos cometen con más frecuencia.
Dónde se equivocan los equipos
Fijar el límite tan alto que no importe. Un límite de WIP que supera lo que el equipo trabajaría a la vez no cambia nada. El objetivo del límite es que el equipo sienta la restricción y termine las cosas antes de tomar más. Si nunca aprieta, es decoración.
Tratar los límites de WIP como sustituto del Sprint. Añadir Kanban no elimina Scrum. El Sprint, el Objetivo del Sprint y todos los eventos permanecen. La Kanban Guide for Scrum Teams es explícita: estas prácticas complementan el marco Scrum, no reemplazan el Scrum Diario, la Revisión del Sprint ni la Retrospectiva.
Ignorar las métricas de flujo una vez montado el tablero. Un tablero con límites pero sin atención al tiempo de ciclo, la antigüedad de los elementos o el rendimiento es solo una pared de notas adhesivas. El valor viene de observar cuánto tardan los elementos y actuar cuando envejecen.
No dejar nunca que el equipo ajuste el límite. Los límites de WIP no se imponen una vez y se congelan. El equipo debería inspeccionarlos y adaptarlos en la Retrospectiva: demasiado ajustados y la gente queda ociosa, demasiado holgados y los elementos se acumulan a medio terminar.
Bloquear en lugar de converger. Cuando se alcanza el límite, lo correcto es que el equipo converja para terminar el trabajo en curso, no que empiece algo nuevo en otra columna. Los equipos que esquivan el límite en silencio pierden todo su beneficio.
Hacerlo bien
Bien usados, los límites de WIP y el Scrum Diario se refuerzan mutuamente: la conversación pasa de «qué hice ayer» a «qué está bloqueando los elementos más cercanos a terminar». Mantenga la práctica honesta con unos pocos hábitos.
Fije el límite inicial algo por debajo de la comodidad actual y luego ajústelo en la Retrospectiva con datos reales de tiempo de ciclo.
Haga muy visibles los elementos bloqueados: para equipos distribuidos, una marca en la herramienta que todos revisan vale más que un rincón de un tablero físico.
Cuando se alcance el límite, termine antes de empezar: converja, trabaje en pareja o revise en lugar de abrir trabajo nuevo.
Revise la antigüedad de los elementos en el Scrum Diario para que nada quede olvidado en una cola remota.
Si sus equipos quieren combinar las prácticas de flujo de Scrum y Kanban de una forma que de verdad perdure, la asesoría en entrega de programas y proyectos de XNM puede ayudarle a implantarlo y acompañarlo.