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