sábado, 15 de junio de 2013

Multikanban, un tablero kanban para contextos multiproyecto

Antes de empezar, es importante puntualizar que con "multiproyecto" me refiero a la situación en la cual un equipo ágil está encargado de varios (muchos) proyectos. NO me refiero a "escalar la agilidad", o cómo varios equipos pueden participar de forma coordinada en un trabajo de mayor envergadura abordado por varios equipos de trabajo. En este último caso ya hay bastante información bajo la etiqueta "Scrum de Scrums", es decir, dividir un proyecto de gran tamaño (y con muchas personas involucradas) en áreas y equipos, de forma que cada equipo esté dedicado un área diferente pero coordinados respecto del trabajo global. Recomiendo la lectura de un caso real descrito en Scaling Agile @ Spotify with Tribes,Squads, Chapters & Guilds.

Para una introducción al enfoque ágil en contextos multiproyecto recomiendo mis posts "Agilidad en un contexto multiproyecto" Parte I y Parte II.

No existe un planteamiento consensuado respecto del enfoque ágil en una situación en la cual un equipo está encargado de varios (muchos) proyectos. Acerca de esta situación sugiero echar un vistazo a los siguientes debates
Un escenario multiproyecto no es un tema usualmente abordado en la bibliografía ágil. Si bien no se menciona explícitamente que un equipo debe dedicar toda su capacidad de manera exclusiva a un solo producto/servicio, cuando se describen los métodos ágiles se pasa por alto la existencia de esta situación multiproyecto. Correspondientemente, en general las herramientas tampoco ofrecen mecanismos específicos para dicha situación, parece que se asume como normal que un equipo en un contexto multiproyecto, tenga que por ejemplo, trabajar con varios tableros kanban a la vez, o que de manera artificial se tienda a incluir en un Backlog o sprint ítems que corresponden a diferentes productos/servicios.

¿Por qué un contexto multiproyecto es una realidad difícil de cambiar?
  • Porque existen oportunidades de negocio y no se cuenta con suficiente personal para abordarlas cada una de forma exclusiva. ¿Qué empresa estaría dispuesta a perder un proyecto porque el cliente no quiere esperar un aplazamiento para el comienzo del proyecto?. Además, si se trata de una empresa pequeña el aumento de proyectos conlleva directamente que equipos y/o personas NO estén con dedicación exclusiva a un proyecto. 
  • Porque los productos/servicios resultantes de un proyecto requieren mantenimiento. Los productos/servicios no tienen necesariamente una continuidad de esfuerzo dedicado a ellos por parte del equipo, ni tampoco requieren la misma intensidad en cuanto a cantidad de esfuerzo dedicado a ellos. Probablemente, se necesitará mayor capacidad del equipo dedicada cuando se desarrolla la primera entrega del producto o cuando se lleva a cabo el desarrollo de un nuevo módulo de tamaño considerable. Sin embargo, el Backlog del producto/servicio sigue vivo mientras el producto/servicio está siendo utilizado, es decir, seguirá existiendo una demanda en términos de nuevos ítems añadidos al Backlog. Probablemente mientras no se tengan ítems urgentes que obliguen a realizar una asignación de capacidad del equipo, o en general hasta que la demanda acumulada no alcance ciertas prioridades del negocio, el producto/servicio, aunque esté en producción, podría pasar un período sin capacidad asignada para trabajar en él pero contando como un producto/servicio encargado al equipo. Así pues, como contrapartida, debido a estas posibles fluctuaciones de capacidad y sin abusar de ello, un equipo podría estar encargado de varios productos/servicios sin que llegue necesariamente a un estado de saturación o degradación de desempeño.
  • Porque en niveles superiores de supervisión (unidades, departamento, etc.) la perspectiva es siempre multiproyecto. La dirección de la empresa puede apostar por el enfoque ágil y proporcionar el apoyo y confianza necesarias para el funcionamiento de los equipos, pero NO creo que renuncie a supervisar :-), al menos en cierta medida. Así pues, los niveles superiores deben contar con mecanismos para poder supervisar el conjunto de proyectos. 
Un contexto "demasiado" multiproyecto NO es una situación positiva para el equipo. La degradación del desempeño de un equipo puede ser similar a la ocasionada cuando a nivel de ítems en una actividad tenemos un WIP elevado. La recomendación general también sería similar, es decir, limitar la cantidad de proyectos entre los cuales el equipo debe distribuir su capacidad (y consecuentemente intercalar su dedicación), privilegiando terminar proyectos en lugar de abrir nuevos. Pero esto a nivel de negocio son cuestiones difíciles de evitar, y no suele ser la primera opción el incremento de personal :-).

Cuando la la empresa opta por asumir un contexto multiproyecto a nivel de equipos, no hay fórmulas mágicas para que pueda funcionar adecuadamente, la clave es que la dirección provea pautas respecto de la distribución de la capacidad de cada equipo, y que éstas estén alineadas con las prioridades del negocio. Cada equipo seguirá dichas pautas de distribución adaptándolas a períodos de tiempo. La siguiente figura ilustra una distribución de capacidad prevista y real para un equipo. En la figura se distingue entre asignación de capacidad (para trabajos en los cuales se realiza una planificación) y reserva de capacidad (para los trabajos que responden a demanda no planificable). Naturalmente, la demanda no planificada puede provocar cambios en la distribución real porque puede fluctuar requiriendo más o menos capacidad que la reserva prevista, y en ocasiones puede tener carácter urgente siendo ineludible su atención, cueste lo que cueste.


