https://jeronimopalacios.com/kanban/Este es el segundo artículo de una serie dedicada a la introducción de Lean Kanban en organizaciones. Si no lo has hecho ya, es recomendable empezar leyendo Proto-Kanban: Qué es y sus beneficios donde hablé sobre como la visualización y una mentalidad pull podían ayudar a un equipo que está empezando en esto de Kanban.
¿Como ir más allá de Proto-Kanban?
Con Proto-Kanban hemos empezado a tener una mejor visualización de nuestro sistema y estamos empezando a gestionar trabajo y no personas. Pero aún estamos lejos de tener un flujo de trabajo real. ¿Cómo continuar?
Nuestra mentalidad pull nos ha ayudado a mejorar el lead time y la tasa de entrega. Pero esto no es suficiente. En nuestras formaciones vemos una y otra vez que existe una gran tendencia a hacernos auto-push y cuando la demanda crece, tenemos elementos con fecha fijada o urgentes, el acto reflejo es empezar a meter y meter trabajo en nuestro sistema colapsándolo.
Lo único que conseguirá sobrecargar un sistema por encima de su capacidad es tener mucho trabajo empezado y nada terminado. Esto es un desperdicio de tiempo y dinero, aumentará el lead time, disminuirá la capacidad de adaptación de nuestra empresa y de entregar a sus clientes lo que necesitan cuando lo necesitan.
Para crear un sistema pull completo vamos a utilizar algunas de las prácticas de Lean Kanban:
- Limitar el WIP
- Políticas explícitas
- Clases de servicio
- Feedback loops
Limitando el WIP (Work in Progress)
Llegó el momento de dar un paso más, ir de la mentalidad pull adquirida con Proto-Kanban a un sistema pull con trabajo limitado. Estableciendo WIP limits en nuestro sistema nos aseguramos que esa tentación de auto-push desaparece porque ahora nuestro sistema, sencillamente, no lo admite.
Establecer WIP limits no es más que limitar el trabajo en curso en nuestro sistema. Podemos poner un límite para todo el sistema (no puede haber más de 6 elementos empezados), podemos poner límites por columnas, por persona, podemos combinar todos, etc…
En la imagen podemos ver los WIP limits representados en la cabecera de cada columna por un número rodeado de un círculo.
Esta limitación permitirá al equipo:
- Reducir aún más la sensación de sobrecarga
- Focalizarse en lo realmente importante en ese momento
- Entregar con mayor calidad
Esta calidad bajará drásticamente el número de elementos mal acabados que vuelven a entrar en el sistema (re-work), lo que impactará positivamente en el lead time, en la tasa de entrega y en lo más importante, la satisfacción del cliente.
Además, limitar el WIP nos permitirá crear un sistema sostenible en el tiempo ganando predictibilidad basado en datos y no en estimaciones u opiniones. Lead times medios, cycle times, etc…
En este post hablamos sobre qué hay que tener encuenta para elegir un buen WIP limit.
Haciendo las políticas explícitas
Hemos creado un flujo de trabajo pero… ¿cómo funciona? ¿quién mueve qué? ¿cómo se deciden las prioridades? ¡Las políticas explícitas acuden al rescate!
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.
Las políticas deben estar visibles en todo momento. Algo que ayuda a los equipos a hacer explícitas las políticas es pensar que cualquier persona que pase por delante del tablón debe entender perfectamente como funciona el sistema al completo.
Es común en los equipos que están empezando intenten crear políticas nuevas que son más bien buenas intenciones que una política de funcionamiento. Esto desemboca en post-its gigantes con una norma que nadie está cumpliendo, generando frustración y la sensación de que la visualización puede ser algo que no es tan importante mantener. Es fundamental que el equipo entienda que las políticas:
- Deben ser escasas
- Simples
- Estar bien definidas
- Visibles
- Las políticas no son un deseo, deben aplicarse siempre. Hay que ser realistas e inspeccionar si la estamos usando, si no, por qué no, etc…
- Tienen que ser fácilmente modificables
Clases de servicio
Para poder gestionar el flujo correctamente es importante conocer el coste del retraso (cost of delay) de los elementos de trabajo. Debemos saber qué ítems son importantes, urgentes, con una fecha dada, etc… Kanban utiliza cuatro arquetipos para definir como cambia el valor del ítem de trabajo según su coste de retraso:
En la imagen podemos ver como evoluciona el coste del retraso o el impacto según pasa el tiempo.
- Urgente: El coste del retraso crece y crece desde el primer día de forma lineal con una gran pendiente. Lo necesito, lo necesito ya y cada minuto cuenta.
- Fecha fija: Al principio, el coste de retraso es bajo. Pero a partir de una fecha el coste de retraso es altísimo. Por ejemplo, si te piden una campaña de marketing para el blackfriday.
- Estándar: Crece casi de forma lineal y constante en el tiempo. Suelen ser las más comunes en un sistema.
- Intangible: Los ítems de clase intangible pueden ser importantes y valiosos, pero no hay costo de retraso tangible asociado con ellos en el futuro cercano.Lo que pasa con los ítems de esta clase es que un día estallan y el coste de retraso se dispara y se comportan como una urgente.
Pero cada sistema es un mundo y por tanto, el equipo debe encontrar las clases de servicio que mejor se ajusten a su sistema. Hay equipos que han llegado a definir una clase de servicio con el nombre de su CEO. Y una política asociada a esta clase de servicio que rezaba: “No empezaremos nunca un ítem de trabajo bajo esta clase de servicio hasta después de una semana”. Este CEO era especialista en pedir cosas muy urgentes y luego… arrepentirse. Como vemos, la combinación de clases de servicio y políticas es muy poderosa y nos permite gestionar perfectamente nuestro flujo.
Hay un comportamiento que nos encontramos muchas veces: “He empezado con este elemento de trabajo por qué me apetecía”. Las clases de servicio, junto a las políticas definidas, nos ayudan a eliminar la subjetividad y la procrastinación a la hora de elegir qué elemento de trabajo comenzar. La elección ahora tiene unas reglas objetivas que todo el equipo conoce, entiende y han establecido de mutuo acuerdo.
Feedback loops
El Agilismo se basa en el empiricismo por lo que no debemos olvidar los procesos de inspección y adaptación. Kanban define hasta siete cadencias con diferentes objetivos. Esto puede provocar rechazo por parte del equipo por la sensación de sobrecarga de reuniones. A nosotros nos da buen resultado empezar con la Daily Kanban y un Replenishment meeting semanal. Poco a poco, los equipos van teniendo necesidades que encajan con los objetivos de las otras cadencias y van sumándolas. Escribiré otro post para tratar exclusivamente de las cadencias.
¿Cómo podemos medir nuestro impacto?
Lo ideal es tener un histórico de métricas del equipo para poder comparar. Pero al menos, con Proto-Kanban ya deberíamos tener:
Lead time medio:Tiempo desde que nos comprometemos a tener una tarea hasta que la entregamos.
Cycle time medio: Tiempo que la tarea está desarrollándose.
Tasa de entrega: Cantidad de ítems entregados en unidad de tiempo.
Es importante medir, al menos, estas tres. A mi me gusta también introducir el customer lead time que es el tiempo desde que un ítem entra en nuestro backlog hasta que se entrega. Al fin y al cabo, al cliente le interesa cuanto tiempo tardas en entregarle la tarea desde que se la pide al equipo.
Nos hemos encontrado empresas con lead times muy bajos y muy orgullosos. Pero luego, cuando indagabas, encontrabas tasas de entregas bajísimas. Habían estado eliminando las tarjetas que llevaban en el sistema mucho tiempo. De esta manera “camuflaban” su lead time real. Pero la tasa de entrega no engañaba. ¿Sirve para algo medir y autoengañarse?
Conclusion
Una vez que tenemos Proto-Kanban funcionando es el momento de introducir más prácticas para crear y gestionar un flujo de trabajo:
- Limitar el WIP
- Políticas explícitas
- Clases de servicio
- Feedback loops
Debemos recordar que Kanban se ocupa del diseño, la gestión y la mejora de los sistemas de flujo. Conseguir un sistema estable en el tiempo es solo el primer paso. El equipo debe seguir mejorándolo continuamente por lo que hay que medir, inspeccionar y adaptar.
Si quieres profundizar más puedes leer nuestra guía de Kanban o el Kanban esencial condensado de David J. Anderson y Andy Carmichael
Continuar leyendo: Upstream, flujo de generación de opciones >>