Tableros kanban. Parte I: Diseño básico para gestionar flujo de trabajo

En el énfoque ágil, el tablero kanban es la técnica por excelencia para visualizar el estado del trabajo y promover el buen flujo del trabajo. Si bien esta técnica, de Taiichi Onho, se desarrolló en los años 50's y en el contexto de cadenas de montaje, actualmente se ha popularizado dentro de la comunidad ágil de la mano del método Kanban (de David J.Anderson), en el cual el tablero kanban es el protagonista.

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.

Las fichas con letras representan ítems de trabajo. Las fichas van fluyendo desde la izquierda a la derecha. En el contexto ágil estos ítems deberían representar el resultado esperado (o parte de él), tal como lo solicita el cliente. Las columnas "Pendiente" (To Do), "En Proceso" (Doing) y "Terminado" (Done) representan el estado del ítem de trabajo. Si el procesamiento que se hace de un ítem (en la columna "En Proceso" es muy sencillo y atómico (cuando básicamente se realiza una sola actividad para darlo por terminado) nos bastaría este diseño de tablero kanban. Sin embargo, si por el contrario para procesar el ítem se aplican varias actividades sobre él nos gustaría tener mayor observabilidad respecto de la actividad en la cual se encuentra el ítem en un momento determinado. Es decir, en estos casos quisiéramos reemplazar la columna "En proceso" por un conjunto de columnas que ofrezcan mayor observabilidad del proceso y permitan localizar en qué actividad específica se encuentra el ítem. Por lo tanto en este caso necesitamos hacer explícito el proceso que aplicamos a un ítem para darlo por terminado. El planteamiento es similar al de definir un procedimiento que seguiremos para abordar nuestro trabajo, es decir, lo que hacemos cuando establecemos nuestros workflows de trabajo. Sin embargo, en el caso de kanban lo acotamos a un diseño de proceso secuencial, ya que columnas contiguas representarán actividades consecutivas. Es decir, no consideraremos explícitamente operadores de paralelo (no representable directamente en un kanban) o de selección, ni tampoco añadiremos detalles respecto de roles, puntos de sincronización, mensajes, etc., elementos típicos en notaciones tales como BPMN. Debido en gran parte a su notación tan reducida es que los tableros kanban se han popularizado pues son suficientes para gestionar la mayoría de las situaciones de proceso que suelen presentarse.

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).

 Estas dos columnnas (por ejemplo, llamadas: "Introducir" y "Ordenar") reemplazan a la columna "Pendiente". Por lo tanto, la versión final de nuestro ejemplo quedaría como se muestra en la siguiente imagen:

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).

El éxito de la implantación de un tablero kanban depende en gran medida de que esté "vivo", que esté actualizado y refleje el estado del trabajo del equipo. Esto debe conseguirse con la participación de todos los miembros del equipo, no es recomendable que existan "encargados de actualizar el kanban", cada miembro del equipo debe mover el ítem cuando comienza o finaliza la actividad correspondiente. Algunas recomendaciones que ayudan a mantener un kanban "vivo":

• 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).

A continuación tenéis una lista de otros posts que he escrito con temas asociadas a tableros kanban:

• 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.

Puedes continuar leyento la segunda parte de este post: Diseño de tablero kanban para aplicarlo con Scrum (desarrollo usando Sprints).



Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

Seguimiento ágil: Dashboard global para contextos multi-proyecto

Necesitamos hacer el seguimiento del progreso del trabajo para no llevarnos sorpresas en cuanto al no cumplimiento de las expectativas, y especialmente para que esto no suceda cuando ya no tengamos tiempo para reconducir la situación. Así pues, la gestión de los cambios que surgen durante el desarrollo del trabajo es determinante para el éxito final. Lectura recomendada:  "¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?".

