Lean Kanban

Kanban Metric Layout (II)

En el primer post de la serie Kanban Metric Layout hablamos sobre los indicadores más importantes. En este post vamos a ver las gráficas dónde podremos ver e interpretar esos indicadores.

Gráficas

Cumulative Flow Diagram (CFD)

El CFD es una gráfica muy completa que nos permite leer multitud de indicadores y analizar tendencias.

Lead time: Si trazas una línea horizontal desde la línea que representa el punto de compromiso hasta la línea que representa que el elemento está entregado tendremos el Lead Time Medio medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).

Cycle Times: Podrás obtener el cycle time medio aproximado si trazas una línea horizontal desde dónde empezamos el trabajo (In progress en el ejemplo) hasta que hemos terminado (ready to approval en el ejemplo).

Throughput: La pendiente de la línea de completados es el throughput medio en ese intervalo de tiempo.

WIP: Trazando una línea vertical desde el estado completado hasta el primer estado de trabajo de nuestro flujo obtendremos el WIP en ese momento.

Para equipos que aún no han limitado el WIP esta parte puede ser muy útil para establecer una conversación sobre el tema (extra: ¿Cómo elegir un buen WIP limit?). La relación entre WIP, Lead TIme y Throughput está queda bastante clara en el CFD:

Para que el Lead Time no se dispare debemos terminar el mísmo número de elementos que empiezo. De manera que las líneas en el CFD del trabajo comenzado y terminado deberían ser paralelas:

Si tenemos dos líneas divergentes significa que estamos empezando más trabajo del que estamos acabando, por lo que nuestro lead time aumentará y nuestra predictibilidad bajará. Esto es justo lo que intenta evitar Kanban limitando el trabajo en curso.

Cycle time Scattlerplot

Es la principal gráfica para visualizar y analizar los Cycle Times. Los equipos pueden fácilmente comprender las tendencias.

Una de las herramientas más poderosas de este gráfico son los percentiles. Son las líneas horizontales discontinuas que terminan en un porcentaje. La más alta de todas, la del 95%, significa que el 95% de los puntos de la gráfica están por debajo de esa línea. Estos percentiles nos permiten saber, por ejemplo, que el 50% de las veces el cycle time está por debajo de 7. También, con los datos que observamos en la imagen, si alguien nos pide un desarrollo en 16 días, estaremos en situación de decirles que se lo entregamos con un 85% de posibilidades en el plazo solicitado.

Además, se podían usar colores para distinguir entre tipos de trabajo, clases de servicio, etc… y tener datos de cada uno de ellos.

Histogram Cycle Time

Los histogramas son gráficas claras y sencillas de leer. Por eso, el histograma de Cycle Time es muy utilizado.

Los datos que podemos ver son los parecidos a los del Cycle time Scattlerplot pero agregados por frecuencia. Esta vez, en vez de ver toda la nube de puntos observaremos la frecuencia de cada uno de los valores de cycle time

Tal y como nos pasaba con el Scatterplot, el histograma nos permite entender como funciona nuestro Cycle Time, detectar valores anómalos y observar percentiles. La gran diferencia es que este gráfico, al no tener un eje temporal, no nos permite analizar tendencias. Pero, para muchos, es el que muestra los datos de forma más clara y permite analizar los datos de forma más sencilla.

Throughput Run Chart

Para analizar tendencias en nuestro Throughput podemos usar un Run Chart dónde podremos ver los elementos terminados por unidahttps://www.pqsystems.com/qualityadvisor/DataAnalysisTools/run_chart.phpd de tiempo. Esto, junto con el trazado de una línea de la media, nos permite ver claramente tendencias en nuestro Throughput.

En el siguiente ejemplo podemos ver los elementos terminados en 100 días agregados por semana.

Aging Work in Progress

La edad de los ítems dentro del sistema es uno de los datos más usados a la hora de tomar decisiones pull. Es importante tener en cuenta cuando entraron en el sistema para intentar garantizar los SLA o SLE.

Si además le añadimos zonas de riesgo por colores podremos ver de una forma muy visual aquellos ítems que están en riesgo.

