En la última entrada de este blog me di cuenta de que hace tiempo que he dejado de publicar contenido “técnico”. En realidad no es que haya dejado de publicar completamente, sino que había derivado todos esos contenidos a mi web. Tengo previsto agruparlo todo de alguna manera, pero lo cierto es que no está entre mis prioridades ahora mismo. Estoy muy centrado en la (r)evolución de eDreams OdigeO, donde el método Kanban está en el centro de todo lo que hacemos. De ahí que tenga mucho sentido que haga un pequeño resumen en este blog.
Sistema Kanban vs Método Kanban
Antes que nada hay que distinguir entre un sistema kanban y el método kanban.
Si buscamos Kanban en la Wikipedia: “También se denomina “sistema de tarjetas”, pues en su implementación más sencilla utiliza tarjetas (kanban) que se pegan en los contenedores de materiales y que se despegan cuando estos contenedores son utilizados, para asegurar la reposición de dichos materiales. Las tarjetas actúan de testigo del proceso de producción.”
El número de tarjetas puestas en circulación se corresponde con la capacidad del sistema. Cada una de estas tarjetas actúa como una señal visual que hace referencia a una unidad de trabajo determinada, por ejemplo, “instalar los asientos en el vehículo”. El operario podrá elegir el modelo de asiento correcto porque en el kanban que acompaña al vehículo en la cadena de montaje se indica de qué modelo de vehículo se trata.
Estas tarjetas se pueden representar, por ejemplo con post-its, en un tablero (tablero Kanban) y ayudarnos así a visualizar el estado de nuestra producción.
Los sistemas kanban tienen una relación muy íntima con los modelos de producción ajustada (o Lean Manufacturing) que, junto a la Teoría de las Restricciones (ToC), son un cuerpo de conocimiento fundamental para entender el método Kanban. Yo trato de no dejar pasar la oportunidad de hacer referencias a Lean y ToC siempre que puedo. Iré añadiendo más referencias a ambos en posteriores entradas de este blog pero, si puedes, echa un vistazo a los dos enlaces anteriores.
El método Kanban
El método Kanban fue desarrollado por David J. Anderson y actualmente hay mucha bibliografía al respecto. Al final de este artículo añadiré unas cuantas referencias.
Kanban es un método (no una metodología) poco prescriptivo, cuyo objetivo es ayudar a que una organización adopte poco a poco una cultura de mejora continua. Inicialmente aplicado en contextos de desarrollo de software, actualmente es posible aplicarlo a prácticamente cualquier negocio.
El origen de Kanban, según cuenta Anderson en su libro, es una experiencia personal visitando los Jardines del Palacio Imperial de Tokyo (Japón). Allí, a la entrada alguien entregaba a cada visitante una tarjeta de plástico que había que devolver a la salida. Anderson observó que, dado que el número de tarjetas era limitado, el flujo de asistentes a los Jardines también estaba limitado. Imagina una temporada de gran afluencia. Al estar limitada la entrada, se evitan colapsos dentro de los Jardines, con lo que, independientemente de la época del año, tu experiencia siempre es agradable. Eso dicen, al menos.
Los principios fundamentales
En casi toda las referencias podrás ver que los principios fundamentales de Kanban son tres:
- Visualiza
- Limita el trabajo en curso
- Gestiona el flujo
Sin embargo, en su libro, Anderson no habla de principios aunque sí presenta una receta para aplicar Kanban con éxito y que podría considerarse la lista de los principios fundamentales del método:
- Enfócate en la calidad
- Reduce el trabajo en curso
- Entrega frecuentemente
- Mantén un balance entre la demanda y la producción
- Prioriza
- Ataca a las fuentes de variabilidad para mejorar la predictibilidad
El autor sigue evolucionando el método, principalmente orientándolo hacia el escalado en grandes organizaciones, así que es posible que leas actualmente que los principios fundamentales son los siguientes:
Principios de gestión del cambio
- Empieza con lo que tengas ahora
- Acuerda buscar el cambio evolutivo
- Incita actos de liderazgo en todos los niveles
Principios de entrega de servicio
- Entiende y enfócate en las necesidades de tus consumidores
- Gestiona el trabajo (no a las personas)
- La organización es un ecosistema de servicios interdependientes
Personalmente creo que esa “receta para el éxito” es un conjunto de principios bastante bueno, entendiéndolos como guías para implementar el método, mientras que los “actuales principios” están más cercanos a unos valores al estilo del Agile Manifesto. En cualquier caso,personalmente no hago mucho caso a estos principios pues yo prefiero aplicar la combinación de los principios de Lean (tal y como los adaptan los Poppendieck al desarrollo de software) y de Agile (los del Agile Manifesto). Con ésos tengo de sobra para ayudar a crear equipos de alto rendimiento, a veces con Kanban y a veces con otros métodos.
Cómo hacer Kanban
Anderson identifica también una serie de características que se dan en todos los proyectos en los que se ha aplicado con éxito el método Kanban. De alguna manera podríamos considerar que son buenas prácticas ó prácticas recomendadas.
- Visualiza el flujo de trabajo
- Limita el trabajo en curso
- Mide y gestiona el flujo
- Explicita las políticas del proceso
- Usa modelos para reconocer oportunidades de mejora
En la práctica es muy fácil centrarse en la parte más mecánica del método y dejarse llevar por visualizar y medir. En mi experiencia, al tratarse de un método muy poco prescriptivo, requiere de una gran autodisciplina y de un esfuerzo aún mayor en los aspectos culturales que otros métodos, como Scrum, por ejemplo, que sí favorecen de una manera mucho más explícita valores como la colaboración o el feedback.
¿Por qué limitar el trabajo en curso?
Voy a tratar de hacer un resumen pues este asunto daría por sí solo para varios artículos.
Antes que nada, recuerda la historia de los Jardines del Palacio Imperial de Tokyo. Limitamos la cantidad de trabajo en curso para evitar que se degrade el servicio que realizamos. Además, también limitamos el número de peticiones en curso para reducir el tiempo medio de entrega de las peticiones. Esto, que puede parecer contraintuitivo, en realidad es la aplicación de la llamada Ley de Little. Esta ley de la teoría de colas enuncia que “en un sistema estable, el número medio de clientes (N) es igual a la velocidad media de llegada de peticiones (V), multiplicada por el tiempo medio que se tarda en dar salida a cada petición (T), o algebráicamente N = V x T”. De ahí podemos deducir que T (también llamado tiempo de ciclo o cycle time en inglés) será menor en tanto que limitemos N (también llamado trabajo en curso o WIP, del inglés work in progress). Si no te lo terminas de creer, quizás te interesará ver este video.
Al limitar el WIP e impedir que las peticiones viajen en el tablero Kanban hacia atrás, lo que estamos consiguiendo es que la demanda de los clientes y la capacidad de producción se equilibren dinámicamente.
Push vs pull
Solemos decir que el método Kanban es un sistema pull pues la demanda “tira” de la producción. Igual que en un supermercado, donde no reponemos la mercancía hasta que el inventario en la estantería no llega a un cierto límite, lo cuál provoca un pedido hacia el almacén, el cuál podrá, a su vez, desencadenar otro pedido si alcance un cierto nivel mínimo de inventario. Así, en un sistema pull los trabajadores retroceden hasta la estación anterior para retirar de ella los materiales y piezas que necesitan para procesarlos inmediatamente. Cuando se retira el material, los operarios de la estación previa saben que ha llegado el momento de comenzar a producir para reemplazar la producción retirada por la siguiente estación. Si la producción no se retira, los empleados de la estación previa detienen su labor. De este modo se evita tanto el exceso como el defecto en la producción. Se produce solo lo necesario, entendiendo como tal no lo que viene establecido en un plan, sino lo que los consumidores demandan. Por cierto, a ésto se le conoce en el mundo industrial desde los años 80 como sistema JIT (de just-in-time) y está dentro de lo que llamamos Lean Manufacturing.
Otro concepto de JIT que suelo explicar cuando aplicamos Kanban es el “Stop The Line” o Jidoka. Se trata de detener la producción cuando se detecta un defecto. En ese momento se identifica la causa raiz que provoca el defecto, se corrige y se vuelve a arrancar la producción. De esta manera nos aseguramos de que nunca más vuelva a aparecer ese defecto. O al menos que no lo haga por esa misma razón.
Aunque creo que la mejor manera de entender un sistema pull es recordando esta frase:
Stop starting, start finishing!
(Deja de empezar y empieza a terminar)
Cómo dibujamos el tablero
El tablero Kanban representa el proceso de trabajo, por ello cada columna será una actividad que añada valor al producto y que no necesariamente es realizado por una persona o departamento determinado. Esto último dependerá de cómo organicemos el trabajo.
Todo tablero Kanban tiene un principio y un final del proceso. Una unidad de trabajo aparece al principio del tablero y se va moviendo de columna en columna, siempre de izquierda a derecha (“río abajo”). El final del tablero indicará que la unidad de trabajo está acabada y no requiere más atención por parte del equipo. Cada columna estará etiquetada con su nombre.
El tablero Kanban más sencillo es el que tiene las columnas PREVISTO, EN CURSO y ACABADO. La primera es una cola, en la que se irá acumulando el trabajo que aceptamos (mientras no alcancemos al límite del WIP que hayamos establecido, si es que hemos establecido alguno). La última es un buffer o acumulador de trabajo acabado (o listo para la siguiente actividad, si la hubiera).
Hay actividades que pueden requerir una cola o buffer para desacoplarlas de la anterior o posterior. Por ejemplo, podemos tener una cola con peticiones de atención al cliente. Las iremos atendiendo en el orden de llegada y el límite de nuestro WIP será el número de peticiones que podemos atender simultáneamente sin degradar el servicio. Un aumento inesperado de las peticiones de atención al cliente se visualizará en un aumento del número de peticiones en la columna de la cola de peticiones.
No hay una mejor manera (colas por delante o buffers por detrás), aunque personalmente suelo emplear la segunda opción pues la semántica de “En curso” y “Listo” para mí es más intuitiva. Lo importante es que deben contar para el límite del WIP. Si vemos que la cola de la actividad siguiente está llena, no podremos pasarle más trabajo. Igual, si nuestro buffer de salida está lleno, es una señal para dejar de tomar trabajo nuevo. En el tablero, el límite del WIP lo indicaremos con un número en la columna correspondiente.
Creo que un excelente ejemplo gráfico de cómo se aplica el sistema pull y el límite del WIP en un tablero Kanban está en este artículo en el blog de Henrik Kniberg.
Gestión de la variabilidad
No todas las peticiones tardan lo mismo en acabarse. En el tablero pueden coexistir tareas de ciclo corto y de ciclo largo relacionadas con el mismo producto. De la misma manera, tampoco tendremos control absoluto sobre la llegada de las peticiones. La ventaja de Kanban es que, como hemos visto, es capaz de equilibrar la producción a la demanda sin necesidad de elaborar un plan de producción.
Pero no todas las peticiones se pueden tratar de la misma manera. Algunas requieren saltarse la prioridad FIFO (el primero que llega es el primero en salir). Para ello podemos usar tarjetas con diferentes colores para representar tareas que llevan asociadas una promesa diferente para el cliente. También pueden llevar una marca o incluso una anotación específica (“URGENTE” o “Para el 23/Abr/2014”). También podemos limitar el WIP por clase de servicio. En ocasiones esto se hace pintando carriles diferentes. Cada clase de servicio debe llevar una política explícita asociada, compartida por todos.
Flujo y cadencias
Cuando aplicas Kanban y pones el foco en gestionar el flujo, limitando el trabajo en curso, explicitando políticas y quizás creando clases de servicio para manejar la variabilidad de la demanda, consigues ser predecible, es decir, consigues poder responder a la pregunta de “¿Esto, para cuándo estará?” con bastante precisión y sin necesidad de un análisis previo. Si oyes hablar de #NoEstimates, en realidad se refieren a que puedes establecer, con un cierto nivel de confianza, unos SLA (acuerdos de nivel de servicio) basados en la observación histórica de tus métricas. Para ello es MUY IMPORTANTE ser disciplinados en la medición. El uso de herramientas digitales (como JIRA, Leankit Kanban, SwiftKanban, etc) resulta poco menos que imprescindible. Otro día hablaré de las diferentes métricas que puedes usar para ayudarte a entender y gestionar el flujo.
Además, cuando tu sistema se estabiliza y puedes establecer esos SLA, también resulta que descubres que hay una serie de eventos (reuniones) que suelen suceder de manera muy regular, como si el propio sistema, contigo incluído, se hubiera auto-sincronizado. A estas rutinas, Anderson las llama cadencias.
Bibliografía
Que yo haya leído, te puedo recomendar:
- “Kanban”, de David J. Anderson (también disponible en español traducido por Masa K. Maeda)
- “Kanban in Action”, de Hammarberg y Sunden. Para mi gusto, mucho mejor empezar con éste que con el de Anderson. Es mucho más práctico y ameno.
- “Kanban vs Scrum”, de Henrik Kniberg, es una excelente comparación entre Scrum y Kanban. También disponible en castellano. Ambos gratuitamente.
También tengo ganas de leerme este otro: “Kanban from the Inside”, de Mike Burrows. Igual este verano consigo hacerlo.
Seguro que me quedo cosas en el tintero. Espero ir profundizando en artículos posteriores. Si tienes cualquier duda o te interesa que aclare algún tema en particular, no dudes en usar los comentarios aquí abajo.