La Historia de Kanban. ¿Qué es Kanban?

Historia de Kanban

Kanban ha ido ganando popularidad durante las últimas décadas. Nació para aplicarse a los procesos de fabricación y con el tiempo se convirtió en un territorio reclamado por los desarrolladores de software. Últimamente, ha empezado a ser reconocido por las entidades empresariales de diferentes ámbitos.

Cada vez más y más gente escucha sobre Kanban y a menudo aparecen malas interpretaciones. Entonces, ¿qué es el Kanban? Aquí tienes algunas de las cosas más importantes que debes saber sobre el método desde su origen y desarrollo hasta hoy en día.

La Historia de Kanban

Kanban ha recorrido un largo camino para convertirse en la parte esencial de la metodología Lean de gestión que es hoy en día. Vale la pena echar un vistazo a la rica historia de Kanban, que tuvo sus inicios durante el período Edo en Japón.

 

1600’s: Las Raíces de Kanban

En 1603, después de que los devastadores conflictos militares casi constantes del siglo XIV y la agitación social terminaran finalmente, Japón entró en un período de estabilidad y crecimiento económico. A medida que la economía del país floreció, las calles de las ciudades japonesas se llenaron de tiendas y negocios locales que luchaban por la conciencia y la atención de los clientes. Es en estas calles donde nació el término “Kanban”.

El nombre Kanban viene de dos palabras japonesas, “Kan”  que significa letrero, y “Ban”  que significa un tablero. A medida que las calles se llenaban de gente, los dueños de las tiendas comenzaron a hacer letreros personalizados – “Kanbans” – para llamar la atención de los transeúntes y contarles sobre el tipo de servicios que prestaba cada tienda. Poco después, los diseñadores de letreros Kanban comenzaron a competir elaborando artísticamente sus letreros, para que se distinguieran de los demás kanbans de la calle, una práctica que sigue viva hoy en día con los modernos diseños de neón. Al observar la rica colección de aquellos tiempos, se puede ver un kanban de pescador con aspecto de pez, o un kanban de pipa de madera de estilo artístico, hecho para una tienda de pipas.

Todos estos signos Kanban tenían una cosa en común – al igual que las modernas tarjetas Kanban, eran capaces de comunicar su contenido de forma clara y concisa.

 

1940’s: El Kanban de manufactura Lean de Toyota

 Producir solo lo necesario, cuando sea necesario y en la cantidad necesaria. Taiichi Ōno

“Todo sigue marchando bien: Toyota” era un slogan de Toyota hace años, y obviamente pegó. Pero no siempre fue el caso.

La Toyota de los años 40 estaba lejos de ser el gigante industrial que conocemos hoy en día. Después de la segunda guerra mundial, la industria automovilística japonesa estaba estancada. Toyota estaba firmemente perdiendo, no podía competir en absoluto con ninguno de los fabricantes de coches americanos, y estaba en tan mala forma que no podían contratar a ningún nuevo personal. Pero el CEO de Toyota, Kiichiro Toyoda, tenía la misión de cambiar eso. Dándose cuenta de que la diferencia de diez veces la productividad entre los fabricantes de coches de EE.UU. y Toyota no puede explicarse sólo por la falta de equipos, el problema era más complejo, Toyoda puso a la compañía en la búsqueda de igualar la productividad con los fabricantes de automóviles americanos en tres años. Aunque un objetivo tan ambicioso era difícilmente alcanzable, fue lo que puso a la empresa en un camino basado en la innovación y la optimización de la organización del trabajo durante los próximos años.

Este cambio en la cultura de la compañía despejó el camino para Taiichi Ōno, un joven ingeniero industrial que acaba de ser transferido a la Toyota Motor Company en 1943.

Ohno-Taiichi

Taiichi Ōno, fuente: wikimedia.org 

Taiichi Ōno tenía un carácter estricto, pero justo y rápidamente ascendió en las filas de Toyota. En 1949 se convirtió en el gerente del taller de máquinas, lo que le permitió empezar a experimentar con nuevas herramientas y principios de organización del trabajo. En 1954 fue ascendido a un puesto de director.

