La mayoría de la gente confunde varios conceptos relacionados con Kanban: Existen los tableros kanban, las señales kanban, los sistemas kanban y el método Kanban.
Puede que tengas experiencia con Kanban o que solamente hayas escuchado hablar del mismo. Quizás hayas escuchado a algún equipo decir: Tenemos que dejar de hacer Scrum y empezar a usar Kanban. ¿Que quiere decir eso?
La mayoría de la gente confunde varios conceptos relacionados con Kanban. Iremos desde el principio. La palabra Kanban existe tanto en Chino como en Japonés.
Kanban escrito en Chino (看板) significa señal o tablero visual. Literalmente significa «Mirando al tablero». A pesar de que los kanjis se utilizan tanto en Japonés como en Chino, en Chino sólo existe ese significado.
Kanban escrito en Japonés (かんばん) significa tarjeta o señal. Por ejemplo, una tarjeta que te entregan al entrar a un probador que indica el número de prendas que portas para que el dependiente pueda saber con cuantas sales.
El método Kanban es el método diseñado por David J. Anderson para la gestión del flujo de trabajo, basado en los sistemas Lean Manufacturing a los que dio pie el trabajo de Toyota en los 50.
Un sistema Kanban es un sistema pull en el que el trabajo fluye a lo largo del sistema, donde existen restricciones y limitaciones, físicas o impuestas. Para ello es necesario que existan límites de trabajo en curso (WIP, Work in Progress limits)
Cuando hablamos de implementar Kanban, tenemos que clarificar de qué estamos hablando. ¿Tablero, slots, método o sistemas?
¿Hablamos de implementar Kanban (看板), un tablero donde mostramos el trabajo -o cualquier otra cosa-.?
¿Hablamos de implementar Kanbans que son señales visuales que nos indican algo, por ejemplo el número de clientes con el número de prendas en el probador?
¿O hablamos de implementar el método Kanban, que acoge a los dos anteriores y además incluye una serie de prácticas para mejorar la gestión del flujo de trabajo? Eso da lugar a un sistema Kanban, que entraría dentro de los métodos ágiles.
Un tablero Kanban o el uso de kanbans no se consideran un método ágil, aunque muchos de ellos los utilizan. Son solamente técnicas.
Es importante diferenciar entre el método que utilizamos y el sistema sobre el que actuamos. Ambos se llaman Kanban pero expresan cosas distintas. Cuando se usa el método Kanban, es muy importantes diferenciar de qué se habla.
En el caso de métodos ágiles, por definición sólo podemos hablar del tercero: el método Kanban. Sin embargo, muchos equipos piensan que hacen Kanban cuando en realidad solamente tienen un tablero visual, ya que no han implementado ninguna de las prácticas básicas que permiten obtener un sistema Kanban.
Estos acercamientos iniciales al método Kanban, en ocasiones muy inocentes, se conocen como protokanban, un intento de implementar un sistema Kanban que use el método pero que no ha adoptado todas sus prácticas para convertirse en sistema pull cerrado. Es decir, un sistema por el que fluya y se pueda gestionar el trabajo.
En la imagen de arriba, se puede ver un protokanban en acción. Existe una visualización del trabajo (看板), existen Kanbans (かんばん) y alguna práctica del método, como las políticas explícitas. Sin embargo no existe ningún límite del trabajo en curso (WIP), lo que impide que se un sistema pull. El trabajo entra y sale sin control sobre el flujo del mismo.
En esta imagen se puede observar un sistema Kanban completo. Tiene un punto de commitment y uno de delivery y entre ellos todo el trabajo está limitado, lo que permite medir y cambiar la limitación para optimizar el sistema. ¿Ves los cuadrados dibujados a mano para colocar los tickets? Eso es el kanban (かんばん). Mucha gente cree que los kanbans son los tickets, cuando en realidad son los huecos vacíos, que están indicando una señal: dame más trabajo.
El método Kanban tiene 6 prácticas y 2 grupos de principios: Gestión del cambio y Gestión del servicio.
Prácticas en el método Kanban: Limitar WIP, Políticas y Clases de Servicio
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.
Kanban (III): Reuniones y roles en Kanban
Después de haber visto qué es Kanban y cuales son sus reglas más importantes, en este artículo veremos cuales son las técnicas de management más importantes del método.
Desde 2008, Kanban ha evolucionado positivamente para crear un método que pretende dar soluciones a establecer un sistema que permita gestionar el flujo de trabajo en una organización, permitiendo un estado de auto-organización que de respuestas a la complejidad creciente, especialmente en entornos de desarrollo de software.
Para ello, además de los tableros kanban, junto con las políticas, límites WIP y clases de servicio, existen una serie de roles y reuniones que pueden ser adoptados en Kanban.
Kanban, a diferencia de Scrum, no prescribe roles o reuniones. Éstos han sido destilados a partir de la observación en organizaciones que han adoptado el método y lo han evolucionado de forma colaborativa.
Principios del cambio en Kanban
Los tres principios de cambio del método Kanban, que son una guía para su implementación son:
Empieza con lo que haces ahora
Entiende los procesos existentes, tal y como son actualmente
Respeta los títulos, roles y trabajos existentes
Pro tanto, en este artículo se tocan aspectos orientados a la mejora de organizaciones que ya usan Kanban y lo están evolucionando. No son una prescripción de los mismos.
Roles en Kanban
Service request Manager
Se encarga de gestionar la demanda y los requisitos dentro del sistema Kanban, manejando las relaciones con los stakeholders y fomentando la transparencia dentro del sistema en torno a la priorización del trabajo. Alternativamente, este rol se puede llamar Product Manager, Product Owner o Service Manager.
Service Delivery Manager
Es responsable del flujo de trabajo dentro de un sistema Kanban y/o determinados ítems de trabajo y facilita el Kanban Meeting y el Delivery Planning. Algunos nombres alternativos son Flow Manager, Delivery Manager o incluso Flow Master.
Reuniones en Kanban
Kanban define siete cadencias o reuniones para gestionar el flujo de trabajo a nivel organizacional, programa o equipo. Todas ellas están interconectadas y dan feedback para la evolución y gestión del flujo de trabajo.
Replenishment Meeting
De cadencia semanal, el objetivo de esta reunión es establecer prioridades y seleccionar cuales son las siguientes prioridades de trabajo. Se mueve trabajo a los commitment point del sistema Kanban. Por servicio.
Daily Kanban
De cadencia diaria, es una reunión en la que los miembros del equipo de un sistema o parte de un sistema Kanban se reúnen cada día para evaluar el trabajo en curso y acciones a tomar. Esta cadencia se produce para cada uno de los servicios dentro de un sistema.
Service delivery meeting
Esta reunión, cuya cadencia depende de cuando se entregue software al cliente, está orientada a examinar y mejorar la efectividad del servicio.
Delivery Planning meeting
Esta reunión se produce a demanda para revisar y planificar entregas al cliente. La diferencia con la anterior es que, mientras esta se orienta a planificar actividades de entrega, la anterior se orienta a examinar y mejorar el servicio.
Strategy Review
Durante esta reunión, se seleccionan los servicios que deben proveerse a nivel organizacional y definir la «Idoneidad para el fin» (Fitness for purpose) del mismo, así como establecer las condiciones necesarias y dar dirección al servicio.
Operations Review
El objetivo es entender el balance entre servicios, desplegar recursos para maximizar la entrega de valor de acuerdo con las expectativas de los clientes.
Risk Review
Esta reunión se hace para entender los riesgos asociados a la entrega de valor, por ejemplo a través de la acumulación de impedimentos.
FUENTES: https://jeronimopalacios.com/kanban/
TRANSCRIPCIÓN: Areli Álvarez Lean Construction México®