Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
Tablero Kanban

Tiempo medio de lectura: 15 minutos.

Este artículo trata sobre cómo gestionar un sistema Kanban suponiendo que ya habéis hecho los pasos previos:

  • Habéis formado al equipo en Kanban.
  • Habéis diseñado el tablero y las tarjetas.
  • Habéis establecido las cadencias.
  • Habéis explicitado las políticas iniciales.

Contenidos

Gestionar con Kanban lleva unos pasos:
  1. Crear y mantener los ítems que forman el backlog.
  2. Priorizar los ítems.
  3. Gestionar el flujo de valor en el sistema.
  4. Mejorar el sistema.

Ahora vamos a ver cada uno de ellos.

 

Gestionando con Kanban el backlog

Una vez definido el sistema Kanban tendremos que constituir el backlog. Para ello debemos:

  1. Listar los ítems adecuados.
  2. Registrar la información relevante.
  3. Situar los ítems en el tablero.

Listar los ítems adecuados en el backlog

La primera cuestión para gestionar con Kanban es listar los ítems adecuados.

¿Qué criterios debemos tener en cuenta?

Debemos tener en cuenta dos criterios: la naturaleza del trabajo a realizar y su tamaño.

Respecto a la naturaleza del trabajo debemos registrar los ítems que que nos han solicitado los clientes o stakeholders (servicios, peticiones, entregables o partes de entregables) y que no hemos entregado. Estos ítems nos los pueden haber pedido explícitamente o implícitamente -por ejemplo los que se derivan necesariamente de los que nos han pedido.

Debemos enfocarnos en listar los entregables que nos han solicitado e intentar no reflejar las tareas que realizamos. Para ello debemos considerar qué implica enfocarnos a servicios y qué implica hacerlo a tareas.

Un servicio cualquiera puede prestarse de formas diferentes, utilizando actividades diferentes o realizadas de forma diferente.

Una compañía puede ejecutar una tarea manualmente, otra utilizar una ligera automatización, otra una automatización total pero simple, otra total y compleja, y otra puede no realizar siquiera esa tarea.

Algunas tareas pueden ser un requisito interno de las políticas e idiosincrasia organizativa.

Otras tareas se derivan necesariamente de la tecnología utilizada: diferente tecnología, diferentes tareas.

Otras tareas se derivan de la proposición de valor que ofrecemos. A diferente proposición de valor, diferentes tareas.

También hay tareas legacy. En un momento tuvieron sentido (o no), pero se siguen haciendo por reproducción cultural. Es decir, por tradición y porque se ha enseñado a hacerlas así, sin que sean cuestionadas.

Si nos enfocamos en las tareas estaremos adoptando un foco interno y nos olvidaremos del foco externo: el cliente y el valor para él.

Así, seguramente no registraremos en el backlog las reuniones de equipo u organizativas, tiempo dedicado a tareas de gestión, etc.

Respecto al tamaño, si existen peticiones muy pequeñas, que se pueden resolver muy rápidamente, tendrá sentido no registrarlas. No tiene sentido utilizar dos minutos en crear una tarjeta y moverla si, a lo mejor, tardo cinco en ejecutarla. Estas microtareas pueden considerarse directamente como una capacidad disponible menor.


Registrar la información apropiada

Una vez que hemos listado los ítems que tenemos pendientes de entregar, el siguiente paso para gestionar en Kanban es registrar la información que nos servirá para tomar decisiones y gestionar la entrega de los ítems.

Se deberán registrar los datos que nos sean relevantes sobre los ítems del backlog. Aparte de la información evidente (descripción, código, tipo de ítem,…) hay datos que posiblemente debemos considerar como:

  • ¿Requiere alguna habilidad especializada?
  • ¿Tiene una fecha límite determinada?
  • ¿Cuál es su valor o urgencia?
  • ¿Hay algún riesgo a tener en cuenta?
  • ¿Existe algún requisito especial sobre esta petición?
  • ¿Pertenece a alguna clase de servicio?
  • ¿Pertenece a algún cliente o categoría de cliente?
  • ¿Está afectado por algún problema relevante?
  • Etc, etc.