Kanban es un método para gestionar el trabajo que surgió en Toyota Production System (TPS). A finales de los años 40, Toyota implementó en su producción el sistema “just in time” (justo a tiempo”) que en realidad representa un sistema de arrastre. Esto significa que la producción se basa en la demanda de los clientes y no en la práctica tradicional “pull” de fabricar productos e intentar venderlos en el mercado.

Su exclusivo sistema de producción puso las bases del Lean Manufacturing (“producción ajustada”). Su propósito fundamental consiste en minimizar los desperdicios sin afectar la producción. El objetivo principal es crear más valor para el cliente sin generar más gastos.

Taiichi Ōno identificó y clasificó siete tipos de residuos (jap. Muda), que conducen a una disminución en el rendimiento y la productividad del sistema.

Siete tipos de residuos

Siete tipos de residuos (Muda)

La sobreproducción era considerada un desperdicio, ya que la demanda de los clientes puede cambiar con el tiempo, pero también lo era mantener un gran inventario de materias primas. La única solución a esta aparente paradoja era producir lo que se necesita y sólo cuando se necesita. Exigía mantener las existencias al mínimo mientras se aseguraba un flujo de trabajo suave y elevado a lo largo de todo el proceso. Pero este enfoque tenía sus propios problemas. ¿Cómo señalar que se necesita un nuevo producto? ¿Cómo propagar esta señal a la línea de producción y eventualmente a los proveedores de materias primas?

Pero recibió una inspiración inesperada de parte de los supermercados minoristas. Ōno visitó los Estados Unidos en 1956, y quedó impresionado por la forma en que la cadena de supermercados Piggly Wiggly fue capaz de mantener los estantes abastecidos con la cantidad justa de cada producto. Después de regresar al Japón, empezó a utilizar tarjetas de papel para señalar y seguir la demanda en su fábrica, y llamó al nuevo sistema “Kanban”.

Las tarjetas Kanban se adjuntaban a cada producto terminado, y una vez que se vendía, las tarjetas se trasladaban de nuevo a la línea de producción. Los miembros del equipo sólo podían trabajar en el nuevo artículo a medida que la tarjeta que señalaba la demanda de éste volvía a ellos, y sólo una vez que el número de tarjetas Kanban pendientes alcanzaba un umbral definido. Cada material utilizado durante la producción también tenía su propia tarjeta Kanban adjunta, de modo que la señal de demanda fluía en última instancia a través de toda la cadena de producción, terminando en los proveedores externos.

Manufactura Kanban

Ese sistema redujo la acumulación de existencias, mejoró el rendimiento y proporcionó una gran visibilidad del proceso. Su uso se extendió rápidamente por toda la División de Maquinaria. En 1963 se desarrolló un plan para propagarlo por toda la compañía, y en breve fue adoptado en casi todos los procesos de Toyota.

La potencia de la aplicación de Kanban fue tal, que Toyota pasó de operar con pérdidas a ser el competidor global que es hoy en día. Taiichi Ōno ascendió por todos los rangos superiores de la compañía y se convirtió en vicepresidente ejecutivo en 1975. Su trabajo no sólo dio lugar al nuevo significado de “Kanban”, sino que también sentó las bases de las modernas técnicas de gestión, conocidas como el Sistema de Producción Toyota.

 

2003-2008: Kanban para la industria del software

A medida que el Sistema de Producción Toyota ganaba popularidad y se extendía la noticia, los directores de proyectos de diferentes tipos de industrias trataron de aplicar sus enseñanzas básicas a su trabajo.

El avance más significativo vino de la industria del software.

A principios del siglo XXI, la industria del software se percató de que Kanban podía hacer un cambio real en la forma en la que se producían y entregaban los productos y los servicios. Se demostró que Kanban era conveniente no solo para la industria automotriz, sino también para cualquier otro tipo de industria. Así es como nació el método Kanban.

En esa época, la gestión de proyectos de software ya había pasado gradualmente de procesos engorrosos e ineficientes como el CMMI a un enfoque más ligero y “ágil”, que se formalizó en el Manifiesto Ágil, publicado en 2001.

Manifiesto para el Desarrollo Ágil de SoftwareManifiesto para el Desarrollo Ágil de Software, fuente: agilemanifesto.org 

El Manifiesto Ágil y sus principios subyacentes ofrecían consejos generales como “Acoger con beneplácito los cambios de requisitos” o “Entregar con frecuencia software que funcione”, pero no especificaban cómo debía lograrse esto realmente. Por lo tanto, varios sistemas de gestión del trabajo evolucionaron rápidamente para llenar este vacío, adoptando el Manifiesto y convirtiéndose en el núcleo del desarrollo de software ágil en ese momento. Los más notables de ellos fueron ScrumProgramación eXtrema y, un poco más tarde, Desarrollo de Software Lean.

Elementos de Scrum, Lean y Gestión Ágil tuvieron un impacto significativo en lo que se convertiría en el método Kanban.

 

  • Scrum
    Muchos equipos de scrum usaban tableros con tarjetas de historia de los usuarios, como radiadores de información. Esto normalmente funcionaba así: durante la planificación del sprint, cada historia de usuario, o una característica a implementar, se escribía en una tarjeta física separada. Juntas, estas tarjetas formaban un atasco de sprints y se colocaban en un gran tablero en algún lugar de la oficina, accesible a todos los miembros del equipo. Cada miembro del equipo podía acercarse a la pizarra, echar un vistazo a las historias y elegir una, que quisiera implementar a continuación. Luego llevaban la tarjeta a su escritorio, y una vez que el trabajo estaba hecho, la tarjeta era retirada y devuelta a la pizarra. Este simple sistema era ingenioso. Proporcionaba una gran visibilidad del progreso, permitía la sincronización del trabajo entre múltiples programadores y mejoraba el flujo de trabajo, ya que cada programador podía elegir el tipo de trabajo en el que se sentía mejor.

 

  • Desarrollo de Software Lean
    En 2003, Mary y Tom Poppendieck publicaron un libro ya clásico sobre el desarrollo de software, “Lean Software Development: An Agile Toolkit”. El libro tradujo los principios de la manufactura Lean del Sistema de Producción Toyota al dominio del desarrollo de software y el trabajo de conocimiento. Se centró en la eliminación de los residuos, el mapeo de la corriente de valor y en los sistemas de tracción. Fue seguido en 2007 por otro libro de los mismos autores, “Implementing Lean Software Development: From Concept to Cash”, en el que se exploraba más a fondo el uso de la Teoría de Colas para reducir los tiempos de entrega del software, y los tableros Kanban como elemento del espacio de Trabajo Visual. Además, en el 2005, Jim Sutton y Peter Middleton publicaron el libro “Lean Software Strategies” en el que se identifican los cinco principios de la producción Lean – definir valor, mapear la flujo de valor, implementar el flujo, mantener un proceso de extracción (pull), buscar oportunidades de mejora – y se aplicaron al Desarrollo de Software.

 

En ese momento, algunos equipos de desarrollo de software, que ya utilizaban tableros Scrum, adoptaron estas nuevas técnicas y reorganizaron sus tableros introduciendo columnas que representaban las distintas etapas de trabajo, dando así lugar a los tableros Kanban.

Los Kanban, combinados con otros métodos de desarrollo de software Lean y de Gestión Ágil, como la Push Scheduling, la limitación del trabajo a la capacidad y la medición del flujo, dieron lugar al desarrollo de software al estilo Kanban.

Este temprano Kanban ganó aceptación como un sistema propio, ya que ayudó con las cosas en las que Scrum no era particularmente bueno: acortar el tiempo de ciclo desde la solicitud del cliente hasta la entrega, y asegurar un flujo constante de trabajo.

En la metodología clásica de Scrum, después de una sesión de planificación de sprint, el atraso del sprint se congela, no se pueden hacer cambios en él. Ese estado dura normalmente de 7 a 30 días, a medida que el equipo progresa a través del atraso, y a veces puede ser frustrante tanto para los desarrolladores como para los clientes finales. ¿Qué hacer si hay una emergencia, y una característica específica necesita ser implementada rápidamente? ¿Qué hacer con todos los errores descubiertos en el producto en vivo – los clientes finales realmente necesitan esperar más de un mes para arreglarlos? Y finalmente, ¿cómo manejar los procesos, que son más dinámicos por su naturaleza, como la comercialización de sitios web o la administración de servidores?

El método Kanban, con sus tableros Kanban y su enfoque en el flujo, se convirtió en una respuesta a esto, proporcionando una forma altamente estructurada, visible y flexible de gestionar el trabajo.

A medida que la adopción del desarrollo de software al estilo Kanban creció lentamente, unos pocos pioneros han ayudado a difundir el conocimiento sobre el mismo, y a dar forma a su futuro final.

 

  • Mary y Tom Poppendieck
    Marry y Tom Poppendieck fueron de los primeros en abrazar y difundir el conocimiento sobre los métodos del Sistema de Producción Toyota aplicados al desarrollo de software y al trabajo de conocimiento. Ellos hablaron en numerosas conferencias y publicaron libros que cubrían temas como el Mapeo de la Corriente de Valor, la Teoría de las Colas y el espacio de Trabajo Visual que se encuentran en la base de Kanban.

 

  • Microsoft
    Probablemente los primeros intentos de introducir los principios de Kanban en los métodos de desarrollo de software, se hicieron en Microsoft. Para incrementar la productividad, los equipos de desarrollo de software comenzaron a añadir elementos de Scrum y Kanban como una extensión del modelo “Feature Crew” existente y del método “Bug Jail”. Esto trajo como resultado el primer proyecto Scrumban exitoso en el 2004.

 

  • David Anderson, Dominica DeGrandis, Corey Ladas y Daniel Vacanti
    En 2005 David Anderson estaba trabajando en la implementación del sistema Drum-Buffer-Rope para descrito en su libro, en el equipo de Ingeniería Sostenida XIT en Microsoft. En 2007 dejó Microsoft y se trasladó a Corbis, con la misión de cambiar la ingeniería de Corbis y mejorar la productividad. Allí introdujo un sistema Kanban para el procesamiento de las solicitudes de cambio junto a Dominica DeGrandis. Ha liberado al equipo de las limitaciones de las iteraciones de tiempo, ha permitido reducir el trabajo en curso y equilibrar la capacidad con la demanda. En la primavera del 2007, Corey Ladas se unió a Corbis para lanzar el segundo proyecto Kanban, el cual consistía en un proceso Scrumban para desarrollo de productos en lugar de solo hacerles mantenimiento. En el verano del 2007, Daniel Vacanti se unió a Corbis y, junto a Corey, trabajaron en un tercer gran proyecto Kanban enfocado en demostrar Kanban a gran escala. Dicho proyecto, introdujo el concepto de los swimlines o carriles para mantener juntos los ítems de trabajo relacionados entre sí. En agosto, David ha dirigido un espacio abierto en la conferencia Agile 2007, que despertó el interés inicial en los tableros Kanban y el método Kanban.

 

  • Karl Scotland
    Karl oyó hablar por primera vez del método Kanban en la conferencia Agile 2007. En septiembre de 2007, como gerente del programa de ingeniería de Yahoo!, Karl presentó a Kanban a su equipo, como una solución al problema de la longitud del Sprint en la metodología Scrum. Esta implementación fue muy exitosa y Karl se convirtió en uno de los primeros y más prominentes proponentes del método Kanban.

 

Estos éxitos iniciales han hecho que se preste más atención a Kanban.

En 2008 se formó el Grupo kanbandev en Yahoo! con el objetivo de proporcionar una plataforma para debatir y aprender más sobre el uso de los sistemas virtuales de Kanban en el desarrollo de programas informáticos, y en poco tiempo creció a más de mil miembros. Aaron Sanders, Alan Shalloway, Alisson Vale, Allan Kelly, Chris Shinkle, Corey Ladas, David Joyce, David Laribee, Derick Bailey, Eric Landes, Jeff Patton, Joe Arnold, Karl Scotland, Linda Cook, Matt Wynne, Mattias Skarin y Rob Hathaway fueron destacados pioneros del método Kanban.

 

2009: Kanban gana impulso

El verdadero año dorado para Kanban fue 2009 .

Alrededor de abril de 2009, Henrik Kniberg publicó “Kanban vs. Scrum – a practical guide”. El artículo cubría los principios básicos de Kanban de una manera fácil de entender. Para muchas personas, este fue el lugar donde aprendieron sobre el método Kanban.