Llegando a este punto, podríamos optar por renunciar al agilismo en un contexto multi-proyecto :-), sin embargo, mi opinión es que es preferible considerarlo un obstáculo y enfrentarlo, sin dejar de acceder a los beneficios de las prácticas ágiles.

Nuestro Enfoque

Anecdóticamente, ya en 2005 cuando nos propusimos desarrollar una herramienta para apoyar la gestión ágil de nuestros proyectos, estábamos ya abordando una situación multi-proyecto, y en la primera versión ya intentamos integrar de forma homogénea todo el trabajo que tiene asignado un equipo. Incluso en esa época, sin aún conocer el método Kanban ni los tableros kanban, apostamos de forma natural por un multikanban, es decir, un tipo de tablero kanban que sintetizara todo el trabajo de un equipo, proporcionando filtros para conseguir una vista a nivel de miembro, producto/servicio, sprint y de proyecto.

El desafío de dicha visualización sintetizada tiene dos aspectos, por una parte los elementos involucrados, y por otra, las actividades del los diferentes workflows (representadas como columnas de los tableros kanban). La siguiente figura muestra los elementos que consideramos y que corresponden a opciones de filtrado en el Multikanban.


Un agente (miembro) participa en equipos. Un equipo tiene agentes. Un equipo está encargado de productos o servicios. Un producto o servicio tiene un Backlog (que contiene el trabajo pendiente priorizado y no incluido aun en sprints). Un producto o servicio tiene definidos sprints con trabajo que se ha movido desde el Backlog. En caso que un producto o servicio no trabaje con sprints (por ejemplo, porque su demanda no es planificable), todo el trabajo estará en el Backlog y directamente allí se abordará.

Pero ¿qué entendemos por Proyecto?. Las metodologías ágiles se enfocan en el producto o servicio que se ofrece como resultado al cliente. Por esto, es el producto o servicio el que tiene un Backlog y opcionalmente se desarrolla o atiende en sprints. Sin embargo, para nosotros el concepto de proyecto sigue siendo válido para representar un esfuerzo invertido durante un tiempo relativamente largo (varios meses), necesario por ejemplo, para desarrollar la primera entrega de un producto o la entrega de un nuevo módulo de gran envergadura. Así, mediante el concepto de proyecto podemos gestionar el alcance global de una entrega, aunque trabajemos con sprints de pocas semanas. Además, el concepto de proyecto nos ha permitido gestionar cambios simultáneos en varios productos, cada uno con su trabajo independiente, pero llevando una planificación y seguimiento global a nivel de proyecto.

La siguiente figura muestra una parte del formulario de inicio de Worki, la interfaz en la cual cada colaborador del equipo puede visualizar todo el trabajo no terminado en el cual participa.



En Worki pueden definirse diferentes workflows y luego asociarse a productos/servicios según sus necesidades. Es decir, en un mismo producto podemos tener ítems que pasan por diferentes actividades, algo que en un tablero kanban tradicional sería dificil de gestionar pues implicaría llevar en cuenta qué columnas son aplicables a cada ítem. En Worki, al crear un ítem se le asigna un workflow y el sistema se encarga de hacerlo pasar por las actividades que le corresponden (permitiendo decisiones de saltos atrás o hacia adelante cuando el agente lo estime conveniente). El tablero multikanban de Worki reúne todas las actividades de los ítems en los cuales un colaborador o equipo participa y no están terminados, es decir, no solo muestra el trabajo que en un momento determinado podría ser realizado por un agente sino que también le muestra el trabajo que está por llegarle, o que ya realizó y está ahora en manos de otros colaboradores. Esto elegantemente se diría como: "disponer de un buen Shared Situational Awareness" :-). Cuando una celda del multikanban tiene fondo azul, todo el contenido de dicha celda es trabajo asignado al colaborador seleccionado y ese trabajo ya está disponible para realizarse. Cuando la celda tiene fondo celeste, allí hay trabajo listo para realizar por el agente conectado o por otros agentes. Cuando la celda está en fondo blanco, todo el trabajo allí contenido está en manos de otros agentes. Además, cuando una actividad de un ítem no tiene preasignado un encargado, será vista como lista para realizar por todos los colaboradores que compartan el rol de la actividad, así cualquiera de ellos podrá acceder a ella y autoasignársela

Con los mecanismos descritos, con Worki podemos, de forma eficiente y sencilla, visualizar todo el trabajo en un contexto multiproyecto. Más aún, vemos de forma integrada el trabajo en productos o servicios que tienen distintas estrategias respecto de usar o no usar sprints, con situaciones diversas en cuanto a preasignación de agentes, o que requieren workflows específicos para cada tipo de ítem. Lectura recomendada respecto de workflows y su relación con tableros kanban: Workflows Flexibles Parte I y Parte II.

Patricio Letelier

No hay comentarios:

Publicar un comentario