Como crear un tablero Kanban


Situar los ítems en el tablero

Cuando ya tenemos los ítems y su información registrados para gestionar en Kanban debemos ubicarlos en la parte del tablero que corresponda:

  • Backlog: ítems pendientes de hacer.
  • Next: ítems pendientes de hacer pero seleccionado para realizar próximamente.
  • Doing: ítems en ejecución, y dentro de esta parte, se pondrían en la fase pertinente si se representa el workflow.
  • Completados: ítems finalizados.

Cuando ya tenemos los ítems registrados y puestos en el tablero, nos dedicaremos a:

  1. Gestionar la ejecución de los ítems en curso.
  2. Priorizar los próximos ítems a entregar.


Gestionar con Kanban el día a día: Asegurar el flujo de ítems

Durante el día a día el equipo trabaja para entregar los ítems, colaborando y coordinándose para resolver los obstáculos y problemas que puedan surgir.


Daily Kanban

El Daily Kanban es una reunión corta diaria para gestionar en Kanban -generalmente 15 minutos o menos- en la que el equipo revisa el tablero, identifica impedimentos para el avance de los ítems (esto es, obstáculos al flujo) y colabora para resolverlos.

A diferencia de lo que es la práctica en Scrum, no es necesario explicar lo que se hizo ayer (se ve en el tablero). Tampoco es necesario detallar lo que se hará hoy porque en muchas ocasiones será el mismo ítem de ayer o se deducirá fácilmente a partir de las tarjetas del tablero y las clases de servicio. Ni indicar qué obstáculos hay porque estarán señalizados en el tablero.

Para mantener las reuniones breves se utilizan diversas técnicas de las que destacamos tres:

  • Establecer mecanismos que aseguren que se mantiene el time-box.
  • Examinar de derecha a izquierda del tablero.
  • Realizar after-meetings.

La primera es aplicar instrumentos que aseguren que se respeta el time-box, o sea, la duración máxima decidida. Una es establecer un moderador que corte o haga volver al redil a los que divaguen. Otra es establecer un mecanismo de limitación de los participantes (p. ej. Un temporizador al que se debe ceñir cada participante). Un tercero es cortar la reunión cuando se llega a la duración máxima.

Para asegurarse que se hayan facilitado el flujo al máximo se empiezan a tratar los ítems bloqueados o problemáticos y luego los otros. Y se hace de derecha a izquierda del tablero, o sea, empezando por los más cercanos a ser completados e ir retrocediendo hacia los más lejanos.

Dado que en un sistema de flujo los bloqueos y los cuellos de botella transmiten sus problemas proceso arriba, ir de izquierda a derecha facilita centrarse en desbloquear los problemas al flujo.

Finalmente, en esas reuniones cortas se deben analizar las causas ni las soluciones de los problemas a riesgo de extenderse. Por ello es habitual a la hora de gestionar en Kanban que los implicados hagan de forma voluntaria una reunión informal una vez acabada la reunión diaria -llamadas after-meetings– para examinar posibles soluciones.

En la reunión diaria también pueden surgir oportunidades de colaboración para el equipo.

 

Colaboración y resolución de obstáculos e incidencias

Existen diversos obstáculos típicos al flujo. Uno es que un miembro esté colapsado por un ítem que exige mucha dedicación. Otra es que porque el ítem supone un problema con el que no está familiarizado y para el que le cuesta encontrar la solución.

En estas situaciones existen oportunidades para que varios miembros echen una mano, práctica que se llama swarming.

Con esta colaboración se ayuda al compañero bloqueado ya sea trabajando con él, descargándolo de otro trabajo o ayudándole o enseñándole a resolver el problema.

Otros obstáculos no exigirán la colaboración dado que pueden realizarse individualmente. Serán perseguir a quien deba suministrar información, aprobaciones, servicios externos, etcétera, etcétera.

