Unidad 4. Agile Process Management y Agile Framework:
KANBAN.
Dirección General de Empresa.
Consejería de Economía, Ciencia y Agenda Digital de la Junta de Extremadura.
NOTA. Referencias al género.
En la creación de este documento se ha hecho un esfuerzo consciente por utilizar un
lenguaje de género inclusivo. En algunos casos se ha optado por usar el masculino
genérico para aligerar el texto y facilitar su lectura. Aquí se entenderá que su uso se
aplica tanto a la identidad masculina, femenina o cualquier otra opción no binaria
referida a la identidad de género.
Los contenidos de este documento se distribuyen bajo licencia Creative Commons
Reconocimiento-NoComercial-SinObraDerivada 3.0 España.
Para ver una copia de la licencia visite:
http://creativecommons.org/licenses/by-nc-nd/3.0/es/deed.es_ES
Índice.
Unidad 4. Agile Process Management y Agile
Framework Kankan.
1. Introducción. .................................................................................5
2. Principios y prácticas Kanban. ...................................................18
3. Valores Kanban. ...........................................................................24
4. Las clases de servicio en Kanban. ..............................................26
5. Métricas de negocio y métricas de flujo: System Lead Time,
Cycle Time y Customer Lead Time. ........................................30
6. Descubre que hay detrás de los WIP Limits. ............................41
7. Los Feedback Loops para mejorar el flujo de trabajo. ............46
8. La experimentación de políticas explícitas. .............................48
9. System Thinking Approach to Introduce Kanban (STATIK):
Usar los elementos STATIK para ayudarnos a construir un
sistema Kanban. .........................................................................50
9. Diferencias entre Scrum y Kanban. ..........................................56
10. Lecturas recomendadas. ............................................................57
10. Bibliografía y Webgrafía. ...........................................................58
1. Introducción.
El Método Kanban es un modelo de trabajo que se viene aplicando desde hace
muchos años, no es como en algunos casos se piensa, de que sea algo reciente y
perteneciente a este siglo. Kanban tiene una importante historia a sus espaldas y data
de una época ya pasada.
Sí que es cierto que Kanban tal y como lo hacemos hoy tiene una historia más corta y
que se remonta al siglo pasado, concretamente, al momento en el que la industria
automovilística lo empezó a usar con un fin claro, construir lo necesario y con un nivel
de calidad excelente.
Kanban genera un cambio de paradigma importante, Kanban no es un método para la
gestión de “recursos”, sino que es una herramienta fundamentalmente utilizada para
la visualización de la carga de trabajo que tenemos, gestiona flujos de tareas con el
objetivo de dotarlos de mayor rendimiento y excelencia.
Todos ellos se centran en alcanzar el máximo rendimiento haciendo un uso
adecuado de los recursos disponibles centrándonos principalmente en generar lo que
se necesita, cuando se necesita y en la calidad esperada. Kanban huye de generar
una producción superior a la que se necesita partiendo de la optimización, y por ello
practica la técnica JIT (Just in Time), la cual veremos más adelante en profundidad.
También, este método aplica otras técnicas diferente, como WIP, experimenta con
políticas explícitas, clases de servicio, y otras que analizaremos, las cuales tratan de
generar que cada uno de los miembros que pertenezcan al servicio aporten su mayor
capacidad, y generen su máximo rendimiento sin llegar a bloqueos o provocar que el
rendimiento disminuya por saturación o exceso de carga.
El método Kanban se basa en 3 principios fundamentalmente, que son:
•Principio de Optimización
•Principio de Productividad
•Principio de Eficiencia
Las raíces de Kanban
Parte esencial de la metodología Lean que hoy conocemos procede de Kanban, y
que parte de un inicio en el Período Edo en Japón.
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 periodo 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 por
otro lado, ”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 algo en común, al igual que las modernas tarjetas
Kanban, y es que eran capaces de comunicar su contenido de forma clara y concisa.
1940’s: El Kanban de Manufactura Lean de Toyota
Producir solo es necesario, cuando sea necesario y en la
cantidad necesaria, Taiichi Ohno, ingeniero industrial
japonés, conocido por diseñar el sistema de producción
Toyota, Just in time.
En los años 40, la Toyota estaba lejos de ser el gigante industrial que conocemos hoy
en día. Tras la Segunda Guerra Mundial, en Japón la industria automovilística estaba
estancada y con pérdidas financieras. Había una fuerte competencia con la
fabricación de automóviles en América del Norte, sin embargo, el CEO de Toyota,
Kiichiro Toyoda, tenía la misión de cambiar la forma de ser y actuar de la empresa. Esa
fue la razón por la que en tres años puso en marcha un modelo productivo basado en
la innovación y la optimización de la organización de trabajo.
En 1954 Taiichi Ohno se convirtió en el director de la compañía, lo que permitió
experimentar con nuevas herramientas y principios de organización del trabajo. Éste
identificó y clasificó siete tipos de residuos, Muda, que conducen a una disminución
en el rendimiento y la productividad del sistema.
Imagen 1. Modelo MUDA. Elaboración propia.
La sobreproducción era considerara un desperdicio, puesto que la demanda de los
clientes puede cambiar con el tiempo, y además lo era mantener un gran inventario
de materias primas. Por tanto, ¿cuál era la solución? producir lo que se necesitaba y
solo cuando se necesitara, lo cual 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.
A pesar de ello, este enfoque tenía un ligero problema…¿cómo saber 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?
Para despejar esta casuística, Taiichi visitó los Estados Unidos en 1956,
concretamente la cadena de supermercados Piggly Wiggly, pues fue capaz de
mantener los estancos abastecidos con la cantidad justa de cada producto. Después
de regresar a 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 asociaban 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
que conformaban un equipo de trabajo solo podían trabajar en el nuevo producto a
medida que la tarjeta que señalaba la demanda de éste volvía a ellos, y solo una vez
que el número de tarjetas Kanban pendientes alcanzaba un umbral definido.
A su vez, 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.
Imágenes 2-3. Modelo Kanban. Kanbantool.
Este sistema redujo la acumulación de existencias, mejoró el rendimiento y
proporcionó una gran visibilidad del proceso. 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 del tal magnitud que Toyota pasó de
operar con pérdidas a ser el competidor global que es hoy en día. El significado de
“Kanban” asentó las bases de las modernas técnicas de gestión, conocidas como
Sistema de Producción Toyota.
La imagen inferior es un ejemplo de tarjeta Kanban original para el envío de ejes y
cojinetes de JTEKT (fábrica de componentes de automoción) a la planta de Toyota en
la ciudad de Takaoka. La tarjeta impresa tiene aproximadamente un tercio de tamaño
de una DINA4 y se adjuntaba al material de producción, cuando era necesaria se
imprimía una nueva.
Por ejemplo, el código “42450-12200-0” indica qué pieza es, número de unidades o fábrica de origen.
Código de localización
Número de pieza
Modelo No.
En ruta
Recepción
Nº pedido
Nombre del producto
Símbolo de unidad
Info referencia
Código suplementario
Nº interno
Fecha y hora
Código de
barras
Sucursal No.
Serie reeditada
Nombre
zona
QR
Code
Imagen 4. Tarjetas Kanban. Kanbantool.
Siguiendo con las definiciones, un sistema Kanban es un sistema pull (sistema “tirar”
frente al sistema push o “empujar” la producción, en el que el trabajo fluye a lo largo
del sistema, donde existen restricciones y limitaciones, físicas o impuestas).
Tradicionalmente, en los procesos de producción se fabrica para crear un stock ideal
basado en la previsión de la demanda del cliente final, esto es lo que se conoce como
un sistema push, dando lugar a la producción en grandes lotes y cantidades, lo que
supone una gran abundancia de dinero en material inacabado en curso, además del
espacio necesario de almacenaje.
En un sistema Kanban, el principio “pull” (arrastre o tirón) es inherente al mismo,
nuevas entradas de material solo se activan cuando el cliente pide un producto, esto
envía una señal en sentido inverso en la cadena de producción para activar la
fabricación. Por ejemplo: en un supermercado se repone una estantería vacía cuando
un producto falta.
2003-2008: el avance más significativo vino de la industria del software.
Durante décadas posteriores a los 50, las compañías han ido trabajando en la
búsqueda de maneras que permitiesen una producción más rápida y mejor. Desde
los años 70 hasta hoy día, el proceso de transformación en las grandes
organizaciones ha estado determinado, en gran medida, por lo que hoy se conoce
como el método Waterfall, como respuesta a enfoques poco estructurados
predominantes en los inicios de la disciplina de software. Este concepto, el cual
hemos mencionado brevemente en la Unidad 3,
Bajo esta metodología, la mayoría de los desarrollos de software o productos siguen
un proceso secuencial que involucra lo siguiente:
•Recopilación de los requerimientos del negocio;
•El diseño detallado de la solución-objetivo;
se basa en un proceso secuencial, inspirado en modelos de producción de
las industrias manufactureras. Y del mismo modo que el agua que cae en una
cascada no vuelve a subir, en el método Waterfall se requiere la finalización
completa de una fase antes de pasar a la siguiente (Management Solutions, 2019).
•Su traducción en un conjunto de requerimientos técnicos;
•La interpretación de los mismos;
•Y, por último, traducción en software por parte de un equipo de desarrollo
(proceso que podría durar meses, dependiendo de la naturaleza de la solución);
•Testing técnico y testing funcional (este último generalmente por parte del
usuario) del software.
•Eventual pase a producción.
Este enfoque se basa en gran medida en una planificación predictiva, documentación
exhaustiva, controles estrictos y la entrega final de un producto alineado con las
especificaciones originales. La razón de ser de esta metodología es que el tiempo
invertido en la planificación, documentación y mejora de los requerimientos se
traducirá en menos tiempo dedicado al desarrollo y testeo de la solución. Esta forma
de trabajar naturalmente llevó a configuraciones organizativas robustas, aunque, si
bien es cierto ha demostrado ser adecuada para proyectos en los que la solución
objetivo no está sujeta a cambios procedentes de la competencia en el mercado o
volatilidad en los requerimientos del negocio, y en los que existe bajo riesgo de que la
solución final se vuelva obsoleta durante el proceso de desarrollo o poco tiempo
después.
De hecho, según Management Solutions, el método Waterfall sigue siendo el principal
modelo de trabajo para la mayoría de las empresas, aunque son varias las
desventajas que la caracterizan, como: la pérdida de información en cada uno de los
muchos traspasos que tiene lugar entre los equipos de negocio y los equipos
tecnológicos (desde la especificación de los requerimientos hasta el software final), la
rigidez del proceso para gestionar solicitudes de cambio, o la burocracia y fuerte
documentación asociada al proceso end-to-end.
Como consecuencia de todo lo anterior, y como respuesta al cambio acelerado del
entorno, son muchas las compañías que comenzaron a adoptar nuevas
metodologías de trabajo como una forma de sobrevivir y prosperar. En la imagen
siguiente, vemos una cronología de los principales hitos en la mejora de la
metodología Agile para centrarnos en la adaptación de esta metodología de
desarrollo del producto en Kanban (aconsejamos ampliar la imagen para una
correcta visualización).
Imagen 5. Cronología de la Metodología Ágil. Elaboración
propia.
Observamos como en la década de los 80, ya aparecía por primera vez el término
Scrum publicado por Hardvard Business Review, prestado del rugby para subrayar la
importancia de los equipos en el desarrollo de productos complejos, como vimos en
la Unidad 3. Las investigaciones en los años 90 de Jeff Shuterland, quién desarrolla el
marco Scrum (1993), testimonian que el desempeño sobresaliente se logra cuando los
equipos son unidades pequeñas y auto-organizadas, y cuando dichos equipos se
les da objetivos específicos, y no tareas ejecutables.
En 2001, Sutherland, Ken Schwaber y otros 15 gestores de proyectos, ingenieros y
desarrolladores de software independientes se reunieron en Utah, convocados por
Kent Beck, para encontrar la fórmula que permitiera desarrollar un software con éxito.
“Acoger con beneplácito los cambios de requisitos” o “entregar con frecuencia un
software que funcione” eran consejos generales que ofrecían los principios del
Manifiesto. Sin embargo, esta falta de especificidad llevó a que se operara con varios
sistemas de gestión del trabajo para llenar este vacío, adoptando el Manifiesto y
convirtiéndose en el núcleo del desarrollo del software ágil en ese momento. Los más
notables fueron Scrum, en el cual hemos profundizado en la Unidad 3, 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 el Método Kanban en 2007.
SCRUM
Muchos equipos de Scrum usaban tableros con tarjetas de historia de los
usuarios, como radiadores de información.
¿Cómo funcionaba? 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 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, pues
proporcionaba una gran visibilidad del progreso, permitía la sincronización del
trabajo entre múltiples programadores y mejoraba el flujo de trabajo.
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. En un principio, apoyó en aquello en lo que Scrum no
era factible, como el acortar el tiempo de ciclo desde la solicitud del cliente hasta la
entrega, y asegurar un flujo constante de trabajo. Así pues, en la metodología
clásica de Scrum, después de una sesión de planificación en Sprint, el atraso del
sprint se congela, no se pueden hacer cambios en el. Ese estado tiene una duración
aproximada de 7 a 30 días, por lo que en el caso de haber una emergencia o una
característica específica que deba ser implementada rápidamente, se debe esperar al
tiempo establecido. Tal es el motivo por el que el Método Kanban con sus tableros
Kanban y su enfoque en el flujo dinámico, se convirtió en una solución a ese
problema, proporcionando una forma altamente estructurada, visible y flexible para
gestionar el trabajo.
Hasta su impulso en 2010, del que hablaremos ahora, muchos fueron los pioneros
que ayudaron a difundir su utilidad y el conocimiento sobre el mismo, hasta dar forma
a su futuro final. Hablamos, por ejemplo de Microsoft, quiénes para para incrementar
la productividad comenzaron a introducir elementos de Scrum y Kanban trayendo
como resultado el primer proyecto Scrumban en 2004, metodología de gestión de
proyectos que combina las dos estrategias ágiles comunes: Scrum y Kanban. En abril
de 2009, Henrik Kniberg publicó “Kanban vs. Scrum - a practical guide”, un exitoso
DESARROLLO DE
SOFTWARE LEAN
En 2003, Mary y Tom Poppendieck publicaron el libro “Implementing Lean
Software Development: From Concept to Cash” en el que se exploraba el uso
de la Teoría de Colas o Ley de Little (en concreto, se usa para estimar los
plazos de entrega de un equipo de trabajo) para reducir los tiempos de
entrega del software, y los tableros Kanban como elemento del espacio de
trabajo visual y organizativo. Hay que destacar que, en el 2005, Jim Sutton y
Peter Middleton publicaron el libro “Lean Software Strategies” en el que se
identifican los 5 principales principios de la producción Lean: Valor, Flujo de
Valor, Flujo y Pull, aplicados al desarrollo del software.
GESTIÓN ÁGIL
Además de Scrum y Lean, también se exploraron otros conceptos de cómo los
equipos podí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.
artículo que cubría los principios básicos de Kanban y que era fácil de entender para
cualquier persona y, a partir de ese momento, el conocimiento y uso de Kanban
creció, haciéndose evidente su función no solo en el desarrollo del software sino
básicamente en cualquier proceso repetible.
En 2016, Andy Carmichael y David J. Anderson publicaron “Essential Kanban
Condensed” en el que se detallaban cinco metas o principios básicos para aplicar la
metodología, tratándose de:
•Visualizar la carga de trabajo;
•Limitar el trabajo en curso;
•Medir y gestionar el flujo;
•Hacer que las políticas de procesamiento sean explícitas;
•Mantener una mejora continua.
Si no estás practicando estos principios, entonces únicamente tienes un Tablero
Kanban y no un Sistema Kanban.
El funcionamiento de Kanban.
Kanban optimiza el valor ofrecido al cliente al mejorar la eficiencia, efectividad y
previsibilidad general de un proceso siguiendo los principios descritos anteriormente,
los cuales explicamos en detalle a continuación (Management Solutions, 2019):
-Visualizar la carga de trabajo. El equipo usa una tabla Kanban para mostrar las
tareas a realizar a través de la cadena de valor. El trabajo se divide en fases, y
se describe en tarjetas que se pegan en la pared. Después, se nombran las
diferentes columnas para ilustrar dónde se sitúa cada elemento dentro del flujo
de trabajo. Al crear un modelo visual, el equipo puede observar la carga de
trabajo, incluidos los obstáculos y las colas, y aumentar la comunicación y
colaboración.
-Limitar el trabajo en curso. La metodología Kanban asigna límites explícitos a
la cantidad de elementos que pueden encontrarse en progreso en cada
estado del flujo de trabajo.
-Gestionar y mejorar el flujo. El objetivo es conseguir un flujo rápido y fluido
mediante la gestión y monitorización de su velocidad a través de métricas, KPIs
(Key Performance Indicators) y analíticas para garantizar transparencia y
gestión activa.
-Establecer políticas explícitas. Para asegurar la eficiencia del proceso, es
esencial que los miembros del equipo entiendan el estado del trabajo y cómo
necesitan hacer su tarea para garantizar el progreso. Para ello, es necesario
que el proceso esté claramente definido, publicado y socializado. Esto puede
hacerse a través de políticas, reglas de proceso o directrices.
-Mejora continua. Los equipos comparten propuestas para mejorar los
procesos, buscando alcanzar la máxima eficiencia.
La metodología Kanban se centra especialmente en la demanda para evitar en todo
momento el exceso de producción, y por ello utiliza el método de trabajo pull, aquel
que es solicitado o demandado, y que es capaz de asumirse, evitando así los
llamados “cuellos botella”. En el vídeo siguiente, puede entenderse de una manera
rápida y visual en qué consiste el método pull en un negocio de hostelería (no olvides
poner la traducción en español, si deseas).
Como hemos podido observar, los tableros Kanban suelen tener huecos con forma de
tarjeta en las columnas de los diferentes pasos del flujo que se relacionan con la
Vídeo 1. ¿Qué es Kanban? Development That Pays.
capacidad de asumir nuevos trabajos por parte del equipo antes de llegar a un nivel
de saturación.
En el gráfico podemos ver un tablero limitado con un WIP (Work in Progress) por
columna. También podemos ver un cuadro en el que observamos lo que representa el
trabajo en progreso. Asimismo, en cada una de las diferentes columnas podemos
observar que en ningún caso hay más tarjetas de las que marca el número que hay
debajo del nombre (o fase) de la columna.
En lo que respecta a las tarjetas blancas, se refiere a actividades que podemos
asumir en este punto del servicio y que ahora no están siendo ocupadas. Es en ese
punto en el que se debe solicitar actividad o trabajo a la columna anterior. Esto es lo
que representa el método pull diferenciándolo del sistema push.
Imagen 6. Ejemplo de tablero Kanban. Elaboración propia.
2. Principios y prácticas Kanban.
El Método Kanban, formulado por David J. Anderson, reconocido como líder de
pensamiento de la adopción del Lean/Kanban, se formula en base a dos principios
básicos y seis prácticas. Empecemos viendo, a continuación, los principios de
Gestión del Cambio en Kanban y de prestación de servicios o Service Delivery.
A) Principios de la gestión del cambio.
1. Empezar con lo que se hace ahora. En muchas ocasiones, cuando se habla de
metodologías de cambio, se buscan mejoras radicales tales como la
reingeniería de procesos totalmente nuevos.
Se basan en empezar con una hoja en blanco y evitar por completo los
problemas y restricciones de los procesos actuales. Sin embargo, el problema
es que un cambio tan radical conlleva en ocasiones inconvenientes: elevados
costes, alto riesgo y en general mucha resistencia al cambio.
Además, estos cambios radicales implican una enorme inversión de tiempo a
la hora de definir el nuevo proceso, las nuevas políticas y criterios, y el
desarrollo e implantación de nuevos sistemas de información que controlen y
apoyen el cambio. De esta forma, el radicalismo implica un alto riesgo.
También, puede llevar a la reformulación e incluso eliminar algunos de los roles
Imagen 7. Principios
Kanban. Cátedra ViewNext
USAL.
existentes, pues las personas que en ese momento trabajan cambiarán sus
funciones, pero también su status dentro de la organización, produciéndose un
proceso de ascenso o descenso. Esto provoca una gran resistencia al cambio,
por el miedo a lo desconocido, por el miedo a ser despedidos, a cobrar menos,
a ver reducido el status de las personas implicadas, o incluso por la exigencia
de los nuevos resultados tras los cambios.
Por estos motivos, es esencial cuando empezamos con una implementación
Kanban, entender y respetar inicialmente el proceso, los roles y las
responsabilidades actuales. En definitiva, se trata de empezar con lo que está
vigente e ir mejorándolo de forma gradual y continua, así obtendremos
mejoras con un coste bajo, pero también asumiremos menor riesgo, y
limitamos la resistencia al cambio.
2. Acordar la ejecución de la mejora a través de un cambio evolutivo. Como
decíamos, en lugar de invertir una gran cantidad de tiempo y dinero en diseñar
un proceso totalmente nuevo, en Kanban nos centramos en adoptar una
mejora continua y acordada.
Partiendo del proceso actual, que de alguna manera está funcionando aunque
seguramente con algún que otro problema (identificado o no), lo que hacemos
es invertir algo de tiempo, de forma sostenida y secuencial, en producir
mejoras en los aspectos básicos.
Así, con una estrategia de cambio evolutivo, si alguna fase de un proceso que
hemos modificado no funciona como está previsto, siempre será fácil ver la
causa del problema - ya que la modificación introducida será pequeña - y
corregirlo.
Y, en el peor de los casos, volver a la situación previa e intentar otra mejora,
será más sostenible que hacer una reingeniería completa. Pues como
decíamos, esta vuelta a la situación anterior al cambio es muy difícil si el
cambio es radical.
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.
3. Fomentar actos de liderazgo a todos los niveles. La mejora continua no se
alcanza solo gracias a la directiva de una empresa o a los trabajadores
directamente involucrados en el flujo de trabajo, sino que debemos alinear los
cambios desde los diferentes niveles organizativos.
Sabemos bien, por experiencia, que los cambios impuestos desde arriba
suelen chocar con la resistencia del personal de abajo, que además pueden
contar con otra información, que suele distorsionarse u omitirse y crean
suspicacias.
Por otro lado, los cambios propuestos desde abajo pueden contar con la
incomprensión y la falta de apoyo de la directiva, que en ocasiones impide que
se consoliden. Por este motivo, es importante que en el equipo se fomente una
mentalidad de mejora continua (kaizen) para alcanzar el rendimiento óptimo a
nivel de equipo, departamento o área.
4. 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, y que no provoca tanto miedo como para frenar el proceso.
B) Principios de prestación de servicios o Service Delivery.
1. Entender y enfocarse a las necesidades y expectativas de los clientes. El
primer paso para abordar la prestación de servicios es entender cuáles son las
necesidades de los clientes y, por supuesto, sus expectativas. Para ello,
debemos conocer los diferentes tipos de clientes, qué tipos de servicios
demandan, y qué hace que nuestro servicio sea adecuado para el propósito
para el que lo han solicitado, así como cuándo debe ser entregado y con qué
calidad.
Esto nos permitirá orientar correctamente las mejoras cuando implantemos
Kanban, así como entender las críticas, y las diferentes necesidades de los
clientes, para priorizarlos y maximizar el valor entregado por el sistema.
2. Gestionar el trabajo y dejar a las personas autoorganizarse las tareas.
Cuando Kanban habla de flujo de trabajo, se refiere a ítems de trabajo. Es
decir, a las peticiones o los servicios que solicitan los clientes y que debemos
trabajar dentro del sistema para proporcionárselos.
Para que realmente exista una mejora, es necesario tener una perspectiva
horizontal y de proceso, gestionando los servicios y peticiones (por ejemplo,
qué recursos y personas se asignan o resolver los problemas que lo frenan) y
cambiar el foco desde la óptima habitual, es decir, la vertical y departamental.
Como se decía anteriormente, Kanban no es un método de “gestión de
recursos”, sino que gestiona el trabajo, y precisamente por eso es necesario
que los miembros del equipo trabajen para dar el mejor servicio que atienda a
las necesidades del cliente, de una forma autoorganizada y responsable.
3. Evolucionar las políticas. En general, una de las principales causas en los
retrasos o alargamiento de los tiempos en la entrega de los servicios (cuellos
de botella, recursos de disponibilidad no inmediata, lotes grandes, sistemas de
trabajo push, etcétera) está relacionada con las políticas organizativas
instauradas en la organización.
Por lo tanto, si no hacemos evolucionar las políticas, estas lastrarán las
posibles mejoras. De aquí la necesidad de modificarlas para acompasarlas a un
proceso de innovación competitiva, y encaje del producto o servicio con el
mercado.
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.
David J. Anderson ha identificado 6 prácticas centrales que deben estar presentes
para una implementación con éxito.
•Visualizar el flujo de trabajo. Lo primero y lo más importante 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, y cada tarjeta Kanban
representa un elemento de trabajo. Cuando comience a trabajar en el
elemento X, lo arrastra hasta la columna “To do” o “Por hacer”, y
cuando el evento esté acabado, lo mueve hasta la columna “Hecho”,
como hemos visto en el vídeo anterior. 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 un 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 o los límites WIP, es decir, no se puede iniciar una tarea hasta
no haber terminado la anterior. Si no hay límites de trabajo en
proceso, no se está haciendo Kanban.
•Gestionar el flujo o workflow. La idea de implementar un sistema
Kanban es crear un flujo continuo e ininterrumpido. Por flujo nos
Imagen 8. Prácticas
Kanban. Cátedra ViewNext
USAL.
referimos al movimiento de elementos de trabajo a través del proceso
de producción, en concreto, lo que nos interesa es la velocidad y la
continuidad del movimiento, que se maximice la entrega de valor, se
minimice los tiempo de entrega, ser fluido y predecible.
•Hacer las políticas explícitas (fomentar la visibilidad). No se puede
mejorar algo que no se entiende. Esta es la razón por la cual el
proceso o flujo 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 la dirección positiva.
•Circuitos de retroalimentación. Para que el cambio positivo ocurra,
tenga éxito y sea duradero, se necesita una cosa más: la filosofía
Lean, la cual admite que las reuniones regulares son necesarias para
la transferencia del conocimiento (circuitos de retroalimentación o
feedback). También existen 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-15 minutos, y las demás reuniones pueden
durar hasta 60 minutos, en función del tamaño del equipo y de los
temas a tratar.
•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.
3. Valores Kanban.
El Método Kanban se basa en una serie de valores que rigen su funcionamiento. Está
motivado por la creencia de respetar a todas las personas que contribuyen a una
colaboración. Por tanto, aplicar de forma efectiva el método Kanban no consiste
solamente en aplicar unas prácticas, sino que requiere también de un cambio de
cultura y valores que marquen el comportamiento y la actuación de los equipos
implicados. De esta forma, se enriquecerá la orientación al cliente y los procesos de
mejora.
Mike Burrows definió 9 valores básicos, que son:
•Transparencia. Compartir la información aporta valor al negocio, y el
flujo de trabajo. El uso de un vocabulario claro y directo es parte de
ese valor.
•Equilibrio. Buscar el punto medio para no colapsar el trabajo, es decir,
un equilibrio en tiempo prologando entre la demanda y la capacidad
del equipo para asumir ciertas tareas o compromisos.
Imagen 9. Valores Kanban.
Cátedra ViewNext USAL.
•Colaboración. El método Kanban fue creado para mejorar el trabajo
en equipo.
•Enfoque en el cliente. Es importante conocer el objetivo de cada
proyecto, fluir hasta un punto de realización de valor, donde los
clientes reciben un producto o servicio requerido.
•Flujo. Visualizar el flujo es un punto de partida esencial en el uso de
Kanban, ya sea continuo o periódico.
•Liderazgo. La capacidad de inspirar a otros a actuar a través del
ejemplo, palabras y reflexión. La mayoría de las organizaciones tienen
cierto grado de jerarquía estructura arcaica, pero en Kanban se
necesita liderazgo en todos los niveles para lograr la entrega de valor
y la mejora.
•Entendimiento. Conocerse a uno mismo (autoconocimiento) y saber
el punto de partida del proyecto ayuda a ir hacia adelante.
•Acuerdo. El compromiso del equipo para avanzar hacia objetivos
comunes respetando las diferencias de opinión.
•Respeto. Valorar, entender y empatizar con el resto del equipo.
4. Las clases de servicio en Kanban.
Como decíamos, Kanban es un método ideado para definir, gestionar y mejorar
servicios, tanto de productos de software como físicos -y hacemos de nuevo la
mención del software, por estar íntimamente ligado a la creación de los marcos de
trabajo ágiles -.
Igualmente, como veíamos en sus principios y valores, Kanban se caracteriza por el
principio de “empieza por donde estés” - por medio del cual se consigue catalizar el
cambio rápido y focalizado dentro de las organizaciones- que reduce la resistencia a
un cambio en línea con los objetivos de la organización.
Así, Kanban se enfoca en la entrega de servicios de una organización: un servicio
tiene un cliente, el cual pide. De este modo, las clases de servicio son las categorías
de los elementos de trabajo que pueden imponer distintas políticas de selección y
procesamiento basadas en diferentes expectativas del cliente, valor relativo, riesgo o
coste del retraso.
En otras palabras, para priorizar en Kanban la entrega de valor necesitamos primero
clasificar a los ítems en categorías según su valor. Después, debemos tener unas
reglas respecto a cómo vamos a secuenciar (poner en cola) a cada ítem según la
clase de servicio (o categoría) a la que pertenezca. Y, finalmente, como muestra David
Coloma (Accredited Kanban Trainer) debemos tener unas reglas respecto a cuantos
recursos vamos a asignar a unos ítems u otros para asegurar que la temporización de
las entregas maximiza el valor.
Cuando hablamos de entregar el máximo valor tenemos que hacer una matización.
No se trata de poner antes el ítem con mayor valor, sino de poner antes aquellos que
van a perder más valor por el hecho de entregarlos más tarde. En otras palabras,
tenemos que mirar la velocidad de deterioro de valor para tomar decisiones de
priorización.
Este concepto fue propuesto por Don Reinertsen como una fórmula para seleccionar
el trabajo. El coste del retraso considera la agilidad en la entrega desde un punto de
vista económico, y se ha convertido en una de las formas más utilizadas para priorizar
en Kanban.
En función de esto, Kanban establece cuatro tipo de clases de servicio que definen el
coste del retraso:
”Expedite” (urgencia muy alta): los ítems de tipo acelerado (llamados expedite en
inglés) tienen un elevado coste por cada unidad de tiempo (horas, días…) que se
retrasa su resolución.
Por ello, deben solucionarse inmediatamente ya que tienen una importancia que
puede afectar la propia supervivencia de la organización.
Ejemplo; caídas del sistema informático en bancos, páginas de tiendas online o
comercio electrónico, otros.
Imagen 10. Tipos de coste del retraso en Kanban. Itnove.
Estos arquetipos, como explica Anderson, pueden ser usados para ayudar a ordenar
el trabajo, o pueden definir diferentes clases de servicio, aplicando diferentes
políticas a cada tipo de trabajo.
”Estándar” (la clase típica): en este tipo de ítems, cada período (horas, días,
semanas, meses) que se retrasa su entrega tiene un coste elevado, pero no ponen
en juego la existencia de la organización.
Es decir, un retraso en los ítems estándar no hace desaparecer a la empresa, pero sí
que la hace menos competitiva.
Ejemplo: desarrollo de nuevos productos de catálogo, reducción de costes de
proceso, entre otros.
“Fecha fija” (fecha determinada de entrega): en este caso, entregarlos antes de
una determinada fecha no aporta ninguna ventaja adicional. Pero entregar más
tarde de esta fecha -por muy poco que sea- tiene un coste muy elevado.
Ejemplo: requisitos regulatorios o legales con fecha concreta bajo pena de
sanción, lanzamiento de un producto de Navidad, día de San Valentin, día del
padre, etcétera.
”Intangible”: Finalmente nos encontramos con los ítems de tipo intangible.
Son ítems que pueden retrasarse con un coste muy bajo a corto plazo. Pero son
ítems que sabemos que en un momento desconocido del futuro tendrán un coste
muy elevado.
En ocasiones pueden ser arrinconados por ítems acelerados, estándar o intangibles,
que tienen un coste del retraso más elevado a corto plazo.
Ejemplos: aquí nos encontramos con los proyectos de mejora internos o de mejora
de calidad.
La relación con los consumidores o usuarios de servicio, los clientes, constituye un
aspecto clave de la gestión del flujo. El Lead Time, que veremos más en detalle,
especialmente el tiempo de entrega al cliente, es una métrica clave para estos,
además de muchos aspectos que también lo son, como el ritmo de despliegue o
entrega, ratio o tasa de errores (y otras métricas de calidad), y la previsibilidad de
entrega. Pueden definirse diferentes niveles de servicio como los que siguen a
continuación para gestionar las métricas en un sistema Kanban.
-Expectativa del nivel de servicio que los clientes esperan.
-Capacidad del nivel de servicio al que el sistema puede entregar.
-Acuerdo de nivel de servicio que es acordado con el cliente.
-Umbral de la adecuación del servicio el nivel por debajo el cual este es
inaceptable para el cliente.
5. Métricas de negocio y métricas de flujo: System
Lead Time, Cycle Time y Customer Lead Time.
Como decíamos, el método Kanban tiene una serie de principios y prácticas y, tal
como hemos visto, una de ellas es la optimización del flujo de trabajo. Esto es vital si
queremos conseguir y mantener el ritmo de trabajo estable y eficiente.
Una herramienta clave para esta optimización son las métricas, pero primero
recordemos qué es aquello del flujo de trabajo.
Es verdaderamente importante tener claro estos dos aspectos:
•¿Cuáles son aquellas fases o estados que conforman el flujo de
trabajo de tu equipo?
•¿Qué tiene que ocurrir para que una tarea entre y salga de un
estado?
Anteriormente lo hemos estado viendo, inclusive puedes irte al vídeo de nuevo, pero
te sorprendería cuántas respuestas diferentes podemos obtener si preguntamos a
nuestros compañeros ¿Cuándo consideráis que hemos terminado una tarea?, o
¿Terminar significa entregar?, sobre todo si colaboramos con otros equipos o áreas en
el desarrollo de nuestro producto.
Aunque consigamos definir un flujo de trabajo adecuado y claro, recuerda que nunca
debes darlo por definitivo. El producto que se desarrolle, el equipo y el contexto en el
que se trabaje cambiarán, y si buscas mejorar tus procesos tendrás que modificar tu
flujo de trabajo para adaptarlo y que siga siendo eficiente y eficaz.
El flujo de trabajo es un conjunto de estados, fases o momentos por lo que
pasan cada una de las actividades que forman parte de nuestro trabajo. En otras
palabras, es el ciclo de vida de nuestras tareas, comenzando desde que se
identifica la necesidad del usuario hasta que se entrega.
Principales métricas en Kanban.
Una vez hemos analizado y definido el flujo de trabajo que mejor se adapta a nuestro
contexto, podremos comenzar a aplicar las métricas que nos ofrece Kanban para
hacer los procesos y las prácticas más eficientes.
A. Customer Lead Time.
El Customer Lead Time, tiempo de entrega del cliente o el tiempo de entrega
total, se define como el tiempo que tarda un cliente en recibir un producto o
servicio desde el momento en que el cliente realiza el pedido o realiza una
transacción de compra.
El tiempo de entrega del cliente puede utilizarse como medida general de la
eficiencia de toda la cadena de suministro de una organización. De esta forma,
podríamos dividirlo en diferentes componentes para evaluar las operaciones:
-Tiempo de procesamiento del pedido: tiempo transcurrido desde que
un cliente realiza el pedido hasta que se genera el pedido de compra o
la orden de producción.
-Plazo de ejecución de producción: tiempo necesario para producir o
procesar el pedido.
-Plazo de entrega: tiempo necesario para entregar un pedido o producto,
una vez fabricado y preparado para su entrega.
B. Lead Time.
Nos permite saber cuánto tardamos en responder a una necesidad del
usuario. Mide el tiempo que transcurre desde que una necesidad es
identificada (entra en nuestro flujo de trabajo) hasta que se entrega (sale del
flujo de trabajo). Es decir, mide el ciclo de vida de una actividad. Ejemplo:
decides comprar por internet un billete de avión para tus vacaciones. El Lead
Time de adquirir el billete empieza a correr en el momento en el que te sientas
enfrente al ordenador y abres un navegador, y termina cuando tienes tu billete
electrónico en tu email.
El tiempo de ejecución para el desarrollo de un requisito de cliente es el
tiempo desde el momento en que el equipo empieza a trabajar en el mismo
hasta que la funcionalidad esté lista para subirla en producción (en el caso de
que se trate de un software). Es decir, el tiempo que transcurre entre el
momento en que el requisito entre y salga del sistema Kanban (alcanza una
columna con límite WIP infinito).
En términos más concretos, el Lead Time de un PBI (Product Backlog Item)
mide el tiempo que ha transcurrido desde que éste se creó en el Product
Backlog hasta que se puso en DONE, pasando por todos los estados
intermedios que tenga nuestro flujo de trabajo particular: priorización,
desarrollo, pruebas de calidad, etcétera.
Imagen 11. Sistema Lead Time. Berriprocess.
Imagen 12. Sistema Lead Time. Netmind.
Para medir bien y consistentemente el Lead Time, es importante establecer los
límites del sistema Kanban. A la hora de saber cómo se calcula el lead time hay
que tener en cuenta diversos factores tanto internos como externos. No
obstante, también hay que tener en cuenta que existe una fórmula de lead time
concreta, la cual nos va a permitir saber cómo se calcula y obtener un dato
concreto que podemos utilizar siempre que sea necesario.
Lead Time = fecha de entrega - fecha de pedido.
Veamos algunos ejemplos de lead time en una empresa:
-24 horas: este es muy habitual, especialmente en el caso de depósitos
regionales o comarcales, donde las existencias se deben reponer de
manera diaria.
-1 semana: este suele ser común en el caso de mayoristas que mandan los
productos en un espacio local o provincial.
-3 meses: este es muy común en el caso de procesos logísticos que
impliquen el envío de productos a nivel internacional, especialmente
cuando se trata de envíos intercontinentales.
C. Cycle Time (CT) o tiempo de ciclo.
El Cycle Time (CT) o tiempo de ciclo es una métrica que muestra el tiempo
que un equipo tarda en entregar una tarea desde que comienza a trabajar en
ella. Cuantifica, de este modo, el tiempo que transcurre desde que un equipo
inicia un trabajo (“in Progress”) hasta que éste cumple con la definición de
terminado (“Done”).
Es, por tanto, una medida de velocidad fundamental para analizar el
rendimiento de un equipo. ¿En qué se diferencia del Lead Time? El CT no nos
da información sobre cuánto hago esperar a mi usuario, sino sobre cuán
eficiente soy en realizar el desarrollo de una tarea y entregarla.
Un ejemplo: considerando el tiempo que los elementos pasan en el Backlog,
un PBI (Product Backlog Item) podría tener un Lead Time muy alto y un Cycle
Time muy corto: la diferencia es, casi en su totalidad, el tiempo que se ha
tardado en priorizar ese PBI.
El Diagrama de Flujo Acumulativo (CFD) es una herramienta analítica,
fundamental para el método Kanban. Permite a los equipos medir el tiempo
de entrega y de ciclo promedio, así como la cantidad de elementos de
trabajo en curso. Cuando hay un impedimento a punto de ocurrir dentro del
proceso, el CFD es dónde se verá primero, además, es el más utilizado y más
común de los diferentes sistemas de medición de Kanban. En lugar de que el
gráfico se mantenga uniforme y aumente suavemente, en este caso habrá una
interrupción, un ascenso o descenso repentino; entonces, en lo que respecta a
la capacidad de predecir problemas, este es el gráfico idóneo en un equipo
ágil.
Visualiza cómo se acumulan las tareas a lo largo del tiempo, junto con su
distribución a lo largo de las etapas del proceso. El gráfico se construye a partir
de bandas de colores de tareas reunidas en varias columnas; así, un color
representa una columna, de modo que cada banda muestra cuántas tareas se
Imagen 13. Sistema Lead Time. Netmind.
encuentran en qué etapa del proceso, y en un tiempo determinado: este es el
valor horizontal.
El diagrama ideal es el que, por ejemplo, se presenta en la siguiente imagen,
con bandas que ascienden más o menos uniformes, a excepción de la banda
de “tareas completadas”, que debía aumentar continuamente. Lo que denotaría
un aspecto negativo sería un ascenso o descenso repentino de cualquier
grupo de tareas -esto sin duda señalará un problema-. Una acumulación de
cuello de botella, y mientras se detecte a tiempo esto puede ser contrarrestado
abordando el problema en equipo. Otro aspecto poco deseable es que la
banda relacionada con las tareas “en progreso” se vuelva repentinamente muy
alta, ya que muestra que la cantidad de tareas que se están manejando en ese
momento es demasiado grande y, por lo tanto, es probable que todo el
proyecto se retrase.
El siguiente vídeo explica perfectamente cómo poder hacer un buen Diagrama
de Flujo Acumulado.
Imagen 14. Diagrama de Flujo. Kanbanize.
D. Ley de Little.
Es un sistema de flujo que no está en tendencia (y en el que todos lo
elementos que se seleccionan se entregan), hay una relación simple entre los
promedios de las siguientes métricas durante un periodo específico.
Donde, la tasa de entrega (delivery rate) es la cantidad de unidades de trabajo
determinadas por periodo de tiempo; el WIP es la cantidad de tareas que
hacemos a la vez, y el Lead Time, como hemos visto, es el tiempo que
transcurre desde que nos solicitan un trabajo hasta que lo terminamos (tiempo
que pasa nuestra tarea en nuestro sistema).
Nuestra tasa de entrega y nuestro lead time no podemos modificarlos.
Podemos tratar de mejorar nuestros tiempos, pero llega un momento en el
que las tareas tardan lo que tardan. De la Ley de Little deducimos que, si
queremos reducir el tiempo que las tareas pasan en nuestro sistema, debemos
Vídeo 2. Diagrama de Flujo. Cris Rúa, Youtube.
disminuir la cantidad de elementos que hacemos; que las tareas estén poco
tiempo en nuestro sistema es beneficioso: recibimos feedback antes,
reducimos coste por unidad de trabajo, y evitamos cambios de foco entre
muchas tareas. De esta manera, somos capaces de dar un mejor servicio y, por
tanto, tener un mejor impacto en nuestros clientes.
Podemos utilizar la Ley de Little para examinar los indicadores de flujo de otras
partes de un sistema Kanban, no solo entre los puntos de compromiso y
entrega, en cuyo caso, en lugar de Tiempo de entrega o Lead Time usamos el
Tiempo en Proceso o TIP para el periodo en el que un elemento está en el
proceso de que se trate. Términos más específicos como el Tiempo en
desarrollo, Tiempo en pruebas, Tiempo en Sistema (sinónimo de System Lead
Time) o Tiempo en cola también se pueden usar.
El término Rendimiento (Throughput) se utiliza en lugar de Tasa de entrega, si
el final del proceso en cuestión no es el punto del entrega. Esta es una
formulación alternativa de la Ley de Little utilizando estos términos: WIP
(cantidad de tareas que hacemos a la vez) y el TIP (periodo en el que un
elemento está dentro del proceso que se trate).
Mostramos de nuevo un Diagrama de Flujo Acumulado, donde se representan
gráficamente el número acumulado de elementos que llegan y se salen de un
sistema.
Imagen 15. Diagrama de Flujo.
Veámoslo detenidamente. El promedio aproximado del Lead Time (Approx Av.
LT) y el promedio WIP (Approx Av. WIP) están marcados por el diagrama. La
pendiente de la hipotenusa del triángulo es el promedio de la Tasa de Entrega
(Average Delivery Rate) durante este periodo y, de acuerdo con la Ley de Little,
se puede ver así:
Los promedios reales de Lead Time y WIP tienen que ser calculados a partir de
elementos individuales, pero en sistemas sin tendencia se aproximarían a estos
valores.
La Ley de Little proporciona un hallazgo importante sobre los sistemas Kanban:
con el fin de optimizar el Tiempo de entrega para los elementos de trabajo,
hay que limitar el trabajo en curso. Esta es una de las prácticas generales de
Kanban.
E. Historiograma de rendimiento.
El objetivo de los gráficos de histogramas es representar visualmente la
productividad del equipo en el pasado. Se mide por la cantidad de tareas que
se terminaron cada día y el tiempo que se tomaron.
Imagen 16. Diagrama de Flujo. Kanbanize.
El eje vertical muestra el número de días que tuvieron un determinado
rendimiento. El eje horizontal representa el rendimiento real como una
cantidad de elementos de trabajo completados. Cada columna contiene el
número de días que tuvieron el mismo rendimiento. La altura de las diferentes
columnas depende de la cantidad de días que caen en ella como categoría.
Los histogramas de rendimiento le permiten:
-Aplicar filtros.
-Elegir periodos.
-Excluir diferentes datos como prioridad, asignado, color de tarjeta,
etcétera.
F. Trabajo en Curso envejecido.
El seguimiento del envejecimiento de WIP es básicamente un análisis de flujo.
Te permite visualizar cómo avanzan las tareas de “solicitado” a la columna
“hecho” en tu tablero Kanban. Estas pasan diferentes cantidades de tiempo en
cada una de las sub-columnas, por lo que es importante saber dónde se está
desacelerando el proceso para determinar por qué y cómo mejorarlo.
Teniendo estos datos, puedes obtener fácilmente una idea de cómo se
desempeñó el equipo en contextos similares en el pasado. Estas estadísticas
podrían usarse para motivar nuevos objetivos estratégicos frente a la alta
gerencia y como puntos de discusión dentro del equipo.
¿Cómo el gráfico de WIP Envejecido?
Una forma fácil de realizar un seguimiento del WIP envejecido es mediante el
uso del gráfico de trabajo en curso envejecido, que forma parte de algunas
soluciones de software Kanban profesionales.
Es una herramienta fácil de usar, ya que se ve similar al tablero del equipo. El
gráfico extrae datos del tablero y los presenta de manera clara y visual para
resumir el flujo.
Cada gráfico de trabajo en curso envejecido contiene los siguientes
elementos:
-Columnas (eje horizontal)
-Edad, en días (eje vertical izquierdo)
-Percentiles de ritmo (eje vertical derecho)
-Tareas (puntos en el gráfico)
Para ser más precisos, podemos elegir fechas específicas para monitorear
seleccionando un marco de tiempo concreto. El eje horizontal representa todas
las etapas del proceso (las columnas del tablero). En la parte superior, encima
de cada columna, hay un indicador WIP que muestra cuántas tareas están en
curso de cada etapa. Por último, el eje vertical visualiza cuánto tiempo ha
pasado cada tarea en esa sección, en días.
Imagen 17. Diagrama de Flujo. Kanbanize.
6. Descubre que hay detrás de los WIP Limits.
Como se ha explicado anteriormente, la abreviatura WIP significa “Work In Progress” o
“Trabajo en Proceso” en español. En pocas palabras, WIP es la cantidad de tareas en
las que un equipo está trabajando actualmente, delimitando la capacidad de los flujos
de trabajo en cualquier momento.
El llamado Work In Progress, WIP, consiste en limitar la cantidad de tareas que pueden
estar “en progreso”, es decir, siendo realizadas. Esto tiene una importancia vital a la
hora de no saturar un recurso. Bien un recurso de fabricación, una persona del equipo
o un proceso concreto. En el momento que limitamos el WIP estamos limitando la
cantidad de trabajo, o más bien de tareas, que se pueden realizar a la vez. Así se
puede ir realizando una tarea al tiempo. La mejora en la eficiencia es evidente al no
tener que cambiar de tarea por una más “urgente” (u otras) y luego volver a trabajar
en la anterior.
¿Por qué se debería limitar el trabajo en progreso?
Los límites del trabajo en proceso (WIP) restringen la cantidad máxima de elementos
de trabajo en las diferentes etapas (columnas del tablero Kanban) del flujo de trabajo.
La implementación de los límites de WIP ayuda al equipo a enfocarse solo en las
tareas actuales y así le permite terminar más rápido con los elementos de trabajo
individuales.
Lo más importante es que al aplicar los límites WIP, el equipo tiene la oportunidad de
localizar los cuellos botella de los procesos de trabajo antes de que éstos se
conviertan en bloqueos.
Los límites de WIP se consideran un prerrequisito importante para entregar valor a su
cliente lo más rápido posible. Esto hace que los límites WIP sean un activo valioso del
método Kanban.
¿Por qué debería utilizar los límites WIP de Kanban?
En realidad, limitar el trabajo en proceso es una de las principales prácticas que
enmarca el método Kanban y lo hace tan eficiente. Los límites WIP de Kanban
aseguran que el equipo mantendrá un ritmo de trabajo óptimo sin exceder su
capacidad de trabajo.
En el contexto de los tableros Kanban, que ya hemos visto, el límite WIP de Kanban es
el controlador de acceso que garantiza que comenzará la misma cantidad de trabajo
que ha sido terminada dentro de la organización. Esto evita la acumulación de trabajo
sin terminar, que podría inundar los procesos.
Además, la aplicación de límites WIP en su tablero Kanban te ayudará a detectar los
bloqueos del proceso de trabajo y evitar que los miembros del equipo cambien
periódicamente entre las tareas. Estos pasos tendrán un impacto positivo sobre la
eficiencia y mejorarán la productividad del equipo.
Imagen 18. Tablero básico Kanban. Kanbanize.
Imagen 19. Detección de cuello botella. Kanbanize.
La imposición del Límite WIP al tablero expuso un cuello de botella de proceso, como
vemos en la imagen anterior. En un equipo de dos, la aplicación de un límite WIP de
una tarea por persona evitaría el cambio de contexto y revelaría de forma inmediata la
diferencia en las tasas de rendimiento.
En este caso, los límites excedidos señalarían la necesidad de revisar y de asignar
potencialmente a más personas en la etapa de trabajo más difícil. Al final es cuestión
de lógica, si ves una columna en la que las tareas entran más rápido de lo que salen,
el trabajo empezará a acumularse y el problema se hará visible para todo el equipo.
Esto puede deberse a un problema temporal o a un cuello de botella en proceso. Por
ello, si se traza un mapa detallado del flujo de trabajo, con columnas dedicadas a
todas las fases de trabajo, se podrá comprender de un vistazo dónde se pueden
hacer mejoras.
Si se desea aumentar el ritmo de entrega de valor a los clientes, se deberá
mantener a todos los equipos centrados en terminar el trabajo, en lugar de
empezar uno nuevo.
De este modo, dejarán de empezar nuevos trabajos y se concentrarán en terminar los
que ya están en marcha. Saber que todo el mundo puede ver lo que está haciendo
cada persona es también un gran motivador para buscar un mejor rendimiento todo el
tiempo.
Imagen 20. Aplicación de límites de WIP (trabajo en curso).
Kanbanize.
Configuración de límites WIP Kanban
Si es necesario, los límites WIP de Kanban deben ser ajustados. No hay una fórmula
predeterminada que le dirá cómo configurar los límites óptimos del trabajo en
proceso.
Antes de aplicar los límites WIP a su tablero Kanban, físico o electrónico, debes tener
en cuenta que su flujo de trabajo cambiará dinámicamente porque no es un sistema
aislado.
Por lo tanto, debe monitorizar el flujo de trabajo de su equipo de manera regular y
controlar los límites WIP en función de los factores constantemente cambiantes como
los nuevos requisitos comerciales, las demandas de los clientes, el tamaño a la
capacidad del equipo, problemas técnicos inesperados, etcétera.
Para estos fines, la mayoría de las plataformas Kanban modernas en línea están
equipadas con poderosas herramientas métricas Kanban, las cuales hemos mostrado
con anterioridad, donde se puede verificar y analizar información esencial sobre el
flujo de trabajo del equipo.
Hay una regla general para asegurarse de que el sistema Kanban funcione para su
equipo. Los límites WIP no deben aplicarse a cualquier coste, a no ser que exista
una tarea urgente que deba considerarse como tarea de prioridad máxima. Sin
embargo, priorizar tareas de esta manera debería ser exclusivo, pues al contrario se
perderá el sentido de crear un flujo de trabajo ininterrumpido y de aumentar la
eficiencia del equipo. Por eso es importante asegurarse de que éste comprenda las
reglas y las prácticas básicas de Kanban.
Normalmente, configurará los límites WIP según la actual capacidad de trabajo del
equipo. Sin embargo, una vez que los configure, deberá observar el proceso de
trabajo y, si es necesario, ajustar los límites WIP. Al final, cada flujo de trabajo cambia
dinámicamente y necesita una mejora continua.
En resumen
La aplicación de los límites WIP le permite crear un flujo de trabajo ininterrumpido y
utilizar la capacidad de trabajo del equipo en niveles óptimos de la siguiente manera:
-Previene la sobrecarga de procesos de trabajo;
-Ayuda a localizar los bloqueadores y a disminuir los cuellos de botella en su
flujo de trabajo;
-Le da la oportunidad de ofrecer lo más rápido posible valor a los clientes
finales;
-Previene un cambio de contexto constante entre los elementos de trabajo.
7. Los Feedback Loops para mejorar el flujo de
trabajo.
Los circuitos de alimentación (en inglés feedback loops) son una parte esencial de
cualquier proceso controlado y especialmente importantes para un cambio evolutivo.
Mejorar la retroalimentación en todas las áreas del proceso es importante,
especialmente en los que veremos a continuación.
•Alineación con la estrategia
•Coordinación operacional
•Gestión de riesgos
•Mejora del servicio
•Retroalimentación
•Flujo
•Entregas a cliente
Anderson define siete oportunidades de retroalimentación específicas para Kanban,
o cadencias. Las “cadencias” son las reuniones y revisiones cíclicas que dirigen la
evolución – cualquier cambio y prestación de servicio efectiva. “Cadencia” también
puede referirse al periodo de tiempo entre cada revisión – un día laboral o un mes,
por ejemplo. Elegir la cadencia adecuada depende del contexto y es crucial para un
buen resultado. Revisiones demasiado frecuentes pueden obligar a cambiar cosas
antes de observar los efectos de cambios anteriores, pero si no son suficientemente
frecuentes, el rendimiento bajo puede persistir más tiempo del necesario.
El esquema que mostramos a continuación muestra las frecuencias aconsejables para
las revisiones en un contexto típico de empresa o servicios múltiples. Expliquemos las
7 “cadencias”:
A. Revisión de la estrategia: para seleccionar los servicios que se van a
prestar, y revisar las condiciones del entorno.
B. Revisión de las operaciones: para entender el balance entre los servicios y
el despliegue de recursos para maximizar la entrega de valor al cliente.
C. Revisión de los riesgos: para entender los riesgos de las entregas
efectivas de servicios.
D. Revisión de la prestación de servicio: para examinar y mejorar la
efectividad de un servicio.
E. Reunión de retroalimentación: para mover los ítems de trabajo dentro del
sistema y supervisar la preparación de opciones para una selección futura.
F. La reunión de Kanban: para realizar una coordinación diaria de auto-
organización y revisión de la planificación del equipo que participa en la
prestación del servicio. Es una breve reunión diaria enfocada en completar
los elementos de trabajo y desbloquear asuntos.
G. Reunión de planificación de la entrega: para supervisar y planificar
entregas a los clientes.
Imagen 21. Revisión de la estrategia. Tecnofor.
8. La experimentación de políticas explícitas.
Llamamos “políticas explícitas” en Kanban a la forma que tenemos de articular y
definir un proceso que va más allá de la definición del flujo.
Las políticas de proceso, en todo caso, deben ser escasas, simples, estar bien
definidas, ser visibles para todos, deben aplicarse siempre y deben poder ser
modificables por los que proporcionan el servicio.
Y es que, curiosamente, las políticas que pueden parecer intuitivamente obvias (por
ejemplo, “cuanto antes se empiece, más pronto se pondrá terminar”) a menudo
produce resultados contradictorios a la intuición-
Por esto, en Kanban es habitual que hagamos un trabajo específico de hacer
explícitas las políticas que aplican a nuestros servicios para que haya un mecanismo
visible y directo para cuestionar y cambiar las políticas siempre que sean
consideradas contraproducentes o se considere que no deben aplicarse.
Por ejemplo, la limitación del ya conocido WIP (Work in Progress) es un tipo de
política. O, por ejemplo, la asignación de capacidad en cada fase del proceso, o la
nivelación de la carga de trabajo. También, la definición de “Hecho” o “Done” que
pudiera parecer innecesaria en ocasiones, y cualquier otra política que nos ayude a
controlar y mejorar las etapas de un proceso, tienen su impacto en el tablero.
Imagen 22. Revisión de políticas. Jerónimo Palacios.
Las políticas son decididas por aquellos cuyo trabajo se ve impactado por el tablero.
No hay un Scrum Master, Kanban Master o Flow Manager que decida cuáles son las
políticas, sino que estas son diseñadas a imagen y semejanza del proceso actual.
Como vimos en los principios de Kanban, “empieza con lo que tienes”, esto es, diseña
el sistema para que refleje los procesos actuales, y una vez que lo domines, entonces
empieza a mejorarlo de forma colaborativa.
Es por ello que la selección de políticas debe hacerse por aquellos que son
responsables de realizar el trabajo, pues son variadas y de muchos tipos. Puede
existir políticas por columna (quién mueve qué, cómo se deciden las prioridades de
trabajo), políticas para todo el sistema (cuando se hacen replenishment o
reposiciones, cómo se revisan los ítems) o políticas por clase de servicio, vistos estos
en el apartado 4).
9. System Thinking Approach to Introduce Kanban
(STATIK): Usar los elementos STATIK para
ayudarnos a construir un sistema Kanban.
Lo que conocemos como STATIK (Sistema Diseñado para Implantar Kanban, en
español), es una forma de entender cómo un sistema se comporta como un todo en
vez de como se comporta cada uno de sus componentes de manera aislada.
Con STATIK podemos entender el proceso por servicio que recorre una tarea
queriendo reconocer que el trabajo implica un flujo de valor que va desde la petición
de un elemento hasta su entrega al cliente; visualiza el trabajo y gestiona el proceso
de entrega del trabajo, después mejora continuamente el proceso aplicando los
principios y las prácticas ágiles.
Esta forma de trabajo es clave a la hora de definir los procesos necesarios para
introducir Kanban en una organización. Hay que tener en cuenta que los pasos no son
necesariamente secuenciales pero sí son iterativos (es decir, con ciclos que se
repiten), utilizando el aprendizaje obtenido en cada iteración para informar e influir al
resto de un entorno colaborativo.
Los pasos de STATIK son los siguientes:
1. Identificar servicios.
2.Entender qué hace el servicio adecuado al propósito del cliente.
3.Entender las fuentes de insatisfacción del sistema actual.
4.Analizar la demanda.
5.Analizar la capacidad.
6.Modelar el flujo de trabajo.
7.Descubrir clases de servicio.
8.Diseñar el sistema Kanban.
9.Socializar el sistema y el diseño del tablero y negociar la implementación.
Claramente hay organizaciones utilizando tableros que aún no emplean un sistema
Kanban que, por dar un ejemplo, limite el trabajo en progreso con señales visuales. A
esta clase de sistemas se les puede llamar “proto-kanban” porque se están agilizando
mediante Kanban aunque todavía no aplican sus prácticas generales. Los sistemas
“proto-kanban” pueden ser una parte, pero no deben ser vistos como un punto final
en el proceso de transformación.
Cuando un servicio ha sido kanbanizado por medio de STATIK, las prácticas y
cadencias de Kanban deben ser aplicadas para balancear la demanda y el flujo a
través de los múltiples servicios de la compañía.
Imagen 23. ¿Cómo diseñar un sistema Kanban? Berriprocess.
Isabel Villanueva (Accredited Kanban Coach) desarrolla los siguientes cada paso a
seguir:
1. Entender qué hace el servicio adecuado al propósito del cliente.
Debes ponerte a pensar qué hace tu servicio para considerarse que es
adecuado al propósito del cliente. Piensa en el servicio que prestas, en qué te
piden tus clientes. Es posible que tu servicio incluya un producto. Ten en
cuenta que hay servicios que entregan también productos tangibles, por
ejemplo, la entrega de pizza a domicilio, el desarrollo de software a medida al
que se le tiene que dar el servicio de soporte y mantenimiento después,
etcétera. Todos ellos se pueden gestionar con Kanban. Si se trabaja por
proyectos, hay que considerar este como un servicio que tiene una fecha de
inicio y de fin, tiene un alcance y que, al entregarlo fuera de esa fecha, habrá
consecuencias.
2. Entender las fuentes de insatisfacción internas y externas.
En segundo lugar, nos debemos centrar en conocer las fuentes de
insatisfacción tanto internas como externas desde la perspectiva de nuestro
cliente. Esto quiere decir, pensar en todos aquellos posibles problemas
mirando tanto de afuera hacia adentro, como de adentro hacia afuera. Estas
fuentes de insatisfacción serán fáciles de identificar siempre y cuando haya
transparencia y compromiso.
Piensa en qué está afectando al curso natural del trabajo que realizas, las
fricciones internas y externas que surgen en tu día a día.
3. Analizar la demanda y la capacidad.
La demanda del equipo a veces es difícil de identificar, pero con un sistema
Kanban conseguirás visualizarla y detectar la capacidad real para responder
ante esa demanda. Para ello es importante pensar qué tipos de trabajo se
están generando, saber qué nos piden y recopilar la siguiente información:
-Tipo de trabajo
-De dónde viene (fuente, canal de comunicación)
-Cliente (peticionario y destinatario).
-Tasa de llegada (cantidad de solicitudes por unidad de tiempo).
-Patrón de llegada (naturaleza de la demanda, estacionalidad, si hay).
-Tasa de salida (cantidad de trabajo terminados por unidad de tiempo).
-Expectativas del cliente (nivel de satisfacción).
Saber o entender cuál es la capacidad del sistema es algo realmente necesario
para poder gestionar adecuadamente la demanda.
4. Modelar el flujo de trabajo.
Pasamos a la parte del mapeo del flujo de trabajo, es decir, la definición por
tipos de trabajo y, a partir de ahí, el entramado de fases o etapas por los que
tiene que pasar cada tarjeta hasta la finalización del trabajo. Como hemos visto
en esta Unidad, se trata de pensar y definir las columnas y filas en el tablero
Kanban.
Recomendamos, en un principio, trabajar sobre un soporte físico con possit,
para que el equipo pueda trabajar la creatividad [véase tarea práctica de esta
unidad], fomentar el diálogo y la colaboración. Posteriormente, será muy
probable que el equipo necesite un tablero digital con el que visualizar todo el
flujo de trabajo actualizado, y analizar las métricas de forma automática. En la
Unidad 8 veremos las principales herramientas digitales para trabajar con
tableros Kanban, y obtención de métricas.
5. Definir las políticas y las clases de servicio.
Como se comentó en el apartado anterior, es necesario definir unas políticas
explícitas para que todos los integrantes del equipo sepan actuar de la misma
manera sin necesidad de consultarlo con otra persona, en definitiva, equipos
auto-organizados.
Si las políticas están explícitamente definidas en un lugar visible y conocidas
por todos, no habrá problemas causados por ambigüedades o
desconocimiento en base a las pautas de gestión del trabajo y de toma de
decisiones.
6. Diseñar el sistema Kanban y la tarjeta Kanban.
Ya sabemos lo que son las tarjetas Kanban, las cuales pueden ser diseñadas en
base a las necesidades del equipo o de un proyecto, en particular, recogiendo
la información necesaria para que todos los integrantes conozcan la naturaleza
de ese “elemento de trabajo”, y el estado de la misma para cumplir la función
principal del tablero Kanban, que no es otra que visualizar el flujo de trabajo
mediante tarjetas.
Al finalizar el apartado, te ofrecemos una ficha STATIK que te puedes
descargar mediante el siguiente link facilitado por berriprocess, y en el que se
muestra uno de los muchos ejemplos de tarjeta Kanban.
7. Reuniones de seguimiento y ponerlo en uso.
Las reuniones de seguimiento con el equipo ayudan mucho en cuanto a la
revisión del estado real del trabajo o del proyecto. La idea de usar el tablero en
las distintas reuniones de seguimiento, como por ejemplo, en la reunión diaria
(Kanban Meeting), sirve para saber qué tenemos por terminar y qué hay que
hacer hoy (antes de arrastrar una tarjeta).
Otra reunión recomendable semanalmente, que ya mencionamos en el
apartado 7, es la Reunión de Planificación (Replenishment Meeting) en la que
se selecciona trabajo para empezar en los próximos días. De esta manera
todos los integrantes del equipo tendrán priorizado el trabajo para dicha
semana.
Con tu tablero Kanban conseguirás una mayor organización y planificación del
trabajo del equipo, ahora solo queda….¡ponerlo en marcha!
Imagen 24. Ejemplo de sistema Kanban. Berriprocess.
9. Diferencias entre Scrum y Kanban.
Tabla 1. Principales diferencias entre Scrum y Kanban. Management Solutions.
SCRUM
KANBAN
Cadencia
-Sprint con una duración fija y
periódica. !
-Ambos marcos se centran en la
cadencia, aumentando la
cadencia en el caso de Scrum
(cómo enviar periódicamente
entregables de desarrollo de
software)
-Flujo de trabajo continuo, sin
plazos limitados - entrega
bajo demanda. !
-En Kanban, es una cadencia
de flujos. Cómo entregar un
mínimo de funciones
acordadas.
Metodología de entrega
-Al final de cada Sprint si lo
aprueba el propietario del
producto.
-Entrega continua o a
discreción del equipo.
Roles
-Propietario del producto, Scrum
Master, equipo de desarrollo. !
-El Scrum Master es el
responsable del proceso y de
garantizar que el equipo alcanza
satisfactoriamente los acuerdos
con plazo limitado (time-box).
- Gestor del servicio de entrega
(SMD), Gestor de la solicitud de
servicios (SRM) y el algunas
ocasiones un Agile Coach.
Principales métricas
-Rapidez (volumen de trabajo que
se pretende llevar a cabo entre
los avances alcanzados y plazos
previstos).
-Trabajo en curso. !
-Ciclo temporal.
Eventos
-Scrum diario, revisión del Sprint y
retrospectiva del Sprint.
-Reuniones Stand-up, demos
y análisis retrospectivos
diarios.
Filosofía de trabajo y
cambio
-Los equipos deben esforzarse en
no introducir cambios sobre la
previsión durante el Sprint. Si se
actúa así se compromete el
aprendizaje relacionado con la
previsión. !
-Definición de tareas y estimación
del volumen de trabajo que puede
llevarse a cabo durante un plazo
limitado para continuar realizando
avances.
-Los cambios pueden
producirse en cualquier
momento. !
-No se asignan tareas ni se
estiman plazos, el equipo
inicia las tareas y empieza a
trabajar en ellas (solo
priorizando las tareas en
cola).
10. Lecturas recomendadas.
•Pia-Maria Thoren, “Agile People: A radical Approach for HR & Managers (That Leads
to Motivated Employees), Lioncrest Publishing, 2017, 386 páginas.
•Natal Dank, Riina Hellström, “Agile HR: Deliver Value in a Changing World of Work”,
Kogan Page, 2020, 328 páginas.
•Frederic Laloux, “Reinventar las organizaciones: cómo crear organizaciones
inspiradas en el siguiente estadio de la conciencia humana”, Volumen 6 de Arpa
Innovación, Arpa, 2016, 495 páginas.
•Claus Otto Scharmer, “Teoría U”, Ed. Eleftheria SL, 2017, 415 páginas.
•Jeff Hiatt, “ADKAR: A Model for Change in Business, Government, and our
Community”, Prosci Learning Center Publications, 2006.
10. Bibliografía y Webgrafía.
•Kanban University, “La Guía oficial del método Kanban”, Mauvius Group, 2021, 15
páginas [https://kanban.university/wp-content/uploads/2021/11/The-Official-Kanban-
Guide_Spanish_A4.pdf]
•David J. Anderson, Andy Carmichael, “Essential Kanban Condensed”, Vol. 2 de
Essential Kanban, Lean Kanban University, 2015, 102 páginas [https://
www.tigalia.com/wp-content/uploads/2020/12/Essential-Kanban-Condensed-
Spanish.pdf]
•Management Solutions, “De proyectos Agile, a organizaciones Agile”, 2019, 44
páginas [https://www.managementsolutions.com/sites/default/files/publicaciones/
esp/organizaciones-agile.pdf]
•Henrik Kniberg & Mattias Skarin, “Kanban y Scrum - obteniendo lo mejor de ambos”,
C4Media, 2010, 123 páginas [http://www.proyectalis.com/documentos/
KanbanVsScrum_Castellano_FINAL-printed.pdf]
•Kanban Tool. Guía Kanban. Kanbantool [https://kanbantool.com/es/guia-kanban/
historia-de-kanban]
•Universidad de Salamanca (18 de marzo de 2020). Kanbanizate [https://
viewnext.usal.es/blog/kanbanizate]
•Patricia Parreira (8 de octubre de 2020). Cómo las métricas Kanban te ayudan a
optimizar tus procesos. Agilidad Empresarial [https://netmind.net/es/metricas-
kanban-que-son/]
•Kanbanize (2023). Getting Started with Kanban. [https://kanbanize.com/kanban-
resources/getting-started]
•Scrum México (31 de enero de 2019). ¿Qué es STATIK y cómo utilizarlo? [https://
scrum.mx/informate/kanban-y-statik]
•Iker Landajuela (2022). Origen de los sistemas Kanban en Toyota. [https://
soka.gitlab.io/blog/post/2019-07-02-01-trello-origen-kanban-toyota-jit/]
•David Coloma (5 de mayo de 2020). Priorizar en Kanban con clases de servicio
basadas en el Cost of Delay. Innove Business Agility Experts. [https://itnove.com/
blog/kanban/equipos/kanban-cost-of-delay/]
•Berriprocess Agility (2023). Analíticas Kanban. Lead Time. [https://berriprocess.com/
analiticas-kanban-lead-time/]
•Berriprocess Agility (2023). ¿Cómo diseñar un sistema Kanban? STATIK. [https://
berriprocess.com/como-disenar-un-sistema-kanban-statik/]