En cuanto a seguimiento, la literatura ágil se centra mayoritariamente a nivel operativo, es decir, el seguimiento que se debe hacer en cada línea de trabajo (cada producto o servicio encargado al equipo), sequimiento realizado por quienes trabajan en ellas. Sin embargo, también en niveles más altos (área, departamento, etc.) se quiere conocer el progreso del trabajo de todas las líneas de trabajo bajo su supervisión. Este deseo de seguimiento en niveles más altos podría asociarse (aunque desde un prisma ágil se espera que así no sea) a la desconfianza y deseo de control por el nivel inmediatamente superior. En un mundo ágil ideal la dirección dejaría que cada línea de trabajo actuase por objetivos y con la máxima autonomía :-). Desgraciadamente, esta situación resulta difícil de implantar, especialmente en empresas de cierta envergadura. Además, innegablemente la dirección tiene derecho a conocer el progreso del trabajo, independiente del uso que quiera hacer con esta información :-). Por otra parte, el querer conocer y tener una visión global del progreso de varias líneas de trabajo no es un interés exclusivo de los niveles de dirección. Aunque no es lo más deseable, suele ocurrir, en especial en empresas pequeñas, que los equipos de trabajo tienen a su cargo varias líneas de trabajo y deben distribuir su capacidad para abordarlas. Es estos casos, nos enfrentamos al mismo desafío: poder supervisar conjuntamente varias líneas de trabajo.
 
En este post me centraré en ilustrar mi recomendación para realizar el seguimiento ágil en una perspectiva multi-proyecto (es decir, seguimiento de múltiples líneas de trabajo), lo cual se presenta en un Dashboard Global. Lecturas recomendas: "Agilismo en un contexto multi-proyecto: Parte I y Parte II" y "Multi-kanban, un tablero kanban para contextos multi-proyecto".

No todas las líneas de trabajo tienen las mismas necesidades de seguimiento. Por esto, cuando queremos sintetizar el progreso de varias líneas de trabajo nos podemos encontrar con el hecho de no disponer de información uniforme para todas ellas. Hay que tener en cuenta el patrón de planificación y seguimiento que más se ajusta a cada línea de trabajo. Así pues, pueden existir líneas de trabajo en las cuales estaremos solo centrados en el flujo de trabajo finalizado y otras en las cuales, además del flujo de trabajo, y si existen compromisos de entrega poco flexibles, nos interesará también gestionar el alcance. La frecuencia de esta gestión de alcance será tan continua como los cambios que surjan durante la realización del trabajo.

Básicamente, cuando gestionamos varias líneas de trabajo (productos o servicios) nos interesa conocer su ritmo de trabajo (flujo de ítems terminados en un período) y el estado de progreso respecto del plazo para terminar el conjunto de ítems de trabajo comprometidos.

Nota: Hay que destacar que cuando me refiero a ítems de trabajo, por tratarse de un enfoque ágil, se asume que dichos ítems representan (en su gran mayoría) una parte del producto o servicio resultante (visto desde la perspectiva del cliente). Es decir, dichos ítems no son artefactos intermedios tales como especificaciones o documentos técnicos, sino que son elementos del resultado final que espera el cliente.

El tablero kanban, nos permite visualizar el estado del trabajo (en qué actividad del proceso se encuentra cada ítem). Si registramos periódicamente las contabilizaciones de ítems en cada actividad en el tablero kanban podemos representar esta información en un Diagrama de Flujo Acumulado, el cual nos permite visualizar el flujo de trabajo, ilustrando situaciones tales como: si está terminando trabajo con la regularidad deseada, si existe tendencia a acumulación en ciertas activiadades (cuellos de botella), y en general, el ritmo de trabajo en cada actividad. Lecturas recomendadas explicando detalles de los Diagramas de Flujo Acumulado: "Limitar el WIP, una buena idea, pero con matices y alternativas" y "Actividad: Tablero kanban + concepto de WIP + Diagramas de Flujo Acumulado".

Independientemente del patrón de planificación y seguimiento que más se ajuste a una línea de trabajo, por el hecho de disponer de un kanban (siempre necesario), podremos elaborar el Diagrama de Flujo Acumulado para incluirlo en el Dashboard Global.

Si el producto o servicio está trabajando con Sprints y tiene algún Sprint abierto (iniciado y no terminado) se mostraría el estado de dicho Sprint, el cual incluiría la siguiente información:

