Jerónimo Palacios

Kanban (II): Limitar WIP, Políticas y Clases de Servicio

En la primera parte de esta serie sobre el método Kanban, vimos las diferencias entre el método, los tableros y los kanbans. En esta segunda parte hablaremos de tres conceptos fundamentales para hacer Kanban.

Para diseñar y usar un sistema Kanban es necesario que creemos un sistema pull cerrado. A diferencia de los sistemas push, donde se planifica el trabajo y se mueve por una serie de fases, como por ejemplo cuando usamos Scrum, en Kanban siempre se mira la visualización del trabajo desde la derecha.

Si miramos un tablero Kanban como el de la imagen, tenemos que ponernos en la columna más cercana a Done por la derecha y ver si tenemos Kanbans libres. Tal y como explicaba en el artículo anterior, los post-its no son los Kanbans, sino los recuadros que se encuentran vacíos e indican una señal: Dame más trabajo.

Work in Progress Limit (WIP)

Para que existan estos recuadros, es necesario que introduzcamos un primer elemento necesario del método Kanban: Los límites del trabajo en curso. Los WIPs nos van a indicar cual es el número máximo de elementos en los que podemos trabajar en un momento dado. Esto favorece varias cosas: Por un lado, introduce una restricción en el sistema, no podemos tener trabajo infinito y nos permite medir; por otro, mejora el foco del trabajo que estamos haciendo. Nos centramos en terminar el trabajo empezado en lugar de seguir empezando trabajo. El tercer factor es que mejora el ratio de entrega.

Además, en el momento en el que introducimos WIPs, podemos empezar a considerarlo un sistema Kanban. Para ello, tenemos dos puntos importantes. Un punto de commitment, en el cual decidimos que vamos a hacer el trabajo y un punto de delivery, que es el siguiente que tenga un límite infinito, en el cual vamos a entregar ese trabajo. La diferencia de tiempo entre uno y otro es el cycle time, que nos indicará cuanto tiempo ha estado ese elemento en proceso. Entre el WIP, el Cycle Time y el Average Customer Lead Time existe una relación llamada Ley de Little. Puedes leer más en el artículo sobre métricas ágiles.

Políticas explícitas

Otra práctica imprescindible del método Kanban es hacer explícitas -transparentes- las políticas del sistema. ¿Quien es el responsable de mover los elementos de trabajo? ¿Cuando se revisa el tablero? ¿Cuales son las reglas para cambiar el sistema?

Las políticas son decididas por aquellos cuyo trabajo se ve impactado por el tablero. No hay un Scrum Master, Kanban Master o Flow Manager que decida cuales son las políticas, sino que estas son diseñadas a imagen y semejanza del proceso actual. Uno de los principios de cambio de Kanban es: empieza con lo que tienes; esto es, diseña el sistema para que refleje los procesos actuales, y una vez que lo domines, entonces empieza a mejorarlo colaborativamente.

Es por ello que la selección de políticas debe hacerse por aquellos que son responsables de realizar el trabajo. Las políticas son variadas y de muchos tipos. Pueden existir políticas por columna (Quien mueve que, como se deciden las prioridades), políticas para todo el sistema (Cuando se hacen replenishments, como se revisan los ítems) o políticas por clase de servicio.

Clases de servicio

Las clases de servicio son una clasificación de los posibles ítems de trabajo que pueden surgir. La práctica es identificar aquellos ítems que sean más críticos basados en su Cost of Delay. El Cost of Delay significa: ¿Cuanto me costaría si este ítem que tengo que entregar en esta fecha estuviera retrasado? La razón de tener clases de servicio es que no todos los ítems de trabajo tienen que estar en fecha. Algunos son importantes pero no urgentes. Otros son desechables pero hay que hacerlos. Otro son importantes por quien los pide.

En la imagen podemos apreciar 6 clases de servicio distintas. Cada una de ellas tiene documentado un Cost of Delay distinto del que el equipo es consciente a la hora de priorizar el trabajo.

Hay quien piensa que el método Kanban funciona bajo la teoría de colas. Y a pesar de que pueda parecer la explicación más sencilla, realmente es más como un concurso de belleza. En el método Kanban no se selecciona el trabajo dependiendo de su orden de llegada, sino dependiendo de su clase de servicio y cualquier otra política expresa que el equipo que hace el trabajo haya decidido. Eso hace que, por ejemplo, un ítem Intangible para este equipo se priorice muy bajo mientras que un ítem Expedite lo haga muy alto, teniendo incluso su propio carril.