Me complace estar aquí como invitado esta semana por invitación de Jeff. El tema que nos ocupa es kanban. Desgraciadamente, esta entrada es un poco larga, porque quiero ir más allá del nivel habitual de fragmentos sonoros para un tema importante.
Recorrido terminológico
Kanban es una palabra japonesa que significa firmar. Se utiliza para controlar el trabajo en curso, en el contexto de una línea de producción en la que el flujo ya se ha establecido (Ohno, Sistema de producción ToyotaCapítulo 2). El concepto se ha abierto camino en el desarrollo de software, donde a menudo se contrapone a la Scrum o se sugiere como complemento a las implantaciones de la Scrum. Sin embargo, aunque la mayoría de los usos del término se remontan a sus orígenes en el Toyota Way, su uso popular malinterpreta gran parte de su intención original.
El estilo Toyota es un sistema de construcción de cosas que, como formalismo, se remonta a mediados del siglo XX, y tiene raíces explícitas a principios del siglo XX o incluso a finales del siglo XIX. Así funciona Toyota. Muchas otras empresas japonesas, empezando por los proveedores de Toyota pero incluyendo a muchas otras, siguen los mismos principios de superposición de fases de desarrollo, autoorganización y aprendizaje. Encontramos muchas de estas empresas mencionadas en la revista Harvard Business Review's El nuevo juego del desarrollo de nuevos productos de Hirotaka Takeuchi e Ikujiro Nonaka. Este es el artículo que inspiró el Scrum, y Jeff Sutherland sigue colaborando estrechamente con Nonaka en la actualidad, como describe Jeff en "Takeuchi y Nonaka: Las raíces del Scrum".
Takeuchi pasó seis años estudiando Toyota y resumió la cultura aparentemente paradójica en el libro Toyota Extreme. La relación histórica entre el documento de Harvard Business Review y Toyota es a veces indirecta, aunque los principios de ambos coinciden. Por ejemplo, la noción de empezar a diseñar antes de haber completado el análisis (que retomaremos más adelante) es explícita tanto en el documento de Takeuchi y Nonaka como en la descripción de Liker del Toyota Way. El uso de equipos versátiles y diversos aparece tanto en el documento de Harvard Business Review como en Toyota Extreme.
En Blog de Jeff describe, es importante distinguir Toyota Way de Lean. "Lean" en su uso común y vulgar -sobre todo en entornos metodológicos- se interpreta con demasiada frecuencia como una forma superficial de aplicar las herramientas de Toyota Way a la producción sin adoptar sus fundamentos más profundos. Kanban es una de esas herramientas. Puede ser una parte poderosa de un sistema de producción que ya tiene un flujo de trabajo, pero es crucial entender que los fundamentos del flujo deben ser lo primero. En este artículo, el término "Lean" aparecerá ocasionalmente en material citado que, a menos que se mencione explícitamente lo contrario, se refiere al Toyota Way.
Scrum es un marco para construir productos que se basa en The Toyota Way. Hay pocas diferencias entre sus fundamentos: por ejemplo, Toyota Way tiene un Ingeniero Jefe que Scrum divide en un Product Owner y un ScrumMaster. Como veremos más adelante, Scrum no se basa en kanban ni tiene necesidad de kanbanporque se adapta perfectamente a un mecanismo de limitación del trabajo en curso denominado flujo continuo de una pieza.
¿Cómo se utiliza Kanban?
En Toyota, kanban se utiliza de dos formas principales. La aplicación original de kanban (como signo - véase el ejemplo de la derecha, del libro de Liker El estilo Toyota, capítulo 2) era aplacar un modo de fallo del Sistema de Producción Toyota. A veces no se puede tener un flujo continuo de una sola pieza, debido a impedimentos como el desarrollo multisitio, una mala estructura organizativa o una mala asignación de los trabajadores a los lugares de trabajo. Si eres un proveedor alejado de tu consumidor, necesitas un semáforo para sincronizar el traspaso de mercancías. El sitio kanban es ese semáforo. Cuando el consumidor se está quedando sin piezas, la célula de trabajo consumidora pone un kanban tarjeta en un carro de suministros que solicita suministros adicionales. El carro se lleva al punto de suministro. Su llegada es una señal para que el proveedor fabrique más y llene el carro, tras lo cual puede volver a llevarlo al consumidor. El consumidor puede iniciar la solicitud con un poco de antelación, dando tiempo al proveedor para responder a la petición, o el proveedor puede mantener algunas existencias a mano para que la mayoría de las solicitudes puedan satisfacerse rápidamente.
El proveedor crea un inventario que se coloca en un carro y se entrega en el punto de uso. El carro se deja allí. Cuando el carro empieza a quedarse vacío, se pone un kanban tarjeta (un cartel) en él dando información sobre la necesidad proyectada, y el carro se lleva de nuevo al punto de suministro para que pueda ser llenado. No tiene kanban sin el muda (desperdicio) de mover la tarjeta y el carro, del coste de almacenamiento del inventario. No tiene kanban sin el mura que proviene de la comunicación de bajo ancho de banda entre el proveedor y el consumidor. Por definición, kanban se basa en tener murien lugar de fluir continuamente, el trabajo se acumula. Así que este modo de fallo crea la necesidad de limitar el trabajo en curso. Un uso disciplinado de kanban limita el trabajo en curso.
La otra aplicación es dentro de una célula de trabajo, para garantizar que sólo haya un número limitado de piezas (normalmente una) en la mesa frente al trabajador en todo momento. La mesa tiene kanban cuadrados dibujados en él. Las piezas que se trabajan deben estar dentro de uno de estos cuadrados. Si las piezas se amontonan, significa que hay sobreproducción en alguna parte. Si soy productor, sólo debo producir algo si veo que mi vecino necesita, o está a punto de necesitar, la pieza que construyo. Construyo esa pieza para entregársela a mi vecino justo a tiempo. Kanban cuadrados también se utilizan a mayor escala en la fábrica, como marcadores de posición para palés de piezas o para piezas de mayor tamaño (véase la figura de la derecha; de leanmanufacture.net).
Kanban es un remedio contra el despilfarro en la fabricación repetitiva
Kanban se aplica al trabajo repetitivo: construir el mismo objeto una y otra vez. Liker - autor de El estilo Toyota y reconocida autoridad en el Sistema de Producción Toyota:
No todo puede reponerse mediante un sistema pull; algunas cosas deben programarse. Tomemos el ejemplo de los productos de gama alta, como un Rolex, un coche deportivo o esos palos de golf de alta tecnología que anuncia Tiger Woods. Cuando se compra un artículo especial o de un solo uso, hay que pensar en lo que se quiere, considerar los costes y beneficios y planificar cuándo se va a adquirir. En cierto sentido, se crea un calendario de compra, ya que no existe una necesidad inmediata de adquirirlo. (Capítulo 9)
Así es el software: Rara vez construimos lo mismo una y otra vez. En la fabricación, alguien tiene que construir las piezas nuevas que necesitamos. En el software, podemos reutilizar una función tantas veces como queramos añadiéndole tantas llamadas como queramos, o reutilizar una clase instanciando un nuevo objeto de la misma. Gran parte del diseño se basa en la agregación y ampliación innovadoras e incrementales de artefactos ya existentes. Esto es especialmente cierto en el software, pero también en sectores como la arquitectura y la construcción. Pocos trabajos de diseño se adentran en un territorio totalmente nuevo, pero ninguno es una réplica consciente de construcciones anteriores. Se trata de construir cosas nuevas para una necesidad programada del mercado, en lugar de una producción estocástica y repetitiva de la misma forma básica.
Liker continúa:
Los expertos en TPS se impacientan mucho e incluso se irritan cuando oyen a la gente delirar y centrarse en kanban como si fuera el Sistema de Producción Toyota... El reto consiste en desarrollar una organización de aprendizaje que encuentre formas de reducir el número de kanban y, de este modo, reducir y finalmente eliminar la reserva de existencias. Recuerde: el kanban es un sistema organizado de topes de inventario y, según Ohno, el inventario es un residuo, ya sea en un sistema push o en un sistema pull. Así que kanban es algo de lo que te esfuerzas por librarte, no por sentirte orgulloso. (Capítulo 9)
El software se ha apropiado indebidamente de Kanban
La fascinación por kanban en Europa y Norteamérica tiene sus raíces en la desinformación sobre cómo kanban encaja en el Toyota Way, pero también hay un elemento cultural en el malentendido. Kanban se aplica adecuadamente como solución selectiva y detallada a un problema concreto. No es una filosofía de desarrollo. Sharon Begley observa:
Los occidentales prefieren principios universales abstractos; los orientales buscan reglas adecuadas a una situación. (Sharon Begley, "Oriente contra Occidente: One Sees Big Picture, Other Is Focused, "The Wall Street Journal, 28 de marzo de 2003).
Taichi Ōhno, inventor del kanban sistema, nos lo cuenta en su libro de referencia Toyota Production System:
Supervisar de cerca las reglas del Kanban es un problema interminable...
La regla 6 nos insta a reducir el número de kanban... (Capítulo 2)
Lo ideal es fluir en lugar de kanban. Una vez más, nos aconseja Liker, "los topes de inventario se utilizan juiciosamente allí donde el flujo continuo no es posible hoy en día. Pero el ideal de flujo proporciona una dirección clara". (Liker, The Toyota Way, capítulo 8)
La palabra kanban también se utiliza como nombre de una metodología de reciente aparición basada en la visualización y el análisis matemático del trabajo en curso. Vemos equipos que adoptan esta forma de kanbancomo herramienta o metodología por derecho propio y no como visión del mundo, sin haber construido antes unos cimientos y unas disciplinas de flujo único. Kanban (la metodología) desalienta el trabajo en equipo y aumenta el riesgo de no completar las cargas de trabajo acordadas dentro de un plazo como un Sprint. En cambio, da a los gestores mucha flexibilidad. Es decir, permite al Product Owner llegar al equipo en mitad del Sprint y detener lo que están haciendo mientras introduce un nuevo PBI o tarea. Esta interpretación de kanban vende a los directivos la necesidad de recuperar el control que perdieron con el Scrum. La capacidad de poner parches, en lugar de resolver los problemas de raíz, da una mayor sensación de éxito inmediato sin tener que sopesar las consecuencias a largo plazo de las decisiones a corto plazo.
Estos malentendidos de los fundamentos de Toyota son profundos, y aunque a menudo tienen kanban como hilo conductor no se limitan al software. Si echamos un vistazo a Kanban.com encontramos una afirmación del director de TI de CVG Systems: "Para obtener el máximo beneficio de kanbanNecesitábamos una solución de circuito cerrado que soportara un proceso de flujo continuo, una solución a la que cualquiera de nuestros proveedores pudiera acceder fácilmente". Kanban es un parche en ausencia de flujo único, no un método para conseguirlo.
Se trata de grupos separados controlados por un kanban que reabastece el inventario a demanda (pull en lugar de push), de forma muy estructurada. Se trata de un sistema de seis pasos estructurado proceso (Ōhno, Sistema de producción ToyotaCapítulo 2)
Una solución realmente ajustada: Flujo continuo de una pieza
En lugar de depender de kanban, el verdadero Lean elimina mura, muriy muda - incoherencia, falta de flujo continuo y despilfarro. En lugar de seguir el movimiento y el procesamiento de los materiales, un buen Scrum co-localiza los equipos o los dispositivos que fabrican los artefactos. Los fundamentos de la Scrum fomentan el flujo continuo de una sola pieza. Los miembros del equipo se arremolinan en torno a un PBI a la vez. Una alternativa disfuncional común es el "Scrum de carril de natación": cada miembro del equipo se apropia individualmente de un PBI a través de las etapas del proceso. Si una persona reúne varios PBI o intenta realizar todas las tareas del PBI a la vez, se puede producir el cambio de contexto que se deriva de tener demasiado trabajo en curso. Kanban dice para hacer un seguimiento del número de PBI en curso, con el apoyo de la matemática de la teoría de las pseudocolas, para limitar cuántas tarjetas puede haber en el tablero de tareas.
Una buena práctica Scrum sigue el Toyota Way centrándose en un único PBI a la vez, aprovechando la inteligencia y la autoorganización del equipo -en lugar de un método- para gestionar el trabajo en curso. En un equipo Scrum no hay subequipos de larga duración: los Developers trabajan juntos como una unidad. Se trata de individuos e interacciones por encima de procesos y herramientas. Si el equipo trabaja como una unidad, se elimina el problema de esperar a que lleguen elementos de trabajo de otra fase de desarrollo. También elimina tanto el inventario necesario para mantener ocupado al equipo de desarrollo en el emplazamiento local, como el inventario que se prepara para su envío en paralelo en el proveedor. Kanban depende fundamentalmente de ambos inventarios.
El flujo continuo de una pieza puede tener lugar en un único equipo que trabaja como una unidad muy unida, en una única célula de trabajo (o equipo Scrum), para aplicar varias transformaciones al trabajo en curso (que se limita a una sola pieza cada vez). El equipo hace un poco de análisis, un poco de diseño, un poco de construcción y un poco de pruebas, todo a la vez, en ciclos muy cortos. Los individuos son polivalentes, lo que refleja el concepto Toyota de chaku-chaku. Véase la ilustración de la derecha, extraída de la Figura 8-4 de The Toyota Way. Refleja una forma de trabajar bastante desestructurada, como relatan Takeuchi y Nonaka en el artículo de Harvard Business Review:
En lugar de avanzar por etapas definidas y muy estructuradas, el proceso nace de la interacción de los miembros del equipo... Un grupo de ingenieros, por ejemplo, puede empezar a diseñar el producto (fase 3) antes de tener todos los resultados de las pruebas de viabilidad (fase 2). O puede que el equipo se vea obligado a reconsiderar una decisión a raíz de una información posterior. El equipo no se detiene entonces, sino que se dedica a la experimentación iterativa. Esto ocurre incluso en las últimas fases del proceso de desarrollo.
Liker subraya el flujo de una sola pieza en el capítulo 3 de El estilo Toyota:
... la célula de flujo de una pieza es lo último en producción ajustada. Ha eliminado la mayoría de los ocho tipos de residuos de Toyota.
De hecho, el objetivo último de la fabricación ajustada es aplicar el ideal del flujo de una sola pieza a todas las operaciones empresariales, desde el diseño del producto hasta su lanzamiento, la toma de pedidos y la producción física.
La programación en parejas es una de las mejores analogías que tenemos en software. No hay codificador ni probador: hay dos desarrolladores trabajando juntos en una célula de trabajo, probando y desarrollando continuamente hasta que el trabajo en curso está hecho-hecho-hecho. Una buena programación en parejas es bastante desestructurada. Como los bucles de retroalimentación se producen local e inmediatamente, no hay necesidad de una tarjeta kanban literal. Dado que se trata de dos mentes que trabajan como una sola, no hay necesidad de cuadrados kanban debajo del teclado. De nuevo, Liker afirma: "En una célula de flujo de una sola pieza, hay muy poca actividad sin valor añadido, como mover materiales de un lado a otro. Se ve rápidamente quién está muy ocupado y quién está ocioso". (El estilo Toyota(Capítulo 17)
No se detiene en la programación por parejas. El flujo continuo de una pieza es un elemento básico de las técnicas que enseñamos a los asistentes al curso de Certificación ScrumMaster para que las apliquen en todo el equipo a lo largo del sprint. En el Juego de velocidad ejercicio hacemos hincapié en que todo el equipo debe trabajar en un PBI a la vez - enjambre en lugar de jugar Swim-Lane Scrum. El ritmo es frenético, pero el flujo se suaviza tras dos o tres sprints, porque se sabe perfectamente quién hace qué, segundo a segundo. Kanban las cartas sólo estorbarían. Los buenos equipos de desarrollo son como los equipos de fútbol, hockey o baloncesto. Los jugadores y los artefactos del juego son las consideraciones más importantes para entender la naturaleza del trabajo en curso.
La programación en parejas como técnica depende de que exista el flujo Scrum más amplio: buena especificaciones de habilitación del Product Backlog, autoorganización y selección de tareas entre los desarrolladores, etc. Lo mismo ocurre con las demás formas de flujo dentro de un equipo Scrum. No es una solución rápida, y no hay un camino rápido para construir los cimientos de la calidad y la eficiencia. De hecho, kanban fue una de las incorporaciones más tardías al Sistema de Producción Toyota, ya que tuvo que esperar a que se establecieran los flujos más amplios. Como cuenta Ōhno: "Los de fuera parecen pensar que el Sistema de Producción Toyota y kanban son la misma cosa... Pero... A menos que uno capte completamente este método de hacer el trabajo para que las cosas fluyan, es imposible entrar de lleno en la kanban sistema cuando llegue el momento". (Ōhno, Sistema de producción ToyotaCapítulo 2)
Kanban: Un buen ajuste para los equipos que ven el trabajo como la extinción de incendios
Las plantas de producción de Toyota y los equipos Scrum existen para fabricar productos. La literatura habla de la aplicación con éxito de kanban en el sector servicios, análogo al de los bomberos o las urgencias hospitalarias. Es complicado programar el próximo incendio a menos que vivas en el mundo de la Fahrenheit 451. Muchos equipos de desarrollo funcionan en modo "apagafuegos", a menudo con "abucheos" del Product Owner durante un Sprint. Y meterse en una disciplina es difícil: es fácil querer reaccionar inmediatamente a los cambios del cliente en lugar de integrar una petición en el plan de negocio, y sienta bien lanzar cuando a uno le parece. Algunos equipos Scrum nunca aprenden las disciplinas de la planificación y la estimación. Es fácil ver cómo estas organizaciones gravitan hacia kanban.
Es difícil que estos equipos lleguen a desarrollar un verdadero sentido del trabajo en equipo y de la colaboración, que se sientan dueños de completar el trabajo según una previsión, o que desarrollen las disciplinas de planificación a largo plazo y especificaciones habilitadoras que están en la base del valor a largo plazo. El problema con kanban (como con Scrum-trasero) es que la mala ejecución resultante no te matará. En su libro, Liker expresa su asombro ante la ignorancia de los supuestos practicantes de Lean, y ha visto reducciones de hasta 80% en el inventario después de aclarar su comprensión (Liker, The Toyota Way, capítulo 14). Dice:
He visitado cientos de organizaciones que afirman ser practicantes avanzados de los métodos Lean... [Habiendo estudiado a Toyota durante veinte años, tengo claro que, en comparación, son unos aficionados.
Cree que menos del 1% de las empresas ajenas a Toyota "lo entienden". (Liker, The Toyota Way, Capítulo 1) Muchas de estas empresas siguen la palabra de moda Lean en lugar del núcleo de Toyota Way. El marco Scrum, tal y como está definido, ha evitado cuidadosamente esta trampa (véase "Takeuchi y Nonaka: Las raíces del Scrum").
Lo mismo ocurre con el software. Los equipos que han hecho ambas cosas han descubierto que kanban en realidad pueden ofrecer menos visibilidad a la actividad del trabajo en curso que Scrum, y quitar la sensación de trabajo en equipo y de "presión positiva" que se deriva del flujo de un equipo Scrum (véase Reflexiones de Samuli Heljo).
Asumir la mente Kaizen: volver a los cimientos
Spanish 
English 
French