Featureban es un juego diseñado por Mike Burrows para experimentar el efecto que tiene limitar el trabajo (WIP)
Uno de los problemas más habituales en organizaciones que pretenden usar Kanban es la resistencia al WIP. Normalmente dicha resistencia viene dada por las presiones y el conocimiento convencional de que la gente debe estar ocupada.
Sin embargo, pocos tienen en cuenta algo importante cuando se concentran en realizar trabajo, focalizándose en la eficiencia en lugar de en el flujo de valor.
Lo normal es que surjan bloqueos que finalmente redundan en grandes cantidades de trabajo a medio hacer y no terminado. Lo que en empresas industriales se conocen como inventario.
Diferencias entre flujo y lotes
Cuando trabajamos, tendemos a hacerlo en lotes de trabajo. Pensamos que es la manera más eficiente de hacerlo. En lugar de realizar una tarea al completo, desde el primer estado hasta el último, tendemos a realizar todas las tareas de un estado para pasarlo a la siguiente fase. Eso se llama procesamiento en lotes. Es eficiente pero muy lento.
El trabajo basado en flujo es un paradigma distinto, en el que obviamos la eficiencia y nos centramos en terminar pequeñas partes del trabajo de forma continua. Ese tipo de trabajo es el que llevó a Toyota a convertirse en el fabricante de automóviles más importante del mundo.
Este vídeo explica muy bien estos dos paradigmas.
Agilidad y WIP
El vídeo nos muestra cómo la diferencia de tiempo –lead time– es espectacular entre cada una de las formas de procesamiento. Para poder mejorar la agilidad del negocio, es necesario limitar el WIP para un procesamiento basado en flujo, en lugar de uno basado en lotes.
Este concepto es difícil de entender. Gracias al taylorismo y a la producción en cadena, tendemos intuitivamente a pensar en lotes en lugar de flujo. Featureban es un juego que ayuda a romper esa barrera mental.
A través de un ejercicio de simulación, el equipo se enfoca primero en ser lo más eficiente posible y después en limitar el WIP para observar las diferencias de flujo. Se puede descargar gratuitamente de la página de agendashift.
[slideshare id=39065931&doc=featureban-slides-140914090927-phpapp02]
¿Cual es el WIP ideal?
Depende. Algunas personas empiezan limitando el WIP al número de personas implicadas en el proceso. Otros utilizan la fórmula 2n-1. La realidad es distinta.
El WIP es una variable de la que dependen otras dos:
- Thoughtput (número de ítems entregados): Cuanto más bajo sea nuestro WIP, más alto será nuestro thoughput por unidad de tiempo. Por eso el procesamiento por lotes es más eficiente. Si calculamos la inversa del throughput, obtenemos el Cycle Time medio por ítem.
- Lead time (Tiempo medio de entrega de un ítem terminado): El Lead Time es la segunda variable. Un WIP más alto significa un lead time más alto y un Cycle Time más largo, mientras que un WIP más bajo significa tiempos más cortos y tiempos de ciclo más corto.
El WIP hay que diseñarlo dependiendo del throughput y del lead time que queramos, ya que dependiendo de las situaciones y restricciones internas de nuestro sistema, uno será más eficiente que otro. Tienes más información en este artículo sobre métricas ágiles y en este vídeo.
Mi cuñado dice que se puede ser muy eficiente y entregar con mucha agilidad
Dile a tu cuñado que si eso fuera así, yo no tendría trabajo y estaría pidiendo en la puerta del sol. La última vez que miré… todavía tenía cosas que hacer.
