En esta presentación se describe el proceso de implantación de la metodología Kanban y la puesta en marcha de los artefactos necesarios. Ha sido utilizado como ejemplo de base una Start-Up española denominada ioPlanto.

1. Simone Brighina
2014

2. ioPlanto es una Startup española: una herramienta online
para el cuidado de plantas que incluye desde el seguimiento
del riego hasta una faceta más social definida como
“El Linkedin de las plantas”.
Simone Brighina
Con el fin de mejorar la organización del trabajo, la
gestión del equipo de forma remota, mantener un flujo
de trabajo constante y maximizado, se requiere la
introducción de la metodología Kanban.

3.  Luis: Programador de la Plataforma.
Lleva unos meses en el equipo pero ya conoce el proyecto y el código a
la perfección.
 Clara: Experiencia de Usuario.
Lleva igual que Luis en equipo. Clara prepara a Luis las interacciones y
los diseños, revisa todo el trabajo de Luis. Trabajan mano a mano.
 Carlos: Diseño y Funcionalidad.
Carlos hace de enlace entre la parte de negocio y la parte de
producción. No trabaja con Clara y Luis al 100% pero si supervisa el
trabajo, lo valida y ordena las prioridades.
 Mario: Analítica y Redes Sociales.
No trabaja con el equipo de desarrollo pero si revisa aquellos
elementos que tienen o pueden tener impacto en su campo. Además
pide cambios puntuales para la mejora de sus datos al equipo de
desarrollo.
Simone Brighina

4.  En este momento el equipo de desarrollo está centrado en:
 Tareas de Mantenimiento
 Tareas de Renovación de la zona de gestión interna de la plataforma
 Tareas de realización de Nuevas Funcionalidades para los usuarios de
ioPlanto.
 Con la introducción de la metodología Kanban será necesario que una persona
se encargue de velar su implantación, en lo especifico habrá que asegurar la
aplicación de:
 Utilización Tarjetas Kanban completas con toda la información requerida
 Utilización Tablero Kanban y ventajas visuales asociadas
 Puesta en marcha de las Reuniones necesarias
Simone Brighina

5.  Kanban no define unos roles específicos, pero su introducción implica
la necesidad de que alguien se encargue de implantar los cambios
necesarios para completar la transición hacia la nueva metodología.
 Este rol puede ser asumido por:
 La persona precedentemente encargada de gestionar el proyecto.
 Podrá ser creada una nueva figura dedicada.
 Podrá ser delegada esta tarea a un miembro del equipo
preexistente (no aconsejado por problemas de gestión del tiempo
y posible generación de conflictos).
Cada equipo podrá elegir la solución que mejor se adapte en base a la
organización preexistente y la disponibilidad de personal.
Simone Brighina

6. Nombre Proyecto
Titulo tarea: Código tarea:
Descripción Tarea: Lead Time
Indicador de
Bloqueo:
Dependencia con otras tareas: Indicador
retraso:
Fecha entrada: Fecha Limite:
Opcional: depende de la tarea
Avatar:
Simone Brighina
Cada tarea se registrará en una tarjeta Kanban que se posicionará en el tablero
Kanban con el fin de permitir un seguimiento visual de la diferentes fases de
desarrollo y así alcanzar una mas eficiente gestión de la productividad del equipo.

7. ioPlanto
Titulo tarea: Añadir Tag en las fotos Código tarea: TAG001
Descripción Tarea:
Como usuario debo poder asignar TAGs en las fotos, elegirlos
de un listado predeterminados, añadir manualmente nuevos
TAGs si necesario.
Categorías de TAGs básicas: Nombre plantas, Nombre semillas,
Tipo de tierra, Tipo de cultivo, Tipo de maceta.
Lead Time: 5 dias
Indicador de
Bloqueo:
Dependencia con otras tareas:
IMG001: Cargar imágenes
IMG002: Asignar imágenes a la cuenta
IMG003: Visualizar imágenes
Indicador
retraso:
Fecha entrada: 08.12.2014 Fecha Limite: 12.12.2014 Avatar:
Simone Brighina

8.  Lead Time: tiempo transcurrido desde que una tarea llega a nosotros hasta sea entregada
al cliente.
 Cycle Time: tiempo que transcurre desde que empezamos a trabajar en una tarea, hasta
que sea finalizada (no aparece en la tarjeta pero sirve para poder definir correctamente el Lead
Time)
 Indicador de Bloqueo: se añadirá un Post-it de color rojo en caso que una tarea quede
bloqueada por problemas que el singlo miembro del equipo no consiga resolver. Puede que
necesite ayuda para llevar a cabo su trabajo tanto como necesite la intervención de otros
interlocutores con conocimientos diferentes.
En casos de bloqueos prolongados será necesario discutirlos en una reunión dedicada.
También es posible elegir añadir una tabla adicional para el estudio de los bloqueos y duplicar
allí la tarjetas con el fin de mejorar la resolución de los problemas que bloquean el trabajo en las
fases iniciales de implantación.
 Indicador de retraso: se añadirá un Post-it de color naranja en caso que una tarea tenga
que retrasarse respecto al plan de acción previsto
 WIP = Work In Progress: definido el la siguiente diapositiva
Simone Brighina

9. Indica el numero máximo de tarjetas admitidas por cada columna
 Es esencial poder establecer el WIP especifico por cada columna y configurado en base al
tipo de proyecto y al equipo que utilizará el tablero.
 La idea se basa en evitar desperdicios de tiempo y esfuerzo (concentración, cambio de
herramientas, trabajo dejado a medias, etc…) debidos al cambio de una tarea a otra.
 El WIP ideal para la máxima productividad sería 1, pero hay que tener en cuenta que pueden