Las reuniones diarias permiten identificar más rápidamente y atacar los problemas en el flujo de nuestro sistema y la colaboración añadir rápidamente capacidad en los obstáculos que lo impiden.

 

La Definition of Done (o DoD)

Igual que hay que evitar que entren ítems inmaduros en nuestro sistema, hay que evitar entregar ítems que no sean conformes con las necesidades de los clientes. Esos ítems acabarán volviendo y deberemos dedicar tiempo a corregirlos.

Las malas noticias son que si consideramos el tiempo dedicado a corregir el defecto, generalmente costará mucho, mucho más tiempo y dinero que el que hubiera llevado hacer bien el ítem o haberlo corregido antes de entregarlo.

Nuestro sistema no sólo deberá atender la demanda de los clientes sino también lo que es la “demanda por fallos”, el trabajo exigido por los fallos, por no haber hecho bien las cosas a la primera.

Para evitar que se entreguen ítems que nos provoquen esa demanda por fallos es conveniente definir qué criterios debe cumplir un ítem para considerarse ”completado”. Aquí estarán los tests de calidad, y toda la lista de criterios y entregables complementarios que deben acompañar al ítem.

 

Gestionar con Kanban la priorización del trabajo

Otra cuestión a realizar cuando se gestiona en Kanban será gestionar la entrada de nuevos ítems en nuestro sistema. En otras palabras, comprometer los ítems que queremos entregar próximamente.

 

Reunión de reposición (Replenishment Meetings)

Las reuniones de reposición son otra cadencia fundamental dentro de la gestión en Kanban. Aquí se analizan los ítems en el backlog y se seleccionan aquellos que deben realizarse a continuación para maximizar el valor entregado.

Son reuniones en las que estará presente el equipo, incluyendo al Replenishment Manager si lo hay, o quien realice sus funciones. Pueden asistir también los clientes o stakeholders.

Estas reuniones se pueden hacer periódicamente (p. Ej. Semanalmente, diariamente, quincenalmente,…), según el ritmo que sea adecuado o bien se pueden hacer disparados por un evento (cuando haya menos de, digamos, 7 tarjetas en la columna “Next”).

El número de los ítems seleccionados dependerá de la política que se establezca en la organización, pero generalmente estará relacionado con el throughput -es decir con el número de ítems completados- en el período en el que se realice.

La duración de estas reuniones de reposición depende principalmente de la duración del periodo para el que se vaya a rellenar la cola de peticiones, la complejidad de dicha reposición y la madurez del equipo. No obstante, una vez se tiene un mínimo de práctica, acostumbran a ser bastante cortas.

 

Factores a la hora de priorizar y reponer

En la reunión de reposición se consideran factores relativos al valor de los ítems, el riesgo que suponen y la premura para decidir los que deben preceder en la entrega.

 

Las clases de servicio

Una primera cuestión es la clasificación de los ítems en clases de servicio. Las clases de servicio son políticas que, en primer lugar, categorizan los ítems según niveles de prioridad. Y, en segundo lugar, definen como secuenciar esos ítems por el sistema según esa prioridad o, dicho de otra manera, en qué orden y qué nivel de recursos deben recibir para ser procesados de forma que se maximice el valor creado.

Habrá así ítems que requieren una acción inmediata porque son de una importancia existencial para la organización y retrasarse puede llevar a la empresa a consecuencias nefastas. Otros tienen un impacto elevado pero no ponen en riesgo la supervivencia. Otros tienen un impacto molesto pero asumible. Y así sucesivamente.

Por poner un ejemplo, una amenaza para la continuidad de negocio -como un ciberataque que esté teniendo éxito- seguramente llevará a que se paralicen actividades no críticas para la supervivencia a corto plazo y se pasen los empleados. En otras palabras, pasa a ser tratado prioritariamente e, incluso, a consumir recursos que estaban asignados a otros ítems como, por ejemplo, la puesta en marcha de un nuevo sistema de reporting o la integración de los sistemas de una empresa acabada de adquirir.

