Como lograr el mejor WIP de un KANBAN

Una de las reglas importantes de Kanban (si no estás muy familiarizado con el tema, te recomiendo leer primero el post sobre Kanban) es que se deben definir cuantas tareas como máximo pueden realizarse en cada fase del ciclo de trabajo. A ese número máximo de tareas se le llama límite “Work In Progress” (WIP) (¿o Work in Process? ¿Madrid o Atlético? ¿Coca-Cola o Pepsi?).

Si una columna de un tablero Kanban (es decir, una fase del ciclo de producción) tiene, por ejemplo, un WIP 5, esto quiere decir que si el equipo (ojo, equipo, no las personas, porque el WIP de un KANBAN afecta a una parte del proceso, en la que participan n personas) en esa fase está trabajando en cinco tareas no podrán trabajar en ninguna otra hasta que terminen alguna de estas cinco.

Un recurrido ejemplo que ilustra el WIP de un KANBAN es el de la impresora. El WIP de una impresora es 1, sólo se imprime una página a la vez. Así, si una página se atasca, y no se puede imprimir, se da la alarma inmediatamente, y se para el proceso, en vez de comenzar a imprimir otra hoja, lo que complicaría más el problema.

Aunque esto del WIP de un KANBAN pueda parecer algo muy simple, su ajuste tiene un gran impacto en la productividad de un equipo (que se lo pregunten a Toyota, que utiliza como pieza básica de su proceso de producción el Kanban y el WIP). Y saber ajustar el mejor WIP en cada fase del proceso productivo no es una tarea fácil. Y para ello te dejo en este post algunas heurísticas al respecto.

Qué suele suceder cuando el WIP de un KANBAN es muy bajo

Si el WIP es muy bajo (imaginemos un WIP 1 en una de las fases para un equipo de 4 personas), las tareas se realizarán rápido (ya que podría tener hasta 4 personas trabajando sobre una tarea) pero probablemente tendré miembros del equipo ociosos (ya que normalmente no todas las personas podrán trabajar a la vez sobre la misma tarea).

Además, las tareas estarán en estado de “pendientes de empezar a ser realizadas” demasiado tiempo, en espera de que el equipo comience a trabajar sobre ellas. Y el “lead time” (una métrica Kanban que mide desde que se hace una petición hasta que se realiza la entrega) será mayor de lo necesario.

Un WIP ajustado, a la baja, hará que problemas que pudieran bloquear la finalización de una tarea se resuelvan lo más pronto posible, ya que hasta que no se resuelvan no se podrá comenzar a trabajar en otra cosa (filosofía Lean “soluciona los problemas cuanto antes”, te recomiendo aquí este post).

A menor WIP mayor colaboración del equipo, más tareas se harán por más de una persona, teniendo en cuenta que hay un límite de personas que pueden trabajar a la vez sobre una misma tarea.

Por ello, otro propósito de limitar el WIP es evitar el exceso de multitareas y la sobrecarga de una parte del proceso.

La esencia de los limites WIP de un KANBAN es enfocar al equipo en finalizar cosas… más que en comenzar cosas.

Qué suele suceder cuando el WIP de un KANBAN es muy alto

Pero si el WIP de un KANBAN es muy alto (imaginemos un WIP 8 para un equipo de 4 personas) existe el riesgo de empezar muchas tareas y terminar pocas, de estar trabajando en varias cosas a la vez sin cerrar muchos temas.

Frente a cualquier contratiempo en una tarea, el equipo puede optar por comenzar con otra y demorar el terminar aquellas que presenten contratiempos.

En este sentido se observa cómo ajustar el límite WIP de un KANBAN actúa como una señal de alerta, avisando de un problema antes de que se nos escape de las manos y siga avanzando (esto es filosofía Lean “soluciona los problemas cuanto antes”), ya que el equipo se centrará en resolver problemas que impiden cerrar tareas, ya que hasta que no lo hagan no podrán comenzar a trabajar en otras.

¿Cómo saber el WIP de un KANBAN correcto?

Pues como te puedes imaginar no hay una regla exacta que lo calcule. Y además de depender del equipo, del producto que se desarrolle, etc., para un mismo equipo el WIP suele variar con el tiempo, lo que implica un ajuste y mejora continua (también muy en la filosofía Lean Kaizen).
Pero sí que hay algunas heurísticas a observar, para detectar si tenemos algún problema con nuestro WIP, por ejemplo:
– Si en una fase del ciclo de producción se observa que hay tareas sobre las que nadie trabaja durante mucho tiempo es porque el WIP de esa fase probablemente es alto. Esto también lo puedes observar en que el “lead time” será alto.
– Si en una fase hay gente parada durante mucho tiempo el WIP de un KANBAN probablemente es bajo. La productividad será baja. Y esto ocurre porque no todo el equipo puede trabajar a la vez sobre una tarea.
Otra cuestión es con qué WIP comenzar la primera vez. Hay quien usa la regla de 2n-1, donde n es el número de miembros del equipo, y el -1 se aplica para aumentar el grado de colaboración. Pero no es más que una regla, que no tiene mayor base que algo de sentido común. Al final, cada equipo debe buscar su WIP.
Fuentes. Si quieres ampliar información sobre este tema te recomiendo estos dos libros: Kanban and Scrum – making the most of both y Lean from the Trenches: Managing Large-Scale Projects with Kanban.
Y, como siempre, os animo a comentar el tema en el blog o en el twitter (@jgarzas).

0 comentarios en “Como lograr el mejor WIP de un KANBAN”

  1. Pingback: Bitacoras.com

  2. Hola Javier. Llevo un tiempo siguiendo tu blog y me parece muy interesante. Te comento un problemilla que me ocurre al estar suscrito a tus entradas nuevas por mail, y es que los links los pones de la forma «../2011/11/kanban.html», y desde el cliente de correo (gmail) eso intenta ir a «http://../2011/11/kanban.html», lo cual obviamente no funciona.
    Felicidades por el blog. Saludos.

  3. Hola;
    Estos terminos que tan de moda están ahora viene a ser lo que en proyectos web se viene haciendo desde hace años, unos programan el Front End, otros el Back, un diseño previo para maquetarlo mientras los programadores analizan la estructura, el organigrama de la base de datos, etc…
    No la he usado pero tiene buena pinta, barata y muy visual http://kanbantool.com/
    Para algo no tan visual pero gratuito y que funciona desde hace años el OpenProject
    Pero la lista de herramientas es enorme, aqui una referencia
    http://www.opensourceprojectmanagement.org/

  4. Os dejo una aportación, por si alguno quiere hacer la prueba, ya que a mí me ha dado resultado, y he visto como daba resultado en otros equipos.
    El caso, es que la «regla» de 2n-1, solo la veo realmente «adecuada» para equipos pequeños, de 1 a tres personas. Para equipos de 4 a 6 personas, aplicamos 2n-2, y para equipos entre 7 y 9 personas, 2n-3. Ya que si persistimos con la otra «regla», al aumentar el número de miembros del equipo disminuye el tiempo «real» para que varios miembros se encarguen de una tarea simultáneamente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba