💻Bienvenida Sprint 7 Kanban

Ahora si, seguimos con la programación habitual. En este Sprint, vamos a hablar sobre el
método Kanban que, si bien no les vamos a pedir que desarrollen su proyecto con este
método, queremos invitarlos/as a que piensen qué elementos podría ayudar al avance de su
proyecto.

Bienvenidos al sprint 7. Acá vamos a ver la filosofía y sistema de Kanban, el WIP y Lead
Time. Así también como las diferencias y similitudes con el Scrum. Si bien en este
programa no vamos a implementar este método, te invitamos a que lo experimentes.

💻Filosofía y significado de Kanban

¿Escuchaste alguna vez hablar de Kanban? Fue desarrollado por los japoneses luego de la
segunda guerra mundial en plena crisis económica y social. Acá te contamos un poco más
de qué trata.
Hola, ¿cómo están? Hoy les voy a contar sobre Kanban, al igual que Scrum, Kanban es un
método o metodología para organizar el trabajo creativo de un equipo, haciendo entregas
con valor y sin sobrecargar a las personas. El método tiene sus orígenes en la marca de
autos japonesa Toyota Post Segunda Guerra Mundial. El país se encontraba en una crisis
económica profunda y una gestión ajustada de los recursos que llevó a que los
productores elaboren un sistema altamente eficiente que proporcione productos de bajo
coste y alta calidad para satisfacer las necesidades de los clientes. Se lo denomina como la
metodología de just in time o justo a tiempo, porque sólo se produce cuando existe una
demanda real de un producto o servicio. La palabra Kanban origina del término Kamban,
que significa cartel o tablero visual que indica la capacidad de trabajo disponible. Toyota lo
implementó para entender los flujos de trabajo qué, cuánto y cómo producir y planificar
en función a las disponibilidades de los distintos sectores de la empresa. Kanban cuenta
con cuatro principios. El primero es empezar por lo que estás haciendo ahora, concéntrate
en las tareas y proyectos de importancia inmediata o en las tareas que debes hacer ahora.
Número 2. Realizar cambios graduales y evolutivos. Evita aplicar cambios radicales. 3.
Mantener las mismas funciones y responsabilidades. Evita cualquier cambio organizativo.
4. Fomenta el liderazgo en todos los niveles. Por otro lado, Kanban tiene 6 principios. El
primero es Visualiza tu trabajo como bien dice el significado de su palabra. Kanban se
apoya en una tabla para visualizar el flujo de trabajo. Se puede visualizar con una tabla.
Unas cartas post-it. El segundo es limitar el trabajo en curso. Menos es más para esta
metodología. Es importante mantener pocas tareas en simultáneo para no sobrecargar al
equipo. El tercero, gestionar activamente el flujo de trabajo, gestionar y supervisar los
procesos para identificar los cuellos de botella y solucionarlos para mejorar la eficiencia.
Este método alienta a ir haciendo pequeños ajustes en vez de cambios abruptos y
demasiado grandes. En cuarto lugar, crea orientaciones para los procesos. Comunica y
establece un norte claro sobre cómo debe hacerse el trabajo y cuándo se considera
terminado el proceso de estar claramente definido, establecido y comunicado para que
todo el mundo esté familiarizado y tome decisiones en consecuencia. En quinto lugar,
existen los circuitos de retroalimentación. Utiliza herramientas y procesos para promover
la retroalimentación continua y temprana. En último lugar, evoluciona y mejora. Aplica
pequeños cambios graduales para adaptar y mejorar poco a poco tu flujo de trabajo y los
procesos operativos.

💻El Sistema Kanban, WIP y Lead Time

Hola, ¿cómo están? Les hago una pregunta: ¿cómo se imaginan el sistema Kanban?
Kanban funciona con una tabla de visualización, dependiendo del equipo, cuenta con
diferentes componentes, pero en general hay tres columnas que indican el backlog,
concepto que ya conocen el work in progress, lo que se está trabajando actualmente y en
último lugar, lo que ya se cerró el work in progress o WIP, en esta metodología debe ser
limitado, es decir, es importante mantener pocas tareas en simultáneo para no
sobrecargar al equipo. El WIP es una gran manera de establecer la cantidad de trabajo en
la que un equipo puede enfocarse a la vez, priorizando los objetivos más importantes. Las
ventajas del WIP son las siguientes: hay foco y claridad en qué tareas se está llevando a
cabo; hay mayor facilidad en la resolución de problemas porque son pocas las tareas que
se abordan en forma simultánea; hay un sentido de trabajo en equipo porque todos
aportan a la realización de una tarea. Ahora bien, ¿cómo nos aseguramos de que las tareas
se avancen en Kanban? Se habla del lead time o plazo de entrega. Es el período que
transcurre entre que una tarea sale del backlog y que alguien se compromete a realizarla,
el work in progress. Por lo general, un cliente no conoce todos los componentes de un
proceso, pero sí conoce el tiempo de entrega. Es así que debemos ser efectivos una vez
que nos comprometemos con la realización de la misma. Medir el WIP nos permite
mejorar el tiempo que tarda una tarea en avanzar de principio a fin. A esta altura, ustedes
son expertos en Scrum. Scrum y Kanban se parecen en que ambos son métodos para
hacer que los equipos trabajen de forma eficiente, ágil, lean y aportando valor en las
entregas. Tanto Kanban como Scrum se centran en liberar los productos pronto y con
mayor frecuencia. Ambos requieren de equipos altamente colaborativos y
autogestionados. Sin embargo, existen diferencias entre los enfoques. Kanban no requiere
de roles predefinidos, mientras que Scrum tiene roles predefinidos, como vimos, Scrum
Master, Producto Owner y miembro del equipo de desarrollo. Kanban se centra en la
entrega continua y en el Lead Time en cada entrega, mientras que es Scrum se centra en
sprints con un tiempo estipulado. En Kanban el trabajo se arrastra a través del sistema en
un flujo de una sola pieza, mientras que en Scrum el trabajo se arrastra a través del
sistema en lotes, a través de los backlogs de los sprints. Kanban permite hacer cambios en
cualquier momento, pero en Scrum no se pueden hacer cambios a mitad de los sprint.
Kanban es más apropiado en entornos operativos con alta incertidumbre, mientras que
Scrum es más apropiado en situaciones en las que el trabajo se puede priorizar en lotes
que se pueden dejar solos. En Kanban se utiliza siempre una tabla para visualizar las
tareas, mientras que en Scrum, se puede ajustar a las necesidades del equipo.

Lectura complementaria

¿Empezar con Scrum o con Kanban?

https://www.javiergarzas.com/2019/05/empezar-con-scrum-o-con-kanban-en-video.html

Kanban
33 comentarios / agil / Por jgarzas / 22 noviembre, 2011
Kanban es una palabra japonesa que significa algo así como “tarjetas visuales” (kan
significa visual, y ban tarjeta). Esta técnica se creó en Toyota, y se utiliza para controlar
el avance del trabajo, en el contexto de una línea de producción. El Kanban está dentro
de la estrategia Kaizen (te dejo un post sobre el Kaizen), es decir, la mejora continua y
continuada.
Aunque esta técnica la explicamos en el libro de gestión ágil de proyectos, me ha
parecido interesante hacer un resumen de la misma en este post.
Todo surgió en una metodología llamada Lean (te dejo un post sobre qué es Lean),
creada por Toyota para mejorar su producción usando técnicas just-in-time (JIT).
Kanban no es una técnica específica del desarrollo software, su objetivo es gestionar
de manera general como se van completando tareas, pero en los últimos años se ha
utilizado en la gestión de proyectos de desarrollo software, a menudo con Scrum (lo
que se conoce como Scrumban).
Las principales reglas de Kanban son las tres siguientes: (1) Visualizar el trabajo y las
fases del ciclo de producción o flujo de trabajo, (2) determinar el límite de “trabajo en
curso” (o Work In Progress) y (3) medir el tiempo en completar una tarea (lo que se
conoce como “lead time”). Veámos que significa cada uno de los anteriores.
1- Visualizar el trabajo en Kanban y las fases del
ciclo de producción, o flujo de trabajo.
Al igual que Scrum (te recomiendo este post introducción de Scrum), Kanban se basan
en el desarrollo incremental, dividiendo el trabajo en partes. Una de las principales
aportaciones es que utiliza técnicas visuales para ver la situación de cada tarea, y que
quizás habrás visto representado pizarras llenas de post-it.
El trabajo se divide en partes, normalmente cada una de esas partes se escribe en un
post-it y se pega en una pizarra. Los post-it suelen tener información variada, si bien,
aparte de la descripción, debieran tener la estimación de la duración de la tarea.