En mayo de 2009 la conferencia Lean Kanban, organizada por David Anderson, se llevó a cabo en el Hotel Mandarin Oriental de Miami. En ella se presentaron los últimos avances en la aplicación del pensamiento Lean al desarrollo de software.

Después de la conferencia, se formó una sociedad informal de WIP limitada, con la misión de unificar y difundir el conocimiento sobre el método Kanban. La sociedad proporcionó una plataforma para la agregación de artículos sobre Kanban, lo que ayudó a difundir aún más el conocimiento del método.

En el verano de 2009, Jim Benson comenzó a publicar artículos sobre el Kanban Personal, que se centraban en la aplicación de los principios del Kanban a la organización de la vida personal, que más tarde se convirtió en un método propio.

 

Los 4 principios básicos de Método Kanban

David J. Anderson (reconocido como el líder de pensamiento de la adopción del Lean/Kanban para el trabajo de conocimiento) formuló el método Kanban como una aproximación al proceso evolutivo e incremental y al cambio de sistemas para las organizaciones de trabajo. El método está enfocado en llevar a cabo las tareas pendientes y los principios más importantes pueden ser divididos en cuatro principios básicos y seis prácticas.

 

Principio 1: Empezar con lo que hace ahora

Kanban no requiere configuración y puede ser aplicado sobre flujos reales de trabajo o procesos activos para identificar los problemas. Por eso es fácil implementar Kanban en cualquier tipo de organización, ya que no es necesario realizar cambios drásticos.

 

Principio 2: Comprometerse a buscar e implementar cambios incrementales y evolutivos

El método Kanban está diseñado para implementarse con una mínima resistencia, por lo que trata de pequeños y continuos cambios incrementales y evolutivos del proceso actual. En general, los cambios radicales no son considerados, ya que normalmente se encuentran con resistencias debidas al miedo o la incertidumbre del proceso.

 

Principio 3: Respetar los procesos, las responsabilidades y los cargos actuales

Kanban reconoce que los procesos en curso, los roles, las responsabilidades y los cargos existentes pueden tener valor y vale la pena conservarlos. El método Kanban no prohíbe el cambio, pero tampoco lo prescribe. Alienta el cambio incremental, ya que no provoca tanto miedo como para frenar el progreso.

 

Principio 4: Animar el liderazgo en todos los niveles

Este es el principio más novedoso de Kanban. Algunos de los mejores liderazgos surgen de actos del día a día de gente que está al frente de sus equipos. Es importante que todos fomenten una mentalidad de mejora continua (Kaizen) para alcanzar el rendimiento óptimo a nivel de equipo/ departamento/ empresa. Esto no puede ser una actividad a nivel de dirección.

 

Las seis prácticas de Kanban

Aunque aceptar la filosofía de Kanban y embarcarse en el viaje de transición es el paso más importante, cada organización debe tener cuidado con los pasos prácticos. Hay seis prácticas centrales identificadas por David J. Anderson que deben estar presentes para una implementación con éxito.

  • Visualizar el flujo de trabajo

Lo primero y lo más importante para usted es entender qué se necesita para el transcurso de un producto desde su pedido hasta su entrega. Solo después de entender cómo funciona actualmente el flujo de trabajo, puede aspirar a mejorarlo haciendo los ajustes necesarios.

Para visualizar su proceso en Kanban, necesitará un tablero con tarjetas y columnas. Cada columna del tablero representa un paso en su flujo de trabajo. Cada tarjeta Kanban representa un elemento de trabajo.

Cuando comience a trabajar en el elemento X, lo arrastra hasta la columna “Por hacer” y cuando el elemento esté acabado, lo mueve hasta la columna “Hecho”. De esta forma, puede fácilmente seguir el progreso y detectar los cuellos de botella.

 

  • Eliminar las interrupciones

El cambio de enfoque puede dañar seriamente su proceso y la multitarea (o multitasking) podría provocar generación de desperdicios. Esta es la razón por la cual, la segunda práctica de Kanban se enfoca en establecer los límites del trabajo en proceso (los límites WIP). Si no hay límites de trabajo en proceso, no está haciendo Kanban.

