Aplicación de Kanban en una startup española dedicada a la construcción, desarrollo y mantenimiento de una herramienta web para el cuidado de plantas.

1. ioPlanto II
Implantación
de Kanban
Kanban 2: Equipos y proyectos. Gestión
evolutiva del cambio
Javier Boó Gustems

2. Comentarios del equipo (I)
 Luis (desarrollador)
 “Estoy muy contento con Kanban aunque tengo la
sensación de que todavía no le sacamos el partido
que podríamos. A veces nos cuesta decidir sobre
qué tareas tenemos que sacar adelante y al no
contar con todo el equipo en la oficina el 100% del
tiempo a veces me bloqueo por no saber por
donde avanzar.”
 Clara (experiencia de usuario)
 “El trabajo con Luis se ha vuelto más fluido y
tenemos una sensación de control mayor.
Estamos desarrollando más y mejor. Sin embargo
creo que la corrección de errores en la plataforma
nos dificulta la gestión de las tareas. Tenemos que
avanzar a la vez con nuevos desarrollos y con
corrección de errores que a veces son prioritarios
y otras no. No siempre es fácil conjugar esto y
seguir avanzando a buen ritmo.”

3. Comentarios del equipo (II)
 Miguel Plantado (Departamento comercial)
 “Estoy viendo como Kanban ha ayudado al equipo
de desarrollo pero me sigue preocupando la
coordinación de las tareas. Sé que es fundamental
la corrección de errores y seguir avanzando con
las funcionalidades pero para mí es crítico que las
acciones y patrocinios que vendemos (banners y
secciones de contenido patrocinado) aunque
normalmente sean sencillos de implementar estén
desarrollados en el plazo que nos piden los
clientes.”
 Mario Redes (Analítica y redes sociales)
 No he terminado de encontrar mi sitio, mi trabajo
transcurre de manera paralela al equipo y no he
terminado de sentirme cómodo en los flujos que
se han planteado. Me gusta el tablero y lo veo útil,
sólo creo que falta un poco de especificidad para
mi puesto.

4. Clasificación de inputs
Nuevos desarrollos
Corrección de errores
Críticos
No críticos
Acciones y patrocinios
comerciales
Con fecha límite
Sin fecha límite
Gestión de redes sociales

5. Clases de servicio
 Expedite para Acciones y patrocinios
comerciales (Con fecha límite).
 Visualización: Tarjetas rojas, con una fila
propia.
 Límites: Un único elemento de esta clase en
el tablero. Además elimina otros límites de
WIP que puedan existir temporalmente. Si la
tarjeta ha finalizado una fase alguien de la
fase siguiente comenzará con ella aunque
tenga que sobrepasar el límite de WIP
temporalmente.
 Priorización: Prioriza la primera siempre y se
saltan los buffers que podamos tener
definidos.

6. Clases de servicio
 Fecha cerrada para Corrección de errores
(Críticos).
 Visualización: Tarjetas naranjas, fecha de
entrega límite explícita sobre la tarjeta.
Límites: Utilizan los límites verticales
establecidos, no se permite que sobrepasen
los límites del tablero.
 Priorización: Priorizan por encima de las
estándar si su plazo de entrega es cercano
o menor al Lead Time medio de nuestro
tablero.
 Otras: Si su fecha de entrega se encuentra
a menos de 5 días laborables se convierte
en un Expedite. Cambiaremos la tarjeta por
una roja con la misma información y
entrarán en juego las políticas de esta clase
de servicio.

7. Clases de servicio
 Estándar para Nuevos desarrollos, Acciones
y patrocinios comerciales (Sin fecha límite) y
Corrección de errores (No críticos).
 Visualización: Tarjetas amarillas.
 Límites: Utilizan los límites verticales
establecidos.
 Priorización: Utilizamos una planificación
FIFO.
 Tablero independiente para Gestión de
redes sociales