• Esfuerzo estimado
• Esfuerzo invertido
• Esfuerzo restante
• Días restantes
• Porcentaje de progreso. 100 * (Esfuerzo estimado - Esfuerzo invertido) / Esfuerzo Estimado
• Porcentaje tiempo. 100 * (Fecha de fin - Fecha actual) / (Fecha de fin - Fecha de inicio)
• Fecha de inicio
• Fecha de fin
• Advertencias. Situaciones anómalas que habría que corregir antes de interpretar el estado, por ejemplo: si falta alguna estimación, si se ha sobrepasado alguna estimación, o si la fecha de fin se ha superado.

De forma similar, si los compromisos adquiridos superan un mes de duración (la duración máxima recomendada para los Sprints), sugiero utilizar el concepto de "Proyecto" para realizar la planificación y seguimiento del compromiso global, al mismo tiempo que se utilizan los Sprints para la planificación y seguimiento (del mismo compromiso) a corto plazo, es decir, para un mes o menos. Así, por ejemplo un proyecto podría estar iniciando su tercer mes, de seis mesen que tiene de duración total, y al mismo tiempo podría estar en su quinto Sprint (si por ejemplo se están usando Sprints de 2 semanas cada uno). Así, para cada proyecto podríamos disponer de la misma información antes indicada para Sprints, con la diferencia que el proyecto en cuanto a fechas de inicio y fin abarcará un tiempo mayor.

También podría darse el caso que una línea de trabajo no utilizase Sprints y sin embargo, utilice proyectos para agrupar ítems de trabajo, que probablemente se estén realizando junto con otros ítems pertenecientes, o no, a otros proyectos. 

A continuación se muestra una imagen del Dashboard Global que hemos implementado en nuestra herarmienta TUNE-UP Process, cubriendo las situaciones antes descritas.

Cada línea en el grid representa un Sprint o Proyecto de un Producto o Servicio. También aparece una línea para el producto o servicio, aunque no tenga Sprints o Proyectos, caso en el cual solo se muestra el Diagrama de Flujo Acumulado. Las columnas de datos muestran la información que se indicó anteriormente.

Desde los botones en la barra de herramientas se puede acceder a una visualización del estado de los Sprints (o de los Proyectos), la cual se muestra en la imagen anterior, en el cual cada punto representa un Sprint (o Proyecto). El eje X representa el porcentaje de tiempo en que nos encontramos respecto de la duración total. El eje Y representa el porcentaje de progreso respecto del esfuerzo total estimado. Los puntos que están sobre la diagonal representan Sprints (o Proyectos) que van bien, y los bajo dicha línea son los que van mal. El código de colores del Dashboard Global representa cuanto va de bien o mal un Sprint (o Proyecto). Es importante destacar que estamos asumiendo un progreso uniforme respecto del tiempo como sinónimo de que el Sprint o Proyecto va bien. Podría darse que intencionalmente, y en especial en situaciones de un equipo sometido a multi-proyecto, que se tome la decisión de centrarse durante ciertos períodos en solo algunas líneas de trabajo (o incluso en una sola) para no degradar excesivamente el desempeño del equipo al tener que hacer cambios de contextos entre muchos trabajos diferentes. En estos casos, la visualización destacará dichas situaciones, pero sabremos que intencionalmente una línea de trabajo podría aparecer muy bien (las que avancemos primero) en desmedro de otras que irían muy mal (las que posterguemos).

Además, desde el enlace para el Sprint (o Proyecto) se puede acceder al Dashboard del Sprint (o del Proyecto), el cual se muestra en la siguiente imagen.

Es importante señalar que para hacer consistente un enfoque ágil con el uso de información para seguimiento (como la que he indicado antes) es imprescindible que su recolección, procesamiento y presentación sea automática. Es decir, no debemos sacrificar el minimalismo y sencillez que queremos promover en el trabajo del equipo por la sobrecarga que podrían suponer dichas tareas si se hicieran manualmente.




Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com