viernes, 23 de noviembre de 2012

Agilismo en un contexto multi-proyecto. Parte II: Planificación y Seguimiento

En este post ilustraré cómo es posible planificar y realizar el seguimiento de múltiples proyectos bajo un marco común de prácticas ágiles (ver Parte I).

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.   
La técnicas recomendada para realizar el seguimiento y la mejora del proceso en un contexto orientado al flujo son el tablero kanban (ver Kanban for free: una evaluacion informal de 5 herramientas gratuitas) y la Gráfica de Flujo Acumulado (Cumulative Flow Diagram, CFD), (ver Limitar el WIP una buena idea pero con matices y alternativas).

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.
La clave para el éxito del enfoque presentado y para mantenerse fiel a los principios ágiles es que toda la recolección y síntesis de la información para el seguimiento se realice de forma automática sin suponer un esfuerzo adicional para los equipos.Además, se ofrecen mecanismos para que el registro de progreso del trabajo (cuando este registro se considera necesario) se realice de forma semi-automática.
En Tune-up Process hemos abordado todas las funcionalidades comentadas y enfrentado muchos detalles adicionales, pero esto sería largo para explicar en un post :-).



Patricio Letelier

lunes, 5 de noviembre de 2012

Agilismo en un contexto multi-proyecto, Parte I: Proyectos-Productos-Servicios

Gestionar simultáneamente múltiples proyectos es un gran desafío, y tiene mucho de malabarismo.

Dos situaciones me han motivado a escribir este post. La primera es que más que una excepción, es casi una regla que un equipo de trabajo es responsable de más de un producto o servicio. Cuando todo el equipo está 100 % dedicado en un solo proyecto, la planificación y seguimiento se simplifica considerablemente. La mayoría de la literatura ágil asume esta condición favorable (que el equipo trabaja en solo un proyecto a la vez) o simplemente ignora dicha situación multi-proyecto. Por otra parte, el agilismo encuentra un importante obstáculo respecto de cómo convivir con (o cambiar) las prácticas tradicionales de planificación y seguimiento de proyectos, especialmente en organizaciones de mayor tamaño y/o donde hay prácticas tradicionales institucionalizadas, y posiblemente promovidas por una PMO (Project Management Office) o entidad similar. Así pues, pienso que es clave dotar de una visión "ejecutiva" al agilismo, para poder convencer de sus bondades y conseguir ese apoyo imprescindible de los niveles altos de la organización. Hasta ahora lo que más he visto/leído al respecto corresponde a una estrategia de confrontación con la gestión tradicional de proyectos. Mi recomendación como estrategia, y sin ceder un ápice respecto de las prácticas ágiles asociadas, es ilustrar y demostrar que la planificación y el seguimiento ágil son efectivos, y especialmente, que pueden reportar información del estado de los proyectos tan o más completa y rigurosa como la que se haría con un enfoque tradicional. Esto último es lo que debería enfatizarse como argumento y como punto de encuentro y convivencia con otros enfoques más tradicionales.  

En esta Parte I voy a presentar la problemática y establecer la terminología para, posteriormente en la Parte II mostrar nuestra visión respecto de cómo abordarlo.

El término "proyecto" suele resultar ambiguo cuando se utiliza para referirse a cualquier trabajo que desarrolla un equipo. En el PMBOK "proyecto" se define como el esfuerzo temporal llevado a cabo para crear un producto, servicio o resultado, y que en cada cualquier éstos sean únicos. Aquí "únicos" se usa para para diferenciar proyecto respecto de "operaciones", las cuales de forma repetitiva producen productos u ofrecen servicios. Es importante puntualizar el significado de proyecto puesto que en el agilismo se enfatiza más el concepto de producto o servicio, pues se desea por ejemplo, establecer un buen flujo de trabajo terminado asociado a un servicio, o se desea hacer entregas frecuentes de nuevas versiones de un producto. Si bien cuando sólo interesa generar un buen flujo estaríamos más cercanos a "operaciones", cuando se hace una entrega frecuente de versiones de un producto la diferencia entre proyecto u operaciones puede no ser tan clara. Proyecto debería en un contexto ágil interpretarse como un sinónimo de Release (o entrega a producción) de un nuevo producto, o la creación de un nuevo servicio, o incluso un cambio o remodelación significativa de un producto o servicio (la cual conllevará un esfuerzo y tiempo importante).