La pizarra tiene tantas columnas como estados por los que puede pasar la tarea
(ejemplo, en espera de ser desarrollada, en análisis, en diseño, etc.).

El objetivo de esta visualización es que quede claro el trabajo a realizar, en qué está
trabajando cada persona, que todo el mundo tenga algo que hacer y el tener clara la
prioridad de las tareas.
Las fases del ciclo de producción o flujo de trabajo se deben decidir según el caso, no
hay nada acotado. En la figura se han puesto un conjunto de fases de ejemplo.

2 – Determinar el límite de “trabajo en curso”.

Quizás una de las principales ideas del Kanban es que el trabajo en curso (Work In
Progress o WIP) debería estar limitado, es decir, que el número máximo de tareas que
se pueden realizar en cada fase debe ser algo conocido.
En Kanban se debe definir cuantas tareas como máximo puede realizarse en cada fase
del ciclo de trabajo (ejemplo, como máximo 4 tareas en desarrollo, como máximo 1 en
pruebas, etc.), a ese número de tareas se le llama límite del “work in progress”. A esto
se añade otra idea tan razonable como que para empezar con una nueva tarea alguna
otra tarea previa debe haber finalizado.

En la anterior figura de ejemplo el número límite del “work in progress” se ha colocado

entre paréntesis debajo del nombre de cada tarea. Podéis, por ejemplo, ver que el
límite del “work in progress” para las pruebas es 1.
La idea es: centraté en cerrar tareas y no en comenzar tareas. Por ello limitar el WIP
impide empzar cosas hasta que se han cerrado aquellas en las que se está ya
trabajando. Lo difícil aquí es encontrar el mejor WIP de un KANBAN.
3 – Medir el tiempo en completar una tarea.
El tiempo que se tarda en terminar cada tarea se debe medir, a ese tiempo se le llama
“lead time”. El “lead time” cuenta desde que se hace una petición hasta que se hace la
entrega.
Aunque la métrica más conocida del Kanban es el “lead time”, normalmente se suele
utilizar también otra métrica importante: el “cycle time”. El “cycle time” mide desde que
el trabajo sobre una tarea comienza hasta que termina. Si con el “lead time” se mide lo
que ven los clientes, lo que esperan, y con el “cycle time” se mide más el rendimiento
del proceso.
Puede haber más métricas, pero las anteriores son las realmente importantes,y
necesarias para el control y mejora continua.

Otras fuentes y recursos que te pueden interesar

Uno de los libros más populares, leídos y recomendados es el de Anderson, que fue el
libro que llevó Kanban al mundo de la tecnología.
Mi segunda recomendación es, sin lugar a dudas, el libro de Kniberg, me parece el más
práctico y conciso de todos. Eso sí, su ámbito son las metodologías ágiles y Kanban.
Una tercera y última recomendación, esta vez en castellano. Un libro que te puede dar
una visión general de Kanban, Lean y Jus-in-Time, no exclusiva del ámbito tecnológico,
es el libro de Kanban y Just-in-Time, de la asociación japonesa de gestión.
Alguna consideración final sobre Kanban
Una unión muy común es utilizar Scrum y Kanban. Aunque hay diferencias entre
ambos métodos, por ejemplo, las reglas de Kanban son muchas menos que las de
Scrum, Kanban no define iteraciones (Sprints), Kanban limita explícitamente las tareas
que se pueden realizar por fase (con el límite del work in progress), mientras que
Scrum lo hace de manera indirecta por medio del sprint planning, etc.