En el siguiente ejemplo vemos el Work Item Age (los puntos) para los elementos dentro del sistema. Además, vemos 5 estados diferentes en nuestro workflow y, para cada uno, tenemos las zonas de menor riesgo (verde) hasta la zona de mayor riesgo (roja). Con esta información podemos saber que en el último estado hay dos elementos en zona de riesgo medio, y dos en zona de riesgo más alto. Cuando hablamos del último estado suele ser fácil saber este tipo de situaciones. Pero la potencia de esta gráfica radica en que ahora sabemos que el ítem en la primera columna está entrando en zona de riesgo alto. Y que en la segunda ya tenemos dos que han entrado y debemos tener una conversación sobre qué hacemos.

Además, esta gráfica suele venir con nuestros amados amigos: los percentiles.

Conclusiones

Me gusta pensar en Lean Kanban como una manera de profesionalizar los servicios que un equipo ofrece a sus peticionarios. Esto nos exige continua mejora y la búsqueda constante de nuestra predictibilidad. Solo midiendo las métricas correctas podremos asegurar un flujo continuo, estable, altamente previsible y potencialmente mejorable.

Espero que os sean de utilidad estos posts. ¿Echas de menos alguna métrica o indicador? No dudes en compartirlo con nosotros en los comentarios.

Kanban Metric Layout (I)

El objetivo de estos dos posts es establecer el punto de partida sobre un marco de trabajo de métricas para equipos que estén bajo el método Kanban.

La guía viene separada en dos grandes secciones:

Indicadores: Qué es lo que queremos medir (primer post).
Gráficas: Donde podremos ver estos indicadores y cómo poder interpretarlos (segundo post).

Indicadores

Introducción

Cuando hablamos de indicadores usualmente se utilizan términos como leading y lagging. ¿Pero qué significan?

Lagging indicators suelen ser “output oriented”, fácil de medir pero difícil de mejorar o influenciar, mientras que los leading indicators suelen ser “input oriented”, difíciles de medir pero fáciles de influenciar.

Pongamos un ejemplo. Imagina que nuestra meta personal es perder peso. Un lagging indicator claro que es fácil de medir. Te subes en la báscula y obtienes la respuesta al momento. Pero … ¿como podemos alcanzar nuestra meta? Para perder peso podemos establecer dos “leading indicators”:

1.- Calorías tomadas

2.- Calorías quemadas

Estos dos indicadores son fáciles de influenciar pero difíciles de medir. Cuando pides en un restaurante la cantidad de calorías no están señalizadas en el menú. Y la mayoría de las personas no tenemos ni idea de cuántas calorías quemamos a lo largo del día.

También te puede ayudar a pensar en la diferenciación en que los leading indicators suelen ser de actividad, y los lagging indicators de resultado.

WIP (Work In Progress)

El número de elementos de trabajo empezados pero no terminados.

Aquí no estamos hablando del WIP Limit (extra: ¿Cómo elegir un buen WIP Limit?) . El WIP Limit es una política que los equipos utilizan para crear un sistema Kanban restringiendo la capacidad máxima de su sistema. La meta del WIP Limit es reducir la cantidad de trabajo en progreso (WIP).

El objetivo de dar transparencia al WIP es mostrar a Stakeholders, e incluso a toda la organización, como la reducción de WIP impacta en las demás métricas.

Una buena manera de observar el WIP es utilizar el Cumulative Flow Diagram (CFD).

Customer Lead Time

La cantidad de tiempo transcurrido desde que un elemento de trabajo es solicitado por un peticionario y un elemento de trabajo está disponible para el usuario.

Este es el tiempo que más interesa al peticionario. El Customer Lead Time está compuesto por cycles time parciales (dentro de cada estado del workflow) y de waiting states entre un paso y otro. ¡Ojo! El Customer Lead Time puede depender de más de un equipo por lo que el workflow total está compuesto por el workflow de diferentes equipos.

Lead Time o System Lead Time

Es el tiempo que transcurre desde que un ítem de trabajo entra en un punto de compromiso hasta que se entrega.

El punto de compromiso suele recibir el nombre de seleccionadas, ready o next.

La gran mayoría de las veces las prioridades de un servicio no están estipuladas por el equipo si no por la organización. Imaginemos que un peticionario realiza una petición “A” con una prioridad 3 sobre 5, siendo 1 la más baja y 5 la más alta. Pero cuando el equipo ejecuta el siguiente replenishment ha llegado otra petición “B” con prioridad máxima 5. Esto deja fuera del sistema a la petición A alargando su Customer Lead Time.