provocarse bloqueos que necesiten la intervención de ayuda externa: en este caso, para no
parar el flujo de trabajo, habrá que poder acceder a otra tarjeta mientras se espera la ayuda
necesaria para eliminar el bloqueo.
 Se aconseja empezar con un WIP = 2 y con el tiempo llegar al WIP adaptado específicamente
por cada columna, siempre teniendo presente que un WIP mas bajo aumenta la
productividad.
 En caso de problemas estructurales y bloqueos recurrentes, en lugar de utilizar un WIP
elevado se aconseja añadir la columna Buffer: esto permite insertar tarjetas con un
prioridad secundaria a la de la columna principal que se utilizarán en casos extremos
cuando el limite del WIP sea alcanzado.
 IMPORTANTE: en caso de utilización excesiva de la columna Buffer será necesario abrir
un proceso de análisis exhaustivo de la organización para revisar los roles, los WIP y
los DOD definidos. Simone Brighina

10. Tablero Kanban ioPlanto
Tareas Análisis Diseño Buffer Desarrollo Verificación Finalizado
En
proceso
Terminado En
proceso
Terminado En
proceso
Terminado En
proceso
Terminado
WIP: WIP: WIP: WIP: WIP: WIP: WIP: WIP: WIP: WIP: WIP:
DOD: DOD: DOD: DOD:
NOTA: para favorecer el acceso al tablero en el caso de que un miembro del equipo pueda no
estar presente físicamente se aconseja replicar el tablero de forma virtual utilizando una
herramienta online que permita su acceso desde diferentes sitios. Un ejemplo gratuito y
completamente configurable puede ser http://leankit.com/.
Simone Brighina
Las tarjetas siguen el Flujo de izquierda a derecha, nunca vuelven hacia atrás

11. Simone Brighina
La tarjetas Kanban permiten una rápida visualización de los bloqueos gracias a los indicadores de
bloqueos (en rojo) que se añaden a cada tarjeta en caso de que no se pueda seguir adelante con el
trabajo.
Sobre todo en una primera fase de implantación, cuando la metodología necesita todavía arrancar y
encontrar su encaje en la organización preexistente, podría surgir un elevado número de bloqueos y
la consecuente necesidad de un estudio profundizado de su importancia e interrelación.
Para una mejor visualización, y también una posible priorización de los bloqueos a resolver, he
dejado abierta la posibilidad de añadir un tablero adicional dedicado a la gestión de los bloqueos
en una reunión especifica.
Esto permitiría poder replicar/duplicar las tarjetas bloqueadas (nuca hay que interrumpir el flujo de
izquierda a derecha en el tablero), poniéndolas en orden de prioridad basada en el peso de los
bloqueos y en la interrelación entre ellos.
De este modo se obtendrá un mejor efecto visual de todos los bloqueos agrupados con el fin de
estudiar la priorización necesaria para maximizar la eficiencia durante el proceso de resolución de los
bloqueos.
Una vez actualizados los elementos organizativos que puedan generar un numero elevado
de bloqueos se podría eliminar esta tabla adicional y seguir utilizando solamente los
indicadores de cada tarjeta dentro del tablero Kanban estándar.

12. Simone Brighina

13. Aunque la metodología Kanban no requiere obligatoriamente la implantación de
reuniones especificas, aconsejamos como mínimo la utilización de estas tres reuniones
con el fin de mejorar el alcance del proyecto y la aplicación de la metodología:
 Reunión Diaria: El objetivo será revisar el flujo de trabajo con el fin de eliminar
bloqueos estructurales y/o comparar conocimientos para resolver bloqueos puntuales.
Si necesario se pueden establecer pequeñas reuniones técnicas puntuales finalizadas a la
resolución de bloqueos o dudas técnicas que necesiten un análisis conjunto.
 Replenishment (o rellenado): debido a que el flujo de trabajo y, consecuentemente
de tarjetas en el tablero, tiene que ser continuo y basado en un sistema Pull, será
necesario alimentar el tablero con nuevas tarjetas que se pondrán en la cola de espera
de la columna “Tareas”.
En esta reunión se analizarán los nuevos requerimientos, se convertirán en tarjetas y se
decidirá su priorización de modo de poder rellenar la cola en base al WIP de la columna
“Tareas”.
Simone Brighina

14.  Retrospectiva: estas reuniones son un elemento necesario para permitir el proceso
de mejora continua durante la implantación y sucesiva evolución de la metodología
Kanban utilizada. El objetivo es parar la maquinaria de trabajo y hacer que todos
puedan aportar sus pensamientos y sus ideas de mejora. Para conseguir este objetivo
se utilizan 3 preguntas guiadas:
• ¿Qué estamos haciendo bien?
• ¿Qué estamos haciendo mal?
• ¿Cómo podemos mejorar?
Las respuestas a estas preguntas permitirán clarificar soluciones de mejoras y
traducirlas en planes de acción para que puedan ponerse en practica desde el día
siguiente a la misma reunión.
El equipo decidirá la cadencia de la Retrospectiva, pero se aconseja como mínimo una
reunión cada mes (en primeras fase de implantación también cada 2 semanas)
Simone Brighina

15. Simone Brighina
es.linkedin.com/in/simonebrighina/
Esta presentación es fruto de una interpretación personal de la metodología Kanban que se
encuentra todavía en fase de evolución constante. Cada uno es libre de decidir aplicar la
metodología utilizando herramientas, roles, artefactos diferentes con el fin de adaptarla a
cada situación, equipo o caso concreto. Igualmente espero pueda resultar útil para la
difusión practica de la metodología o simplemente para su conocimiento a nivel teórico.
Para profundizar el tema es posible acceder al articulo relacionado:
Quiero ser Ágil: ¿mejor Scrum o Kanban?