Esta unión Kanban – Scrum (o Scrumban) tiene sus particularidades, pero las dejo para
un futuro post.
Por qué Scrum no es Kanban y por qué
Kanban no es Scrum
1 comentario / General / Por jgarzas / 5 abril, 2016
La verdad que es tema es antiguo pero… no por ello lo suficientemente conocido. Y es
más que frecuente encontrar que ambos son utilizados como sinónimo. Y, cómo sabes,
ni mucho menos lo son, tienen parecidos, sí… pero no son lo mismo.

Hace como casi 5 años que escribí aquel post de ¿Qué es el método Kanban para la
gestión de proyectos?, que, con la veteranía que tiene, lo puedes tomar como
antecedente a este de hoy, y recordar que Kanban es una de las piezas clave de Lean,
algo de historia, etc.
En este caso, vamos con unas cuantas diferencias entre Scrum y Kanban, hay más, pero
por ir a lo más importante…

Las reglas de Kanban son muchas menos que las de

Scrum
Aunque Scrum no es que tenga muchas reglas, ya sabes que la guía oficial de Scrum
son 21 páginas, que, como siempre digo, si le quitas el índice, portada, etc., se te
queda en nada. No obstante, Kanban tiene menos, de hecho en Kanban se habla de
tres reglas: que el flujo de trabajo exista y sea visible, que se limite el trabajo en cada
parte del proceso (lo vemos luego) y que se mida (lead y cycle, lo vemos luego).

En este punto afecta también, aunque sea obvio después de lo anterior, que en
Kanban no se habla de roles, es decir, no hay (aunque luego tu puedes hacer lo que
quieras) Scrum Master, ni Product Owner ni equipo.

Kanban no define que haya iteraciones ni Sprints

Quizá la diferencia más popular, en Scrum una pieza clave es la división del tiempo en
Sprints… que en Kanban no existe. Por ello, hay quien a Kanban le pone el apellido de
“trabajo continuo”.

La manera de organizarse en Kanban es teniendo priorizado el trabajo pendiente, lo

cual vendría a ser similar en Scrum a tener un Product Backlog claro priorizado por
valor, y limitando el máximo de trabajo en cada parte del flujo de trabajo (en cada
columna del tablero, para que nos entendamos), es decir…
Kanban limita explícitamente las tareas que se
pueden realizar por fase, Scrum lo hace por Sprint
Lo hace con el popular “límite del trabajo en el proceso” o work in progress, para unos,
o in process, pero, en cualquier caso, el WIP para todos. Scrum también lo hace de
manera indirecta por medio del Sprint Backlog, ya que se cierra en el mismo el tope de
cosas a hacer en el Sprint. Pero en Kanban ese límite es más “fino” ya que es por
columna, mientras que en Scrum es por Sprint.

Lo anterior provoca que en Scrum, dentro de que es ágil, ya sabes “el cambio es
bienvenido”, las opciones de cambio sean menor que en Kanban, ya que durante el
Sprint no debería cambiarse nada. En Kanban no deberías tocar una tarea empezada,
pero las pendientes pueden cambiarse de orden en cualquier momento.

Kanban tiene dos métricas base

Una es el tiempo desde que algo está pendiente hasta que se termina, la otra es el
tiempo desde que se empieza a trabajar en algo hasta que se termina (los llamados
tiempos lead y cycle).

Esto es importante, no sólo para mejorar, y ver como van las cosas, sino también
porque, a diferencia de Scrum, en Kanban no habla de que cada item en la lista de
cosas pendientes debe ser de menor duración al tiempo del Sprint, pero al medir
tiempos, Kanban te acaba obligando a descomponer tareas en lo más pequeño
posible.

Aunque no es obligatorio, en Scrum, típicamente, la gente usa una métrica que es la

velocidad, que viene a ser el trabajo completado en el Sprint.