Este es el motivo por el que un equipo se compromete a tener un lead time lo más estable posible y suficientemente bajo y muchas veces no puede comprometerse con un Customer Lead Time. El Lead Time representa el tiempo que el trabajo está en la zona que pertenece al equipo. Mientras que el Customer Lead Time depende de factores que escapan al equipo y puede dispararse por razones externas como un cambios de prioridades.

Esta métrica es un “lagging indicator” de flujo. Está disponible sólo cuando un elemento está ya terminado desde la perspectiva del workflow. Normalmente se utiliza, junto con el Cycle Time, para impulsar trabajo de mejora, así como para poder establecer expectativas internas / externas en cuanto al tiempo de respuesta del equipo en elementos específicos.

La métrica más usada para observar el Lead Time medio aproximado es el Cumulative Flow Diagram.

Lead Time medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).

Cycle Time

La cantidad de tiempo transcurrido entre que un elemento de trabajo “comienza” desde que pasa un punto de commitment y un elemento de trabajo “termina”. En la siguiente imagen por ejemplo desde que entra en desarrollo hasta que está terminado. También puedes tener cycle time parciales por cada uno de los estados del workflow.

La gráficas más usadas para visualizar y analizar los Cycles Times son:

Throughput

El número de elementos de trabajo “terminado” por unidad de tiempo.

Nótese que la medición del throughput es el número exacto de elementos de trabajo, sin ningún tipo de compensación por el tamaño del mismo. El throughput se puede medir en cualquier paso del workflow y generalmente se utiliza el final del mismo.

El throughput se puede observar utilizando:

Run chart
Cumulative Flow Diagram

Work Item Age

La cantidad de tiempo transcurrido entre cuando se inició el trabajo y la fecha actual.

Work Item Age complementa el Cycle Time. Si el Cycle Time es un lagging indicator relevante sólo para elementos terminados, Work Item Age es un leading indicator solo relevante para los elementos aún en desarrollo. La idea principal de este indicador es proporcionar transparencia sobre qué ítems están fluyendo correctamente y cuales están algo “atascados”, incluso si no están formalmente bloqueados.

El Work Item Age debería ser transparente en el ticket de cada elemento para facilitar buenas decisiones pull. Además, podremos consultarlo en el Aging Work In Progress.

Medir el Work Item Age permite también reducir los riesgos y mejorar la predictibilidad, mejorando la eficiencia global del sistema.

En el siguiente post vemos las gráficas donde analizar estos indicadores. ¡No te lo pierdas! Pulsa aquí para ir directo

Upstream: Flujo de generación de opciones

En los artículos anteriores de esta serie dedicada a Lean Kanban hablamos de:

• ProtoKanban: Qué es y sus beneficios.
• Downstream, ¿cómo ir más allá de ProtoKanban?

En ellos vimos como, entre otros beneficios, el método Kanban puede ayudar a los equipos a aumentar la tasa de entrega, reducir lead times, y todo ello desminuyendo la sensación de sobrecarga.

Si no estás familiarizado con conceptos como WIP limit, lead times o tasas de entrega te aconsejo que les eches un ojo a los anteriores artículos antes de seguir leyendo.

Y en tu empresa…. ¿cómo se toman las decisiones?

Standish Group tiene una base de datos con más de 1.000 organizaciones y 50.000 proyectos. Todos los años publica el informe “CHAOS Report” dónde plasman sus conclusiones sobre como impactan en el éxito o fracaso de los proyectos diferentes factores, como pueden ser madurez de los equipos, metodología de trabajo, skills de los miembros del equipo, etc… En el último CHAOS Report nos contaron que el factor que más impacta en el fracaso o éxito en un proyecto es la latencia que existe a la hora de tomar decisiones. Según sus números, el 58% de los proyectos con buena latencia de toma de decisiones tienen éxito. Solo el 9% de los proyectos con mala latencia llegan a buen puerto.

Como agilista, me parece que tiene todo el sentido del mundo. Si la mentalidad Agile se basa en la aceptación de la incertidumbre y su manera de abrazarla es la continua adaptación, una empresa con más capacidad de tomar decisiones será más adaptativa, más ágil, y tiene más posibilidades de llevarse el gato al agua.

