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.
[…] es difícil de realizar por persona pero es tremendamente sencillo de hacer por equipo. Limitando el WIP -el número de elementos en los que el equipo Scrum trabaja a la vez-, crearemos un espacio de […]