Para que un tablero kanban resulte eficaz debe estar bien diseñado y deben estar claras las reglas del juego según las cuales el equipo interactúa con el tablero (algunas de ellas se traducen en decoraciones extra que se añaden al tablero o a los ítems de trabajo). En este post me centraré en el diseño básico del tablero kanban, orientado a visualizar el flujo de trabajo. En un próximo post abordaré el diseño y mecánica cuando además se trabaja con Sprints, en lo que se suele denominar Scrumban (combinando Scrum con tableros kanban) y aclararé el concepto de Backlog cuando se usa en el mmarco de un tablero kanban.
La siguiente figura muestra el tablero kanban en su diseño más simple.
Siendo minimalistas, podremos coincidir en que para cualquier típo de ítem podríamos tener que realizar al menos 3 actividades para darlo por terminado: Definirlo, Ejecutarlo y Probarlo. Por ejemplo, en el ámbito de desarrollo de software estas actividades podrían llamarse: Definir (D), Programar (P) y Probar (T). Ellas se muestran a continuación:
Es importante destacar que dentro de una actividad pueden realizarse varias tareas, cada una de ellas podría convertirse en actividad (una columna independiente) pero mientras no se justifique, es preferible tener menos actividades (columnas), aunque entro de ellas se realicen varias tareas.
Correspondientemente un tablero kanban que incluya las actividades indicadas antes podría ser el siguiente:
No es el propósito de este post el explicar o recomendar la mecánica de interacción con el kanban, pero en esencia, tal como comenté antes, la idea es que los ítems fluyan de izquierda a derecha hasta terminarse, y a un buen ritmo pues eso significará que estamos terminando parcialmente (incrementalmente) el trabajo que nos solicita nuestro cliente. Dependiendo del ámbito de trabajo pueden existir saltos de actividades (columnas), tanto hacia adelante como hacia atrás (en casos de re-trabajo por detección posterior de defectos o que el trabajo no está completo).
Cada ítem de trabajo podría tener un kanban diseñado específicamente para él. Sin embargo, es obvio que si ciertos ítems de trabajo son procesados de forma similar, tengamos un kanban para todos esos ítems de trabajo. Por ejemplo, en un ámbito de desarrollo de software los ítems suelen ser de tipo: Nuevo Requisito, Mejora o Corrección de Fallo y aunque se trate de diferentes típos de ítems, todos requieren básicamente el mismo procesamiento, aunque quizás con diferente intensidad. Por ejemplo, una Corrección de Fallo puede que no requiera tanta definición como una Mejora o un Nuevo Requisito. Sin embargo, si por el contrario hay ítems de trabajo que tienen un procesamiento particular, convendría que tuviesen su propio tablero kanban, puesto que si mezclamos ítems con diferentes procesamiento en un mismo kanban el equipo de trabajo debe tener muy presente qué actividades deben aplicarse a unos ítems o a otros, saltándose las actividades que no deban ser aplicadas a un ítem. Por contraparte, para una gestión integrada siempre es preferible tener menos tableros kanban, especialmente si se trata del mismo ámbito de trabajo, con lo cual si solo existen pequeñas diferencias de procesamiento, basta con identificar la o las columnas que podrían ser opcionales o no aplicables a un determinado tipo de ítem. Pero también deberíamos considerar si tenemos diferentes líneas de trabajo. Una línea de trabajo puede ser un producto en desarrollo, un servicio ofrecido al cliente, o una agrupación de ítems asociados a un proyecto). En términos de gestión resulta más sencillo tener un kanban para cada línea de trabajo (auque tengan tipos de ítems con procesamiento similar), ya que de esta forma nos evitamos tener que introducir decoraciones (por ejemplo colores para ítems) que ayuden a distinguir en un mismo kanban ítems de diferentes líneas de trabajo.
Un nivel adicional de detalle que resulta interesante es poder conocer si un ítem en una actividad está pendiente, en proceso o terminado. Es decir, lo mismo que nos planteábamos de forma global en el kanban más simple mostrado antes, pero ahora visto a nivel de actividad. De manera que pudíesemos, por ejemplo, saber qué ítems están pendientes de Programar, los que ya se están Programando y los que se han terminado de Programar pero aún no se han pasado a Testear. Como vemos en la siguiente imagen, si aplicamos este detalle a cada actividad de procesamiento se produce solape entre el Done de una actividad y el To Do de la siguiente. Por eso, lo que hacemos es fundir esas dos subcolumnas en una sola. Dado que normalmente al finalizar una actividad se sabrá si es necesario pasar el ítem a la siguiente columna o si conviene saltarse ciertas columnas, prefiero que las dos subcolumnas solapadas se fundan en el To Do de la siguiente.
Así, haciendo dicha fusión de subcolumnas, nuestro kanban de ejemplo quedaría como se muestra a continuación.
Adicionalmente, existen dos situaciones comunes que conviene considerar:
- Cuando ya se ha identificado la necesidad de realizar un cierto ítem pero aún nos falta información para dar comienzo a su procesamiento (incluso puede que dicho ítem finalmente se desestime). En mi experiencia, me ha resultado efectivo tener una actividad llamada "Introducir" en la cual aseguro que un ítem que finaliza esta actividad tiene la información suficiente para empezar a ser procesado (la que se determine en el contexto), además en esta actividad se revisa si el ítem está repetido o tiene solapes con otros ítems.
- Cuando un ítem ya está listo para ser procesado pero debe evaluarse su prioridad respecto del resto de ítems que aún no se han comenzado a procesar. Nuevamente, mi experiencia me confirma la conveniencia de incluir siempre una actividad llamada, por ejemplo, "Ordenar". Se trata más bien de un búffer de contención para evitar que se comience a procesar un ítem que no es el más oportuno realizar en dicho momento. Hay que establecer la prioridad, o mejor dicho, hay que determinar el orden de procesamiento de los ítems, pues no es solo una cuestión de importancia del ítem. Para esto deberían considerarse diferentes criterios y de su evaluación obtendríamos una posición (orden) de procesamiento para cada ítem. Lectura recomendada: Gestión eficaz del Product Backlog. Además, dicho orden debería intentar respetarse durante el procesamiento del conjunto de ítems. En esta columna "Ordenar" se acumularían todos los ítem que aún no se empiezan a procesar (tengan o no tengan orden) y periódicamente se ordenarían los último en llegar y que no tengan aún orden. Así, pasar un ítem de To Do a Doing en esta columna "Ordenar" implica intercalar el ítem en la posición que le corresponda entre los ítems que ya están en la subcolumna Doing (es decir, asignarle un orden respecto a todos los ítems todavía no procesados). En esta actividad los ítems se mantendrían en Doing hasta que no se decidiera comenzar a procesarlos (pasándolos a To Do de la primera actividad de procesamento).
Me gustaría insistir en que lo recomendable es comenzar a aplicar tableros kanban de forma minimalista, menos tableros y con menos actividades (columnas). Algunas sugerencias al respecto:
- Cada línea de trabajo podría tener su propio kanban pero si estamos en una situación multi-proyecto hacerlo con kanban físicos esto puede resultas complicado, puede que nos falten paredes donde poner todos los tableros :-). En estos casos mejor es utilizar desde el principio algún software.
- Si actividades consecutivas las realiza la misma persona y siempre una inmediatamente después de la otra quizás sea mejor fusionar dichas columnas en usa sola. Por contraparte, aunque se trate de una misma persona que realiza dos tareas dentro de una actividad (columna), pero dichas tareas no se realizan una tras otra inmediatamente y se quiere saber en qué tarea está un ítem, podemos promover dichas tarea a actividades, es decir, dividir la actividad original en dos (dos columnas).
- Hacer reuniones frecuentes de puesta en común del trabajo del equipo, realizadas frente el kanban. Scrum y Extreme Programming recomiendan una reunión diaria de 15 minutos y de pié (las denominan Daily Scrum y Stand-up meeting, correspondientemente), lo ideal es realizar esta reunión en semicírculo frente al kanban.
- Usar alguna decoración para indicar quién está trabajando en un determinado ítem. Por ejemplo, poner un avatar que representa a la persona trabajando en el ítem.
- Si los ítems pasan días o semanas en una actividad el kankan no mostrará cambios y esto restará interés por verlo. Puede que la mayoría de nuestros ítems tienda a ser Épicas (ítems muy "grandes"). En este caso se podría intentar dividirlos (teniendo cuidado de no dificultar la gestión puesto que los ítems resultantes de la división podrían ser muy dependientes entre sí) o hacerlos incrementalmente, identificando un item por el cual se comenzará a trabajar y dejando como otro ítem el resto del trabajo. Otra posible causa de la poca movilidad de ítems en el kanban es que en algunas actividades se estén haciendo demasiadas tareas, con lo cual podría evaluarse si conviene promover algunas de dichas tareas como actividades (columnas), cuando por ejemplo, son realizadas por diferentes personas o en distintos momentos.
- Si bien en un principio un kanban físico (montado en una pared con post-it) da un buen impulso en cuanto a motivación, ya que conlleva algo de bricolaje y esto resulta entretenido, hay bastantes limitaciones que luego se pueden volver en contra de la sostenibilidad de dicha motivación y actualización del tablero. Más pronto que tarde sugiero pasar a utilizar un tablero soportado por alguna herramienta software. Sin embargo, al hacer esa transición debe asegurarse que el tablero físico, como punto de reunión, sea reemplazado por una pantalla (ojalá de grandes dimensiones).
- Una evaluación informal de herramientas gratuitas que ofrecen soporte para tableros kanban. Kanban for free. Si buscas algo más completo para gestión de proyectos y que además incluya tableros kanban te sugiero nuestra herramienta TUNE-UP Process :-).
- Tableros kanban para contextos multi-proyecto.
- Relación entre tableros kanban, el método Kanban y el método Scrum. ¿Kanban or Scrum? That is not the question.
- Una actividad para ilustrar la mécánica de un tablero kanban.
- Desafíos para la aplicación de tableros kanban.
- Workflows y su relación con tableros kanban. Parte I y Parte II.
Patricio Letelier
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com
No hay comentarios:
Publicar un comentario