Siempre me ha llamado la atención que en muchas empresas de las que he visitado la decisión del qué hacer, ya sea en un producto o un servicio, se queda relegada a las personas más ocupadas de las empresas y se confía que casi en pocos minutos (y en su tiempo libre) sean capaces de tomar las decisiones acertadas. Y eso si tienen tiempo de reunirse, claro.

Inanición del downstream

Una consecuencia de no gestionar ni dar visibilidad a la generación de ideas, y que pasa en un altísimo porcentaje de implantaciones de Kanban, es lo que conocemos como el “downstream starvation” (inanición del downstream).

Una vez que nuestro flujo de ejecución o downstream comienza a trabajar con Lean Kanban, a gestionar su demanda y a tener las conversaciones correctas ayudados por la limitación del WIP, la mayoría de los tiempos de espera y cuellos de botella vienen por parte de los usuarios, los representantes del usuario en el equipo, o las personas de negocio (latencia en la toma de decisiones). En definitiva, las personas que deciden el “qué”. Esto empieza a provocar que el downstream se va quedando algo ocioso, o trabajando en tareas cuyo valor de negocio es bajo. Algo que no interesa económicamente a la empresa.

Kanban, ¡ayúdanos!

Kanban puede ayudarnos en toda la cadena de valor del servicio y, por supuesto, en el flujo de decisión de qué se va a hacer, o upstream.

Hasta ahora habíamos hablado sobre el downstream, pero si tiene sentido aliviar el downstream de la sensación de sobrecarga, ¿no tendrá sentido alivar de una sobrecarga similar a los trabajadores creativos de nuestro upstream, esos quienes deben descubrir los conceptos e ideas a implementar?

El upstream existe tanto en servicios como en productos. Y no te obliga a que el downstream deba ser gestionado con Kanban. Puedes trabajar con Kanban tu upstream y gestionar con Scrum, o cualquier otro método o framework la ejecución.

Visualizando y creando el flujo upstream

Lo primero que tenemos que hacer es visualizar cuál es nuestro flujo de upstream y como se relaciona con nuestro downstream. Algo como:

Además, limitaremos el WIP para crear un sistema pull.

Tasas de descarte

En el flujo downstream la tasa de descarte suele ser casi nula. Una vez que un elemento llega al punto de commitment del equipo (en este caso ready to start) la inmensa mayoría de elementos completarán el flujo conforme la capacidad del sistema lo vaya permitiendo.

Pero nuestro flujo upstream no debería comportarse de esta manera. En cada etapa de nuestro flujo de ideación, hay una oportunidad de descartar una mala idea: demasiada cara; tomará demasiado tiempo; o nuestros clientes no quieren ni necesitan esto.

Si todo lo que se te ocurre lo estás metiendo en tu producto o servicio, puede significar que no estás generando suficientes opciones para darte cuenta de las malas ideas y quedarte solo con lo que da más valor al usuario y, por lo tanto, más reveniew para tu empresa. Una buena gestión de opciones lleva asociada una tasa de descarte.

Acoplando upstream y downstream

Nuestro sistema downstream funciona con un flujo estable de tarjetas que viajan por los kanban que van quedando disponibles (recordad que en este caso los kanban son los huecos libres que nos dan la señal de que podemos acometer más trabajo). Trabajar con WIP Limit es lo que provoca justamente este flujo, ya que hace entrar en el sistema la misma cantidad que sale. Podemos verlo como una tubería perfectamente sellada dónde la misma cantidad de agua que entra, sale. El caudal existente en nuestro sistema vendrá regulado por el WIP limit.

Pero en el sistema upstream no tiene esta naturaleza. En él se descartan ideas por el camino. Es como una tubería con goteras entre las diferentes fases que puede tener ( necesidad detectada, análisis, diseño, etc… ).

¿Cómo podemos enfrentarnos a esta situación y prevenir que nuestro downstream se quede sin comida? Introduciendo en nuestro upstream un WIP mínimo o un número de opciones mínimas (además del WIP limit). De esta manera nos aseguramos que el caudal de nuestra tubería es lo suficientemente alto para contrarrestar las goteras, y dejar listos un mínimo de elementos de dónde el downstream pueda tirar.