Y ahora llega la cuestión: ¿qué criterios deberían utilizarse para definir esas clases de servicio para la priorización?

 

El coste del retraso (Cost of Delay)

Para priorizar tenemos que ver cuál es el retorno de la inversión del tiempo invertido en los ítems . Debemos ordenarlos de forma que proporcionen el máximo valor en el mínimo tiempo dedicado a ejecutarlos.

Vamos a desglosar este concepto en sus dos componentes.

El primer componente, el valor, debe ser definido correctamente. Los ítems son perecederos. Raramente conservarán el mismo valor en diferentes momentos del tiempo.

Por esto debemos considerar no el valor absoluto y fijo en un momento dado sino su variación en el tiempo. Expresado más claramente, debemos evaluar cuánto valor pierden con el paso del tiempo. Esto es, el coste del retraso, o sea, cuánto “cuesta” entregarlo más tarde, como se deteriora su valor por demorar su entrega.

El segundo componente es el tiempo de entrega, el tiempo que se tardará en finalizar el ítem. Menos tiempo en entregarse significará menos pérdida de valor. Si se limita el WIP a 1, la dedicación del sistema al ítem (que es el recurso disponible) y el tiempo que se tarde en entregarse (que es sobre el que se deteriora el valor) serán equivalentes. Es decir, menos tiempo en entregarse .

Cuando tenemos claros los cos conceptos, podemos establecer trade-offs entre valor perdido y tiempo de entrega para tomar las decisiones que reduzcan la pérdida de valor en el tiempo.

Si quieres ver cómo utilizar el coste del retraso para definir prioridades, puedes ver el artículo “Las clases de servicio y el coste del retraso”.


El triaje de los ítems

En lugar de poner los nuevos ítems en la cola para que sean procesados después de los precedentes, se estudian brevemente para ver si sus características recomiendan que sean priorizados y pasen por delante de los ítems anteriores.

Esto supone ver las peticiones como si fueran los pacientes que llegan a un servicio de Urgencias de un hospital:

  • Las peticiones (demanda) son superiores a la oferta.
  • Algunas peticiones pueden esperar menos que otras.

En Urgencias lo primero que hacen es examinar si la situación del paciente es grave. En función de su situación relativa a la de los otros pacientes, se lo atenderá inmediatamente o se lo hará esperar más o menos.

La priorización supone lo mismo.


Los criterios de aceptación de los ítems

Si seleccionamos un ítem para trabajar en él y no está claramente definido o esta definición no está acordada con el cliente, existe un alto riesgo de que se eche para atrás. En este caso el sistema tendrá que dedicarle tiempo adicional, que no se podrá dedicar a otros ítems.

Si seleccionamos un ítem y no están resueltas sus dependencias, probablemente se quedará bloqueado, afectando el tiempo de entrega y exigiendo dedicación para conseguir su desbloqueo.

Por estas razones es necesario que los ítems que se comprometan cumplan unos requisitos para ser aceptados como, entre otros:

  • Definición clara.
  • Definición acordada con el cliente.
  • Dependencias resueltas (dentro de lo razonable).

Estos criterios de aceptación se llaman “Definition of Ready” (o DoR), y establecen un filtro para evitar que se introduzcan en el sistema ítems inmaduros, que no estén listos para ser ejecutados con el mínimo de problemas.


Descarte de los ítems

Una de las características de cualquier sistema que presta servicios que sobreviva a largo plazo es que tiende a tener más demanda de peticiones que capacidad. Esto llevaría a que la cola de ítems esperando en el backlog crezca hasta el infinito.

Dentro de las solicitudes existen peticiones de diferente importancia. Algunas son muy importantes y otras son nimias. Otras se han vuelto obsoletas y han perdido su sentido con la espera. Puede haber desaparecido su ventana de oportunidad, cambiado la tecnología, la necesidad o el cliente que las habían pedido.

Por esto es importante tener un proceso periódico para eliminar ítems que lleven un tiempo excesivo en el backlog porque esto es indicador de que su valor no justificaba su resolución por el sistema.