Dicho lo anterior, un equipo puede estar ligado a varios productos o servicios. Por contraparte, un producto o servicio podrá estar ligado a varios equipos responsables de diferente proyectos (por ejemplo el equipo que lo crea o el equipo asociado a una remodelación importante) o equipos de operaciones (por ejemplo, el equipo de mantenimiento o el equipo de soporte). Así pues, la siguiente imagen ilustra la relación muchos-a-muchos entre equipo y producto/servicio.
Obviamente, esta situación "muchos-a-muchos" no es la más apropiada ni para el desempeño del equipo ni para el desarrollo o mantenimiento eficiente del producto o servicio. El equipo en esta situación debe distribuir su capacidad en la atención de varios productos o servicios, y los cambios de contexto penalizarán su desempeño. Esta situación es similar a la que se presenta cuando existe un WIP (Work in Process) demasiado alto en alguna actividad de un tablero kanban, el efecto negativo es el mismo, el alternar entre un trabajo y otro, sin privilegiar la finalización un determinado trabajo, reduce el desempeño del equipo. Pero limitar el WIP a nivel de ítems de trabajo es más sencillo que limitar el número de productos o servicios de los cuales es responsable un equipo, lo cual no suele ser decisión del equipo, sino de más alto nivel. Por otra parte, la tendencia en grandes empresas no suele ser crear equipos por producto o servicio. Así pues, tal como se refleja en la siguiente imagen, el trabajo sobre un producto o servicio lo pueden realizar diversos equipos, muchas veces creados puntualmente para un proyecto, o equipos externos encargados del outsourcing de ciertas actividades. Los protocolos de interacción entre estos diferentes equipos suelen penalizar el desempeño del producto o servicio visto de forma global.
Podríamos promover que se evite o reduzca dicha situación "muchos-a-muchos", sin embargo, no se trata de una decisión sencilla y rápida de implantar. Además, el tener diferentes equipos realizando trabajo sobre un mismo producto o servicio también tiene sus ventajas. Por ejemplo, basta pensar en el impacto que tendría prescindir del Outsurcing de actividades o de un área de QA, y la resistencia que encontraríamos para intentar hacerlo. Así pues, de antemano debemos estar preparados para ofrecer una forma se abordar de la mejor manera dicha situación, probablemente conviviendo con ella o haciendo mezclas. Por ejemplo, un Outsourcing in-situ, contando con el personal del proveedor en nuestra empresa no representa ningín inconveniente mayor de cara a nuestro propósito de aglutinar equipo. Si ponemos como condición previa a la implantación de agilismo que dicha situación "muchos-a-muchos" no exista, probablemente ni siquiera se llegue a disponer de una oportunidad para introducir agilismo en dicho contexto.

En mi opinión, la mejor forma de conseguir el apoyo de los altos ejecutivos para la introducción del agilismo (más allá de explicarles las bondades de la cultura y prácticas ágiles) pasa por dar respuesta a los siguientes desafíos (sin renunciar a los principios ágiles):
  1. Realizar la planificación y el seguimiento de los diferentes productos, servicios y/o de sus proyectos asociados.
  2. Coordinar los diferentes equipos que trabajan en un producto o servicio.
  3. Abordar eficazmente con un mismo equipo trabajo en varios productos o servicios durante un mismo período de tiempo.
  4. Supervisar el trabajos de diferentes equipos, disponiendo de reportes de estado que puedan equipararse a los que suelen disponer en proyectos tradicionales.
Cada uno de estos puntos los desarrollaré en detalle en la Parte II. Ahora concluiré esta primera parte enfatizando la gran oportunidad de mejora que en general se puede tener respecto del punto 4. 

La forma en la cual se generan los reportes de estado en un contexto tradicional suele constituir una gran fuente de desperdicio ("waste"). A pesar de que la información de estado se genera a nivel operativo en cada equipo, ésta no suele ser aprovechada (al menos no restabilizada del todo) en el día a día del trabajo del equipo, y solo se recolecta de forma periódica para elaborar informes dirigidos a niveles superiores de supervisión. Por ejemplo, la gerencia pide informes a los departamentos, éstos a las unidades departamentales, éstas a los jefes de proyecto, y éstos finalmente recolectan la información que les proporcionan los miembros del equipo, por ejemplo, registrándola una vez a la semana. La siguiente imagen ilustra esta situación.


Las interrupciones y el tiempo invertido en dicha recolección de información y preparación de datos puede (y debería) evitarse. Hay que conectar el registro de dicha información con el trabajo díario de los miembros del equipo, de forma que el registro y recolección se realice de forma semi-automática. Además, hay que automatizar la elaboración de dichos reportes de estado, y finalmente, hay que promover una política de transparencia en cuanto a que dicha información esté disponible en todo momento y para todos los que la necesiten. 



Patricio Letelier