Lo primero que destacaría es que un mismo equipo a lo largo del tiempo (e incluso en un mismo período) puede ser responsable de uno o más productos o servicios (o proyectos definidos sobre ellos). Además, en cada caso, y aunque se trate del mismo equipo, las características de cada tipo de trabajo pueden ser diferentes. No reconocer esta diversidad llevaría que en algunos casos nos "sobre proceso" y en otros quizás nos "falte proceso", es decir, que algunas actividades sobre o tengan que realizarse con menos intensidad, o por contraparte que deban añadirse otras actividades no contempladas inicialmente o complementar las existentes, todo ello dependiendo de la unidad de trabajo abordada. Por unidad de trabajo me refiero a un ítem de trabajo, historia de usuario, incidencia, expediente, etc., es decir, un gránulo de trabajo dentro de un producto, servicio o proyecto. La siguiente figura remarca la diversidad de trabajos de los cuales un equipo podría estar encargado durante períodos de tiempo (en la Parte I ya comenté que esto, aunque NO es lo más deseable, suele ocurrir :-) y no es fácil de evitar). En cada caso debería realizarse la configuración del proceso que se aplicará.
Esta diversidad tampoco implica tener obligatoriamente un proceso a medida para cada unidad de trabajo, o cada producto, servicio o proyecto. En la práctica simplemente hay que tener un conjunto de workflows (ver Workflows Flexibles) que acumulen la experiencia de proceso del equipo ante determinados tipos de trabajo. La definición de estos workflows resuelven directamente una parte de la planificación y seguimiento puesto que cuando una unidad de trabajo sigue un workflow tenemos una previsión de las actividades que se realizarán sobre ella y el seguimiento básico es conocer en qué actividades del workflow se encuentra cada unidad de trabajo. Este seguimiento esencial se debería apoyar con un tablero kanban (no estoy hablando de el Método Kanban de David Anderson, solo del tablero kanban, que de paso también es utilizado en dicho método) . El problema es que cuando nos enfrentamos a la diversidad antes indicada necesitamos un tablero kanban más versátil (ver algunos Desafíos para la aplicación efectiva de Scrum + Kanban = Scrumban).
Más adelante en este post seguiré comentando respecto del tablero kanban. Centrémonos ahora en la clasificación que os propongo. En general existen dos tipos de trabajo, los denominaré Orientado a Flujo y Orientado a Sprint/Proyecto.
Trabajo Orientado a Flujo
Un trabajo Orientado a Flujo es aquel para el cual no es conveniente hacer planificación y seguimiento respecto de un compromiso o previsión de terminación. A priori cualquier trabajo podría ser planificable, sin embargo, la planificación pierde protagonismo o resulta poco rentable cuando el trabajo pendiente cambia continuamente (y no se pueden predecir dichos cambios), o cuando más importante que generar grupos de unidades de trabajo terminadas en un determinado plazo es generar un flujo continuo de unidades de trabajo terminadas a lo largo del tiempo. En este caso se reemplaza la planificación continua por la continua priorización del trabajo. El desempeño de un trabajo Orientado al Flujo se mide en términos de parámetros tales como: Cycle Time (tiempo desde que se empieza un trabajo hasta que se termina), Lead Time (tiempo desde que se registra el trabajo como pendiente hasta que se termina) y Production Rate (número de unidades de trabajo terminadas por unidad de tiempo). En este contexto se suelen establecer SLAs (Acuerdos de Nivel de Servicio) que determinan ciertos objetivos respecto de parámetros tales como los indicados antes. También, y relacionado con alcanzar un buen flujo, es importante supervisar el WIP (Work in Process) para detectar y resolver posibles cuellos de botella. Los siguientes son ejemplos de trabajo para los cuales es más conveniente generar flujo de unidades de trabajo terminadas que planificar unidades de trabajo en el marco de un Sprint o de un proyectos:- Atención o soporte al cliente
- Solución de incidencias
- Mantenimiento correctivo o de pequeñas mejoras en un producto
- Otros trabajos donde existan workflows y la demanda (unidades de trabajo que se reciben) no es controlable, es decir, simplemente se va recibiendo y según ciertas políticas se va atendiendo. En este caso estaría los procedimientos administrativos en general, en los cuales los "expedientes" (por usar un nombre para la unidad de trabajo) se van atendiendo según orden de llegada, prioridad, urgencia u otros criterios.
Tablero kanban
Cuando un equipo esté encargado de varios productos, servicios o proyectos, no nos bastará con cualquier tipo de tablero kanban . Lo ideal es que el tablero kanban sintetice todo el trabajo del equipo y a la vez, de una manera sencilla, permita visualizar dicha información filtrada por producto/servicio, proyecto, miembro del equipo, etc., y que también ayude a localizar rápidamente un cierta unidad de trabajo. El equipo deberá tener una estrategia para distribuir su capacidad cuidando el no penalizar demasiado su rendimiento en los cambios de contexto al pasar de un producto/servicio o proyecto a otro durante un mismo período. El tablero kanban debería ayudar a seleccionar correctamente el trabajo que debe ser realizado en cada momento por los miembros del equipo. La siguiente figura muestra una parte del kanban de nuestra herramienta TUNE-UP Process, en el cual en el grid de la izquierda se tiene una lista de actividades con las contabilizaciones de unidades de trabajo en cada una de ellas, separando por estado To Do y Doing. Seleccionando en una celda en el grid de la derecha se puede ver la lista de unidades de trabajo en dicha actividad-estado. Sobre esta información se pueden aplicar los filtros y la búsqueda antes indicada.
Así, un tablero kanban ofrece una excelente visualización de dónde están las unidades de trabajo respecto del su workflow (el proceso definido por las actividades por las cuales pasan las unidades de trabajo que siguen dicho workflow). Lectura recomendada Multi-kanban, un tablero kanban para contextos multi-proyecto.
Gráfica de Flujo Acumulado (Cumulative Flow Diagram - CFD)
La siguiente figura muestra en las columnas de tabla de la izquierda los snapshots con contabilizaciones del WIP en cada actividad del tablero kanban. La Gráfica de Flujo Acumulado de la derecha muestra cómo un aumento del ancho de una franja (el WIP de una actividad del proceso) alerta de un posible cuello de botella.
Trabajo Orientado a Sprint/Proyecto
Un trabajo Orientado a Sprint o Proyecto es un trabajo planificable, es decir, que antes de comenzar a ejecutar el trabajo se puede/debe identificar, organizar y estimar las unidades de trabajo necesarias para obtener un resultado en un plazo establecido y con la restricción de capacidad del equipo para dicho trabajo. En esta situación suele existir compromiso o pronóstico asociado a completar un cierto alcance, en un determinado plazo, y con determinados recursos. Para que un trabajo sea planificable debe cumplirse que éste, al menos en gran parte, pueda ser definido con anticipación y/o que no sufra modificaciones significativas durante su ejecución. El límite está en el punto en el cual ya no tiene sentido intentar re-planificar y hacer un seguimiento al respecto cuando el plan se modifica con demasiada frecuencia. En las metodologías ágiles se promueve la planificación y el seguimiento continuo, alineado con la idea de conseguir entregas frecuentes de trabajo terminado. Sin embargo, como se trabaja con ciclos cortos (Scrum recomienda sprints de menos de 4 semanas y Extreme Programming de menos de 3 semanas), se sugiere que mientras no se trate de una urgencia, no se altere el contenido de un sprint. El desempeño de un trabajo planificable se mide considerando el grado de terminación de las unidades de trabajo acordadas para terminar en el Sprint.La técnicas que recomiendo para realizar el seguimiento y la mejora del proceso en un contexto orientado a Sprint o Proyecto son el tablero kanban, la Gráfica Burndown (ver Gráficas Burndown: ¿Cómo rentabilizar el esfuerzo para elaborarlas?) y la Gráfica de Trabajo Finalizado (que muestra la proporción del trabajo terminado respecto del trabajo pendiente). Nótese que el tablero kanban es la técnica básica que recomiendo usar tanto para un trabajo Orientado a Flujo como para uno Orientado a Sprint o Proyecto.
Gráfica Burndown y otras complementarias
La siguiente figura muestra una Gráfica Burndown. La línea roja representa el esfuerzo restante día a día durante un Sprint o Proyecto, el cual debe evaluarse respecto de la línea de referencia (la línea morada) que converge hacia 0 en el día de finalización del Sprint o Proyecto. La línea azul es el Burn-up, el esfuerzo invertido y la línea verde es el esfuerzo estimado.
Puede que el trabajo restante muestre una buena tendencia pero que todas las unidades de trabajo estén sin terminar y posiblemente acumulándose en las últimas actividades del proceso. Para anticiparse a esta anomalía se recomienda complementar el Burndown con la Gráfica de Trabajo Finalizado como la mostrada en la siguiente figura, donde la parte naranja de la barra representa el esfuerzo asociado a unidades de trabajo no terminadas y la parte verde corresponde al esfuerzo de las unidades de trabajo ya terminadas.
Si queremos tener una visualización integrada del estado de varios Sprints y/o Proyectos hemos elaborado la siguiente gráfica, la cual es una adaptación de la representación sugerida por J. R. Holt (ver How to Get Things Done, Visual project management shows the way). En esta gráfica cada punto representa un Sprint o Proyecto. En el eje Y se representa el % de progreso del trabajo, medido como el esfuerzo invertido respecto del esfuerzo total estimado. El eje X representa el progreso del tiempo, medido como el tiempo transcurrido desde el comienzo del Sprint o Proyecto hasta el día actual respecto del tiempo total.
A continuación se nuestra cómo hemos implementado dicha visualización en TUNE-UP Process Nótese que para la correcta interpretación de la gráfica todo el trabajo del proyecto debe estar estimado (pues sino no estaríamos considerando todo el esfuerzo asociado) y no deben sobrepasarse dichas estimaciones (pues el trabajo restante tendría un valor negativo). En la gráfica, estas advertencias se destacan poniendo en negrita y con un asterisco el nombre del proyecto, y además, el bocadillo que se muestra al poner el cursor sobre un proyecto indica en sus últimas líneas dichas advertencias respecto del número de unidades de trabajo en dicha situación anómala.
Haciendo doble click sobre un proyecto se puede acceder a su dashboard, del cual se muestra con un ejemplo en la siguiente figura.
Desde el dashboard se puede acceder a la lista de unidades de trabajo o directamente al detalle de una unidad de trabajo, ambos casos ilustrados a continuación:
Conclusiones
Primero debo insistir en que un ambiente multi-proyecto NO es lo óptimo para el rendimiento del equipo. Existirá una reducción del desempeño del equipo por tener que estar cambiando de contexto entre diferentes trabajos, ocurriendo algo similar a lo que pasa en un proyecto cuando los participantes intentan avanzar en paralelo muchos ítems asociados de dicho proyecto. La recomendación es similar a la ofrecida en el marco de un proyecto: reducir/limitar el WIP, pero en este caso a nivel del conjunto de proyectos asignados al equipo. Según esto, lo primero que habría que hacer es intentar reducir la cantidad de proyectos encargados a un equipo. Las decisiones al respecto deben ser tomadas por la dirección pues conllevará seleccionar los proyectos más prioritarios, postergar el comienzo de ciertos proyectos, suspender temporalmente algún proyecto, etc. Probablemente aún después de tomar estas decisiones, el equipo siga teniendo asignado varios proyectos :-(, con lo cual el siguiente paso es proporcionar pautas claras respecto de cómo el equipo debe distribuir su capacidad. Para cada tipo o línea de trabajo encargada a un equipo debería identificarse su orientación (Flujo o Sprint/Proyecto). Dependiendo de la orientación, se aplicarían las técnicas indicadas, teniendo el tablero kanban como técnica base aplicable siempre e independiente de la orientación del trabajo. Para los trabajos con Orientación al Flujo deberían establecerse "reservas de capacidad" (esfuerzo que dedicará el equipo por día, semana o mes). Para los trabajos con Orientación a Sprint/Proyecto debería distribuirse la capacidad restante. Así, el equipo intentará en un cierto período de tiempo cumplir con dichas directrices en cuando a distribución de su capacidad. Especialmente para el caso de Orientación a Sprint/Proyecto, mientras mayor sea el período utilizado mejor será para el equipo, por ejemplo, si el equipo tiene que dedicar un cuarto de su capacidad para un proyecto, mejor es que el equipo dedique una semana del mes a dicho proyecto, en lugar, por ejemplo, que esté dedicando un cuarto de cada día a dicho proyecto.Por otra parte, una visión más "ejecutiva" y realista del agilismo (que complementa a las más usuales, centradas más en presentación de metodologías y prácticas ágiles, e ignorando los desafíos del trabajo multi-proyecto) debería ayudar para conseguir el apoyo de los niveles más altos de la organización y entidades del tipo PMO para implantar prácticas ágiles, puesto que podemos demostrar que:
- La planificación y seguimiento ágil puede ser tan o más rigurosa que la ofrecida en enfoques tradicionales.
- Es posible reducir o evitar el interrumpir a los equipos o ciertos miembros para que éstos recolecten datos y preparen estados de situación de su trabajo. Esta información resumida, que está orientada hacia la supervisión global y periódica que requieren los niveles superiores, no suele rentabilizarla el equipo en su trabajo diario. Si conseguimos que la disciplina de trabajo del equipo conlleve de forma natural y en el momento la recopilación de dicha información este esfuerzo se verá recompensado por el ahorro de todo el esfuerzo gastado a causa de dichas interrupciones. Además, los niveles superiores pueden realizar la supervisión en cualquier momento y sólo intervenir puntualmente cuando sea necesario.
Patricio Letelier