Consejo final…
Hasta aquí los métodos, ahora… ¿qué te recomiendo yo? Que pruebes, experimentes,
mezcles cosas de ambos, si crees que lo necesitas. Que empieces con lo que crees que
más te conviene y luego lo vayas adaptando a tu realidad.

Y si quieres leer más, te recomiendo el post de ¿Qué es el método Kanban para la

gestión de proyectos? y el libro de “Kanban and Scrum – Making the Most of Both”
Kanban… ¿realmente es ágil?
2 comentarios / General / Por jgarzas / 28 septiembre, 2016
Si asumimos que una manera de trabajar (piensa en cualquier framework, XP, Scrum,
etc.) se puede considerar bajo el paraguas Ágil porque siempre que se utilice como
debe cumple, de alguna manera, con los valores y principios del manifiesto ágil, según
este razonamiento… Kanban no es ágil (supongo que sabes de sobra qué es Kanban,
pero sino es así… lee esto antes).
Es decir, que Kanban puede usarse de manera ágil pero sus principios no son los del
manifiesto ágil, pudiendo incluso usarse Kanban a la perfección, con excelentes
resultados… sin seguir los valores del manifiesto ágil. Y eso (bueno, y otros) es lo que
diferencia a Kanban de Scrum, XP, etc.

De los cuatro valores del manifiesto ágil, el único que se puede argumentar que si
sigue Kanban por naturaleza es el de responder al cambio frente a seguir un plan.
Eso, por ejemplo, con Scrum no pasa, puedes hacer un mal uso de Scrum (o de
eXtreme Programming), y de esa manera no seguir los valores ágiles, pero si haces un
uso correcto de las reglas de Scrum… estás siguiendo los valores y principios ágiles. Es
decir, que Kanban puede usarse, siguiendo sus reglas, en modos no-ágiles pero Scrum
no. Y, de hecho, son muchas las diferencias entre Kanban y Scrum (tema del que ya
hablamos en Por qué Scrum no es Kanban y por qué Kanban no es Scrum)
Así que Kanban es compatible con la agilidad, sí, y es una gran idea, también, pero no
es ágil por naturaleza. Puedes usarlo en modo ágil sí, pero también puedes usarlo en
modo NO ágil sin saltarte ninguna de sus reglas, aplicándolas todas a la perfección.

El paraguas de métodos ágiles de Henrik Kniberg, ahí está Kanban, abajo, un poco
separado, pero ahí anda

Esto es así, siendo rigurosos e hilando fino, pero cierto es que te vas a encontrar
muchos sitios en los que a Kanban se le mete bajo el “paraguas de métodos ágiles”
(qué mejor muestra que esta). Muchos sitios que hacen trabajar a Kanban de manera
ágil. Incluso quien habla de “generaciones” de Kanban, siendo las últimas más ágiles. Y
hasta debates y polémicas sobre hasta qué punto Kanban es ágil o no lo es.
No obstante, la verdadera preocupación debería ser… ¿la manera de trabajo que
hemos adoptado es realmente la más efectiva y eficiente?

Pero, volviendo, para terminar, al objetivo de este post, que sepas que hasta el mismo
David Anderson, pionero en el uso de Kanban en tecnología, lo ha dicho y
escrito varias veces: Kanban es un camino alternativo a la agilidad.

La historia de Kanban
https://kanbantool.com/es/guia-kanban/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 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.

o 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.
o 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.
o 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.

o 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.
o 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.
o 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.
o 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

¿Sabías qué?
Kanban Tool® fue una de las primeras soluciones de gestión basadas en
la web que se centró en la gestión visual con el método Kanban. Ha
evolucionado a través de los años y todavía se considera la primera
opción en el espacio de gestión de proyectos. Pruébalo y capacita a tu
equipo.

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:
o Visualizar el Flujo de Trabajo
o Limitar el Trabajo en Curso
o Medir y Gestionar el Flujo
 o Hacer que las políticas de procesamiento sean explícitas
o 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.

La Guía oficial de Kanban

Imprimir