Ahora tenemos dos palancas para jugar e intentar acoplar con éxito estos dos sistemas: las opciones mínimas del upstream y el WIP limit del downstream.

Conclusión

Implementar Lean Kanban en ejecución muchas veces es insuficiente de cara al usuario final. Lo importante es que el tiempo desde que se detecte una necesidad hasta que la solución esté implementada no se dilate. Para conseguir esto, debemos crear flujo tanto en la ideación (upstream) como en la ejecución (downstream).

Como nuestro flujo upstream debe tener una tasa de descarte, introducimos el nuevo concepto de “WIP mínimo” u “opciones mínimas” para asegurarnos de que el número de opciones que llegan a nuestro downstream son suficientes para mantener su flujo lleno.

Visualizar este flujo e imponer un mínimo de elementos activos puede ser una palanca que deje aflorar un posible problema de toma de decisiones dentro del proyecto. La exigencia del WIP mínimo muchas veces ayuda a los equipos de decisión, comités, etc… replantearse su estrategia de gestión.

El primer tablero Kanban del equipo

Desde la experiencia con varios equipos, hoy me gustaría hablarte de la evolución de un tablero Kanban concreto. Es cierto que las decisiones de unos equipos a otros no se parecen, ni las necesidades o su trabajo. Pero he vivido una serie de momentos que se repiten en el tiempo. Algo así como El día de la marmota para un Agilista

Podríamos llamarlo “los primeros escalones” cuando un equipo empieza a usar cualquier metodología, marco de trabajo o mentalidad Agile. Y el tablero es una de las herramientas más valiosas como comentaba en mi artículo anterior.

De menos a más

Todos empiezan con algo muy sencillo, normalmente por consejo del Scrum Master o el Agile Coach que les esté acompañando. Entonces, lo primero será visualizar el flujo de trabajo del equipo en cuestión. El equipo prepara un tablero y te enseña esto:

Ahora es cuando te toca hacer preguntas. ¿Solo tenéis 3 pasos en vuestro flujo?¿Quién pone esas tarjetas ahí?¿tienen orden alguno o prioridad?… pero voy a hablar de la primera para empezar.

Visualiza tu workflow o flujo de trabajo

Al principio los miembros de un equipo tienen oxidado este tipo de análisis. Porque no suelen analizar como trabajan, sino el trabajo en sí. Así que, a ti, que estás intentando ayudarles a crear un tablero Kanban útil, te costará muchas preguntas, algunos momentos incómodos, un poco de presión y mucha paciencia.

Tras una buena charla con todos los miembros del equipo, incluyendo siempre al Product Owner o Manager que tiene visión de negocio, se han añadido nuevas columnas. Ahora en algunos de los miembros del equipo puedes ver cierto brillo en los ojos, ¡incluso alguna sonrisa!. Esto se debe a que han tratado temas que les suelen doler, porque se atascan, donde no tienen mucho poder y ahora es visible. Así que el equipo trae esto:

Evitemos el caos

Ahora sabemos que hay más pasos en el flujo de trabajo. Pasos que son importantes porque se toman decisiones que no son solo técnicas, sino de negocio.

Al final muchos equipos deciden meter una columna de “Test” para la comprobación de que todo está como debería, pero pocas veces se trata de un test técnico. Es algo que al principio me sorprendía, ahora ya se que es uno de esos “primeros pasos”. Duele menos llamar así a la comprobación del Manager o el PO de que ese item es lo que ellos habían pedido.

Añadir WIP limits al tablero kanban

Como puedes observar, en el segundo tablero, hay mas columnas con el mismo número de tarjetas. Y casi todas las subtareas técnicas están en la columna “test” provocando de esta manera, un pequeño embudo que acumula tareas sin terminar. Por otro lado, todas las subtareas ya están en proceso o en test, pero algunas no se están avanzando. Toca sesión de preguntas incómodas de nuevo. ¿Esto es real? ¿se está trabajando en todas y cada una de las subtareas?

Si queremos que el tablero kanban sirva para algo y nos haga mejorar, hay que cambiar de mentalidad. Kanban nos ayuda a trabajar con una mentalidad pull y evitar el empezar mucho y acabar poco.