Limitar el trabajo en proceso (WIP) significa que un sistema de arrastre (pull) se aplica sobre partes o sobre todo el flujo de trabajo. Establecer un número máximo de elementos por etapa asegura que una tarjeta se “arrastra” al siguiente paso sólo cuando hay capacidad disponible. Tales restricciones iluminarán rápidamente las áreas problemáticas en su flujo para que pueda identificarlas y resolverlas.

 

  • Gestionar el flujo

La idea de implementar un sistema Kanban es crear un flujo continuo e ininterrumpido. Por flujo nos referimos al movimiento de elementos de trabajo a través del proceso de producción. Lo que interesa es la velocidad y la continuidad del movimiento.

Idealmente, queremos un flujo rápido e ininterrumpido. Esto significaría que nuestro sistema está creando valor rápidamente. O sea, minimizar el riesgo y evitar el coste de retraso, pero también hacerlo de manera previsible.

 

  • Hacer las políticas explícitas (Fomentar la visibilidad)

No puede mejorar algo que no se entiende. Esta es la razón por la cual el proceso debe estar bien definido, publicado y promovido. Las personas no se asociarían ni participarían en algo que no creen que sea útil.

Cuando todos estén familiarizados con el objetivo común, podrán trabajar y tomar decisiones con respecto a cambios que les moverán hacia una dirección positiva.

 

  • Circuitos de retroalimentación

Para que el cambio positivo ocurra, tenga éxito y sea duradero, se necesita hacer una cosa más. La filosofía Lean admite que las reuniones regulares son necesarias para la transferencia de conocimiento (circuitos de retroalimentación).

Tales son las reuniones diarias de pie para sincronizar el equipo. Se llevan a cabo frente al tablero Kanban y cada miembro comparte con los demás lo que él o ella hizo el día anterior y qué va a hacer el día de hoy.

También existen las reuniones para la revisión de entrega de servicios, la revisión de operaciones y la revisión de riesgos. Su frecuencia depende de muchos factores, pero la idea es que sean regulares, a una hora estrictamente fija, directas al grano y nunca innecesariamente largas.

La duración promedio ideal de una reunión de pie debe ser entre 10 y 15 minutos, y las demás reuniones pueden durar hasta una hora, en función del tamaño del equipo y los temas.

 

  • Mejorar colaborando (usando modelos y el método científico)

La forma de lograr la mejora continua y el cambio sostenible dentro de una organización se consigue a través de la visión compartida para un futuro mejor y la comprensión colectiva de los problemas que deben superarse.

Los equipos que tienen un entendimiento compartido de las teorías sobre el trabajo, el flujo de trabajo, el proceso y el riesgo, tienen más probabilidades de crear una comprensión compartida de un problema y sugerir acciones de mejora que pueden acordarse por consenso.

 

Kanban en pocas palabras

Kanban es algo más que notas adhesivas en la pared. La forma más fácil de entender Kanban es aceptar su filosofía y luego aplicarla a su trabajo diario. Si lee y entiende los cuatro principios básicos, la transición práctica parecerá lógica e incluso inevitable.

Visualizar el flujo de trabajo, establecer los límites del trabajo en proceso (WIP), gestionar el flujo, asegurar políticas explícitas y la mejora colaborativa llevarán a su proceso mucho más allá de lo que pueda imaginar. Recuerde organizar circuitos de retroalimentación regulares y el conjunto de todas estas piezas revelará el verdadero poder de Kanban.

Como ahora se está embarcando en un viaje hacia la comprensión de Kanban, esto es solo el inicio. Para obtener una comprensión más profunda de Kanban, explore los puntos fuertes de los tableros Kanban, los límites WIP y las tarjetas Kanban.

 

En resumen

Intentar aprender qué es Kanban podría ser difícil al principio, pero ahora cuando sabe de qué se trata, puede sacar el máximo provecho de los principales beneficios de Kanban:

  • Los tableros Kanban físicos y digitales le ayudan a visualizar su trabajo
  • Kanban es fácil de adoptar: sólo empiece con lo que tiene
  • Los límites WIP le permiten ser más eficiente