Pero esto, ¿no puede crear un problema?

Esto no nos debe preocupar. Si siguen siendo ítems importantes, el cliente nos los volverá a pedir y volveremos a ponerlos. Si no, se habrá hecho bien en dejar espacio para otros ítems.


Gestionar con Kanban la mejora del sistema

Kanban ayuda a gestionar nuestro sistema pero la gracia está en mejorarlo continuamente.

Para ello existen diversas herramientas que vamos a ver a continuación:

  • Service Delivery Review.
  • Técnicas de retrospectiva.
  • Identificación de los problemas de flujo.

Revisión de entrega de servicio (Service Delivery Review)

La Service Delivery Review es la reunión periódica de gestión en Kanban que tiene como objetivo mejorar la prestación de servicios.

Se revisan los problemas que hacen que los servicios no cumplan las expectativas y los criterios que los convierten en aptos para el propósito. Se analizan las causas raiz de estos problemas y se conciben soluciones.

Dentro de estas reuniones se aplican técnicas de dinamización como liberating structures, etc.


Técnicas de retrospectiva

Dentro de la Revisión de entrega del servicio se pueden utilizar la agenda típica de las retrospectivas así como muchas técnicas de análisis de problemas y de causas tales como las Katas o la técnica A3. También se siguen modelos rápidos de generación de ideas de mejora como el starfish, técnicas de voto para obtener un consenso rápido (dot voting, thumb voting,…).


Identificar las causas de los problemas de flujo

Idear soluciones duraderas a los problemas de flujo requiere identificar correctamente sus causas. Si no, se reproducirán recurrentemente porque se habrán atacado los síntomas o una causa intermedia y no la causa profunda del problema.

Por esto es conveniente considerar si están presentes en nuestros problemas las causas típicas de los problemas de flujo como:

  • Lotes grandes.
  • Un nivel alto de trabajo en curso, que causa sobrecarga del sistema, colas ante los recursos y hace perder productividad por el cambio de contexto.
  • Cuellos de botella.
  • Dependencias, como la necesidad de recurrir a aprobaciones, información o servicios por parte de áreas externas al sistema.
  • Bloqueos diversos.
  • Defectos o ítems que deben ser retrabajados (p. Ej. Por no haberse entendido o comunicado correctamente).
  • Personal muy especializado que no puede ser asignado a fases diferentes.
  • Falta de autonomía en la gestión, donde un número elevado de decisiones deben ser tomadas fuera del equipo.
  • Procesos demasiado fragmentados entre áreas de la organización, que obligan a muchas transferencias de trabajo y coordinación.
  • Prestaciones no solicitadas.

Acciones de mejora

Las revisiones de entrega del servicio deben finalizar con la decisión de acciones de mejora a desplegar.

Vamos a ver los pasos a realizar:

  1. Establecer una lista de acciones de mejora que ataquen el problema o los problemas seleccionados.
  2. Estimar el impacto de las acciones y la dedicación o tiempo necesario para la puesta en marcha.
  3. Priorizar las acciones de mejora por impacto y por dedicación y duración de la implementación.
  4. Seleccionar una (o unas pocas acciones) que ofrezcan el máximo retorno del tiempo invertido.

Hay que recordar que no se trata de buscar la solución ideal, que puede exigir una inversión elevadísima de tiempo. Debemos buscar una solución efectiva, que evite la repetición recurrente pero que requiera poco tiempo para ejecutarse. Un ejemplo de esto es lo que en las liberating structures se llama ’20% solution’, una solución que te reduce el problema en un 20% pero que es muy fácil y rápida de implementar.

Las acciones de mejora deben registrarse y mantenerse en un backlog de mejoras. Y es recomendable que en cada reunión de reposición se comprometa al menos un ítem de mejora para ejecutarlo próximamente.

 

¿Quieres saber más?

Puedes profundizar en Kanban con nuestro curso de Kanban.

¡Si has llegado hasta aquí, comparte este artículo!

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.

Abrir chat