Hace unos días, mi compañero Nacho Navarro publicó un post interesante que te recomiendo acerca de elegir los WIP limit. Básicamente un WIP limit es un límite del trabajo activo que puede existir. Se puede limitar por columnas, por personas, el sistema completo, etc.. Por ejemplo, un equipo con 3 desarrolladores podrían decidir que no hubiera más de 3 tareas en curso en la columna “doing” a la vez. De esta forma nos asegurarnos de que creamos un sistema pull real.

Gestión del flujo de trabajo

Es importante que el mensaje de la mentalidad pull haya calado. En este tablero mejorado vimos muchos cambios:

Priorización de los elementos y sus tareas.
Orden para terminar más trabajo que antes.
Problemas de estancamiento o embudos.
Posibles necesidades de mejora para el tablero del equipo.
Métricas. Ahora podemos medir cuánto tardamos en entregar algo.

Políticas explícitas para usar bien el tablero

Esta vez, y solo para evitar tentaciones, hay que añadir las reglas del juego. Si queremos que esto funcione de verdad, necesitamos ser legales. Nada de decir que una tarea está “casi hecha” en la columna de “Done”.

Estas son una serie de requisitos que una subtarea debe cumplir si queremos pasarla a la siguiente columna. Si no los cumple, no está lista para pasar a la siguiente columna. Del mismo modo que si la columna siguiente tiene el WIP limit ocupado, tampoco puede pasar aunque las políticas se cumplan.

Esto nos ayuda a funcionar mejor con el sistema pull de Kanban. Así nos centramos en acabar el trabajo ya empezando en lugar de empezar otra tarea nueva. El equipo entendió que era necesario poner unas políticas explícitas en cada columna de paso. Así se aseguraban un mínimo en la nueva columna. El tablero quedó así:

Mejora continua de verdad

El último paso también es muy importante, ya que nos permite ir viendo estas evoluciones a lo largo del tiempo y los proyectos. Un ejemplo de ello es que en este último cambio, también añadieron algunas clases de servicios con diferentes colores en las tarjetas. Así se aseguraban que si alguna tenía fecha fija o era prioritaria, la vieran antes. Es necesario tomarse un tiempo de reflexión de todo el equipo en conjunto para tratar posibles mejoras.

Por supuesto esto es una versión reducida de un sistema que se puede complicar todo lo que necesitemos. Para ello podéis pasaros a leer la guía de Kanban que tenemos en la web, que es muy completa.

Espero que te sirva de inspiración este pequeño resumen en base a mi experiencia. En próximos post escribiré otros ejemplos, hablaremos de las tarjetas Kanban y de posibilidades dentro de un tablero kanban.

Cómo elegir un buen WIP Limit

El agilismo es una mentalidad, una manera de entender el desarrollo de software que cuando te sumerges te va salpicando poco a poco en muchos aspectos de la vida.

Cuando comenzaba en esto de las formaciones uno de los principios ágiles por los que pasaba rápidamente por encima era:

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.”

Cuando estuve ayudando a nuestros amigos de Product Hackers me tocó ponerme el gorro de Product Owner y este principio al que no le daba mucha importancia… se convirtió en mi preferido. Sólo en el momento en el que todas las piezas encajaron a nivel equipo, empresa, cliente, etc… y conseguimos un entorno de desarrollo sostenible y constante, empezamos a entregar valor de verdad y satisfacer las necesidades prioritarias de nuestros clientes una y otra vez creando una relación de confianza que nos permitió alcanzar grandes éxitos.

Wip limit: Creando el espacio

Una vez me hicieron la pregunta: “Si tenemos una capacidad máxima de delivery, ¿cómo que no limitamos la capacidad de entrada?”

Más o menos me quedé así:

Y es que…. ¿sirve de algo meter más trabajo del que va a salir en un sistema? Si tengo una depuradora de agua en mi piscina… ¿le intentaría meter más agua de la que es capaz de depurar para intentar depurar más? Si lo que quiero es pagar una gran factura de reparación y una mirada incrédula de un técnico de depuradora… entonces puede que sí.

Y es que limitar el WIP es precisamente lo que nos permite que nuestro sistema sea estable y constante en el tiempo. Es como una tubería donde solo entra caudal si sale.

WIP limit: La palanca magica

