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.

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.

Ō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 (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.

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.

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 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 Scrum, Programació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.

• Gestión Ágil
  Además de Scrum y Lean, también se exploraron otros conceptos de cómo los equipos podrían ser más ágiles. En 2004 David Anderson publicó el libro “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results”, que cubría conceptos como flujo, cuello de botella, control visual y diagrama de flujo acumulativo, que luego incorporó al método Kanban.

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.

También en 2009, han surgido las primeras aplicaciones basadas en la web para gestionar proyectos con el método Kanban: Agile Zen, Kanban Tool y LeanKit Kanban.

Una versión temprana de Kanban Tool, fuente: kanbantool.com

A partir del 2010: Kanban para todos

A medida que el conocimiento y el uso de Kanban creció, se hizo evidente que Kanban funciona bien no sólo en el desarrollo de software, sino básicamente en cualquier proceso repetible. Manufactura, ventas, mercadeo, reclutamiento - todo tipo de proceso podría beneficiarse del Kanban. Incluso el ejército de los EE.UU. estaba ansioso por adoptar sus principios. Mientras se contaban más y más historias de éxito, empezó a quedar claro que el método Kanban necesita tener algunos principios subyacentes definidos.

En marzo de 2010 Henrik Kniberg y Mattias Skarin publicaron un minilibro gratuito “Kanban y Scrum - Obteniendo lo Mejor de Ambos”, que luego fue traducido a 14 idiomas.

En abril de 2010, David Anderson publicó “Kanban: Successful Evolutionary Change for Your Technology Business”. A pesar de que se centró en los negocios de tecnología, ofrecía algunas orientaciones generales sobre la aplicación y el uso de Kanban.

En 2011 Jim Benson y Tonianne DeMaria Barry publicaron “Personal Kanban”, mostrando que el Kanban también puede ser aplicado con éxito a nivel personal.

Numerosos otros libros y artículos en línea sobre el Kanban comenzaron a aparecer, documentando las experiencias individuales con el Kanban, y sus varias aplicaciones.

Por último, en 2016 se publicó “Essential Kanban Condensed” en el que se destila el Kanban en cinco prácticas o metas:

• Visualizar el Flujo de Trabajo
• Limitar el Trabajo en Curso
• Medir y Gestionar el Flujo
• Hacer que las políticas de procesamiento sean explícitas
• Usar Modelos para reconocer las oportunidades de mejorar los procesos.

Si no estás ejecutando éstas prácticas, entonces todo lo que tienes es un tablero Kanban y no un Sistema Kanban.

Para aprender más sobre la aplicación de Kanban en tu trabajo, lee Fundamentos de Kanban.