Kanban Training for Operations Team in Schibsted Classified Media Spain

2. Kanban en Sistemas

3. ¿QUÉ ES KANBAN?
• Kanban es una herramienta que permite visualizar el trabajo y optimizarlo.
• Está basado en la filosofía del Just in time.
• Y en los conceptos de mejora continua
•
ricos en el sentido de que se espera que experimentes con el
proceso y lo adaptes a tu entorno. Se tiene que experimentar. Este
sistema no proporciona todas las respuestas – simplemente nos
proporcionan una serie de reglas y limitaciones a la hora de guiar la
mejora de nuestros procesos.
• Parte de la base de que el equipo es autoprganizado.

4. ¿QUÉ ES KANBAN?
• Visualizar el flujo de trabajo:
• Dividir el trabajo en tareas, escribir cada uno de los elementos en una
tarjeta y poner en el tablero.
• Usar el nombre o columnas para ilustrar en que estado se encuentra
cada elemento dentro del flujo de trabajo.
• Limitar WIP (Work In Progress):
• Asignar límites explícitos sobre cuantos elementos pueden estar en
cada uno de los estados del flujo de trabajo.
• Medir el tiempo (en entornos muy maduros o industrializados):
• Contar el tiempo promedio para completar una tarea “lead time”, como
es obvio, optimizar el proceso para que el tiempo tan pequeño y
previsible como sea posible.
• Reducimos variabilidad y damos previsionalidad a nuestro trabajo.

5. ¿QUÉ PRETENDEMOS RESOLVER?
El principal cliente de un equipo de sistemas son los desarrolladores. Pero…
Nos encontramos con falta de comunicación, falta de empatía,….

6. ¿QUÉ PRETENDEMOS RESOLVER?
¿Cómo nos ven los desarrolladores?
¿Y cómo vemos nosotros a los desarrolladores?

7. ¿KANBAN ES LA SOLUCIÓN?
• Kanban no es la solución para todo. Necesitamos un cambio de actitud
tanto en desarrolladores como en sistemas para derribar las barreras.
• Kanban ayuda en este proceso a conseguir:
• Comunicar el estado de las tareas y en que estamos
trabajando, generando confianza.
• Gestionar la repriorización diaria.
• Limitar el trabajo a la capacidad del equipo.
• Gestionando el limite de trabajo en curso.
• Identificar cuellos de botella y eliminarlos.
• Mejora el trabajo en equipo: colaboración en tareas y solución y apoyo
al que tiene un problema.
• Camino a ser más multidisciplinares y aprovechar al máximo la
capacidad del equipo.

8. ¿POR DÓNDE EMPEZAR?
• Comencemos reflejando nuestra actividad.
• Y sobre esto, vayamos aprendiendo y adaptándonos.
• Hasta construir NUESTRO modelo.

9. CONSTRUIR EL PRIMER TABLERO
• Definir el Mapa de la Cadena de Valor:
• ¿Cómo recibo una petición?¿Cómo la clasifico? ¿Cómo la priorizo?
• O Podemos comenzar con estados muy básicos y luego darle mayor
complejidad:
• Backlog: lista de tareas pendientes de atacar y priorizadas
• Ready: Lista de tareas que podemos acometer durante el día
• Work in Progress: Tareas en las que estamos trabajando
• Done: Trabajo finalizado. Podemos hacer “reset” de forma semanal
o quincenal.

10. CONSTRUIR EL PRIMER TABLERO
• Nos debemos hacer preguntas del estilo;
• ¿Qué
tipo
de
trabajo
tenemos?
¿Soporte/Peticiones/Proyectos/…?
¿Portales
diferentes?
• ¿Tamaño de los tipos de trabajo? Deberíamos tener tareas con
tendencia a que no duren más de 1 día para ver avances en las tareas
y no tareas eternas. ¿Pero podemos estandarizar el tamaño de las
tareas? Tallas: XS, S, M, L, XL.
• ¿Debemos compartir responsabilidad entre los diferentes tipos de
trabajo?

11. UNA IDEA
Backlog Ready WIP (3) Done
Fotocasa & Inmofactory
Segundamano
Coches
Lectiva
Sistemas comunes
FIRE!!!
PRIO
ASAP
• Podemos añadir tablas o gráficas. Por #incidencias por portal,
%disponibilidad,….
• El tablero es un radiador de información, utilicemoslo.

12. CEREMONIAS
• Crear tareas
• No es necesario reflejarlo todo. P.e: podemos decidir no añadir tareas
de 5’. Queremos ser eficientes, no crear un monstruo administrativo.
• Tal como nos llega la petición, la debemos llevar al tablero y priorizarla
con el cliente.
• El cliente debe entender que si prioriza una tarea sobre otra, implica
que algo se va a retrasar.
• ¿Damos tamaño y fecha?
• Información básica:
• Descripción suficiente saber qué hay que hacer.
• Persona que trabaja en ella.
• Peticionario.
• Otros datos: Fecha entrada, Fecha fin, #repriorizaciones, Lead
Time, Tamaño,…
• Cambio de estado de una tarea
• Al momento. El tablero debe reflejar el estado del trabajo en curso de
forma fiel.

13. CEREMONIAS
• Daily:
• Reunión diaria de sincronización del equipo
• Cada persona explica qué hizo el día anterior y qué cosas va a hacer
hoy.
• La reunión debe durar unos 15’. Se debe hacer siempre a la misma
hora. Puntualidad.
• Se pueden/deben comentar impedimentos, pedir ayuda, comentar la
priorización, comentar la solución, posibles retrasos, pero no alargar el
debate. Si es así, se deja para el final y se habla entre los implicados.
• Reset:
• No queremos acumular meses de tareas en Done. ¿1 semana es
suficiente?
• Retrospectiva:
• ¿1 al mes? ¿semanal? ¿quincenal?
• Sinceridad, escuchar todas las opiniones.
• Sed constructivos y no os tememos nada de forma personal
• Las acciones de mejora deben tener un owner del equipo y un
deadline. Revisar en la siguiente retrospectiva.

14. CONSEJOS
•
•
•
•
•
•
Experimentad y aprender.
Lo que no funciona, eliminadlo.
Leer sobre el proceso y haced el vuestro.
Personalizar el tablero.
Celebrad los éxitos.
Cuando tengamos el modelo dominado, pasemos a formato electrónico.
Nos facilitará el cálculo de lead time, quienes nos piden más cosas, más
FIRE,..
• Utilizad señales:
• Evitar interrupciones cuando tenéis que hacer un trabajo de
concentración: chaleco, bandera, …
• Decidir quien atiende a quien se acerca a Sistemas para realizar una
petición.
• Al momento. El tablero debe reflejar el estado del trabajo en curso de
forma fiel.

15. COMENCEMOS A SER AGILE!!!