Hubo un señor que demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. Ahora estaréis pensando…¿y por qué me cuestas esta gran anécdota Nacho? Pues porque este señor se llamaba Little, y esta es la ley de Little y es la base de Kanban:

Como vemos, el WIP es la relación entre el lead time y el throughput rate o delivery rate. También podemos ver como afecta el WIP al lead time mirando un CFD (Cumulative Flow Diagram):

¿Cómo elegir mi WIP Limit?

La relación entre cuanto menos WIP menos lead time está clara con la ley de little o el CFD. Así que alguien puede pensar… ¡pues pongo 1 de WIP limit! Eso nos deja la paradoja del One piece flow dónde te aseguras que cuando una tarea entra en el sistema sale muy rápido, pero tu delivery rate se verá afectado y será muy bajo. ¿Esto es malo? ¿esto es bueno? Pues ni bueno… ni malo… en algunos entornos necesitarán un tiempo de respuesta muy rápido y no les importará tanto la tasa de entrega y en otros entornos necesitarán un equilibrio mayor.

En una de mis vidas pasadas colaboraba con un cliente muy tradicional dónde había una pequeña galia trabajando con Kanban y funcionando muy bien. Ellos querían poner en producción al menos una vez a la semana. Pero esta empresa solo permitía subir una vez al mes. En esta situación…. ¿un lead time de 1 o 2 días me ayuda? ¿O puedo pensar en abrir un poco el WIP, aumentar un poco el lead time, pero subir el delivery rate? La capacidad de absorción de nuestros clientes es un factor a tener en cuenta también.

Creo que este vídeo explica muy bien como puede ser una búsqueda de el WIP deseado (Nota: en el vídeo se habla de cycle time que es el tiempo que está la tarea desarrollándose. El Lead Time es el tiempo desde que me comprometo hasta que lo entrego. Como es de suponer, están estrechamente relacionados)

En definitiva, hay que encontrar un equilibrio entre el Lead Time y el Delivery Rate.

¿Cómo elijo mi primer WIP limit?

¿Cómo elijo ese primer WIP limit que mediré, inspeccionaré y adaptaré si aún no tengo métricas?. El primer WIP limit habrá que elegirlo según la experiencia de los miembros del equipo o con consejo externo. Lo importante es tener una mentalidad empírica para inspeccionar y adaptar así que tampoco me volvería loco eligiéndolo.

Una frase que a mi me sirvió: “El WIP limit debe doler”. Es una restricción. Muchas veces los equipos tienen a pensar… si somos 4… y cada uno puede con 2 o 3 cosas a la vez… ¡pues pongamos 10! Como ya he dicho antes este número no está ni bien ni mal. Habrá que medir, inspeccionar y adaptar si hace falta. Pero una primera elección que nos duela suele resultar más acertada la mayoría de las veces. Como probar uno por persona en todo el sistema. Pero como vimos antes, cada entorno es un mundo y persigue diferentes métricas.

¿Qué pasa si cambio el WIP limit?

Imaginemos que quieres bajar el Lead Time porque quieres ganar predictibilidad y poder asegurar un SLA más bajo. En ese momento decidís bajar el WIP limit. Ahora te tocará esperar a que el sistema se vacíe para ver como funciona. Es como si tienes una cisterna de 5 litros y la cambias a una de 3. No podrás ver como se comporta el nuevo sistema hasta que se vacíe y se llene de nuevo. Es un proceso que pasará de forma natural y no requiere ningún esfuerzo extra que no sea respetar vuestras reglas y paciencia.

Conclusiones

Limitar el WIP es un arma muy poderosa para crear un entorno sostenible. Siempre es difícil elegir el primer WIP, pero hay que acordarse de que:

Se puede cambiar en cualquier momento. Siempre que se esté persiguiendo la mejora del sistema y no una auto-trampa para eliminar una restricción que nos molesta.
Hay que tener en cuenta la capacidad de absorción de nuestros clientes
Es una restricción y como tal, la primera vez que lo estipulamos, es buena señal si nos duele.
Hay que mirar (al menos) nuestras métricas de Lead Time y de Throughput para ir equilibrando entre ellas cambiando nuestro WIP si fuera necesario.
Una vez cambiado el WIP Limit, el impacto no es inmediato.