sábado, 15 de junio de 2013

Multi-kanban, un tablero kanban para contextos multi-proyecto

Antes de empezar, es importante puntualizar que con "multi-proyecto" me refiero a la situación en la cual un equipo ágil (pequeño) está encargado de varios (muchos) proyectos. NO me refiero a "escalar agilismo", o cómo varios equipos pueden participar de forma coordinada en el trabajo asociado a un producto/servicio. 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 a cada área del producto/servicio. Recomiendo la lectura de un caso real descrito en Scaling Agile @ Spotify with Tribes,Squads, Chapters & Guilds.

Para una introducción a agilismo en contextos multi-proyecto recomiendo mis dos artículos anteriores Parte I y Parte II.

No existe un planteamiento consensuado respecto del agilismo 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 multi-proyecto no es un tema usualmente abordado en la bibliografía ágil de referencia (escrita por los gurús del agilismo). 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 multi-proyecto. 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 multi-proyecto, 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 multi-proyecto 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 seguirán teniendo demanda mientras estén en producción. 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 multi-proyecto. La dirección de la empresa puede apostar por el agilismo 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" multi-proyecto 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 multi-proyecto 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 multi-kanban, 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 Multi-kanban.


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 Planificador Personal de Tune-up, la interfaz en la cual cada agente o el equipo como un todo pueden visualizar todo el trabajo no terminado en el cual participa.



En Tune-up 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 Tune-up 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 Multi-kanban de Tune-up reúne todas las actividades de los ítems en los cuales un agente 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 agentes. Esto elegantemente se diría: "disponer de un buen Shared Situational Awareness" :-). Cuando una celda del Multi-kanban tiene fondo azul, todo el contenido de dicha celda es trabajo asignado al agente y preparado para realizar. 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 pre-asignado un encargado, será vista como lista para realizar por todos los agentes que compartan el rol de la actividad, así cualquiera de ellos podrá acceder a ella y auto-asignársela

Con los mecanismos descritos, con Tune-up podemos, de forma eficiente y sencilla, visualizar todo el trabajo en un contexto multi-proyecto. 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 pre-asignació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

viernes, 7 de junio de 2013

Desarrollo Iterativo versus Incremental ... o ¿cuál es la mejor estrategia para pintar la Mona Lisa?

Este post viene motivado por el debate iniciado por Agustín Villena en chileagil@googlegroups.com a fines de mayo de 2013. El debate se titula "Incremental versus Iterativo" y pone como referencia los siguientes posts: Don’t know what I want, but I know how to get it, por Jeff Patton (2008), y Revisiting the Iterative Incremental Mona Lisapor Steven Thomas (2012). En estos posts, como metáfora del desarrollo de un producto software se utiliza la elaboración del cuadro de la Mona Lisa. Suele ser un tanto engañoso usar metáforas para explicar conceptos de ingeniería de software, pues normalmente encierran siempre algún truco o interpretación forzosa :-). Sin embargo, como la exposición en dichos posts ya estaba dada en términos de dicha metáfora, continuaré con su utilización. A continuación se muestran las ilustraciones de los posts indicados antes. En cada caso la pintura se realiza en varios pasos numerados. Además, en cada ilustración se destaca el nivel de visualización previa del pintor respecto del cuadro que va a pintar.

Figura 1. Proceso Incremental según Jeff Patton 


Figura 2. Proceso Iterativo según Jeff Patton


Figura 3. Proceso Iterativo e Incremental  según Steven Thomas

En enero de 2010 Jeff Sutherland escribió un post replicando el post de Jeff Patton, titulado Iterative versus Incremental Development. En dicho post Jeff Sutherland descalifica la clasificación de Jeff Patton, diciendo que la Figura 1 (Proceso Incremental) simplemente muestra un enfoque "out of step" (alejado de la realidad), sin embargo, no juzga si es o no un proceso incremental :-). En el caso de la Figura 2, dice que NO es un proceso iterativo sino incremental. Jeff Sutherland interpreta que en la Figura 2 hay una intención de conseguir una versión potencialmente entregable del producto en cada paso. Como veremos a continuación esta consideración hace que un proceso se clasifique como incremental, es decir, un proceso puede ser iterativo (organizar el trabajo en iteraciones, llámense éstos sprints o pasos) pero, para que además sea incremental, debe existir la intención de producir una versión potencialmente entregable. En el caso de la Figura 3 de Steven Thomas, si bien presenta una mezcla de las estrategias de la Figura 1 y Figura 2, también es una cuestión de interpretación si en cada paso existe o no la intención de que el resultado que se obtenga en cada iteración sea un incremento potencialmente entregable.

Consecuentemente con lo anterior, en Scrum se establece que el resultado de un sprint (una iteración) es un incremento potencialmente entregable del producto ("potentially releasable product increment"), es decir, una versión que potencialmente podría pasarse a producción. El incremento es la suma de todos los ítems del Backlog completados durante un sprint y todos los sprints anteriores.

Por otra parte, Alistair Cockburn en el apartado de su web titulado Incremental versus Iterative Development proporciona otra perspectiva en cuanto a la definición de Iterativo y de Incremental. Incremental lo plantea como la estrategia que permite mejorar el proceso (desarrollar partes y luego integrarlas) e Iterativo lo plantea como el re-trabajo para mejorar el producto.

Según todo lo anterior, en mi opinión, queda claro que un Proceso Iterativo, apelando a lo básico, es un proceso donde se trabaja con ventanas temporales (llamadas usualmente iteraciones o sprints) en las cuales se lleva a cabo cierto trabajo sobre el producto. Un Proceso Incremental e Iterativo es un proceso en el cual el resultado de cada iteración es un incremento potencialmente entregable del producto. Pero quedaría por responder la pregunta del millón :-) ¿puede un proceso ser Incremental SIN ser Iterativo?. Mi respuesta es afirmativa, y mi argumento sería el siguiente (en la línea de Alistar Cockburn): si el producto se desarrolla en partes que se van integrando en cierto momento con la intención de hacer una entrega, pero sin utilizar iteraciones (o sprints), estaríamos en el caso de un proceso NO iterativo pero SÍ Incremental. Pondría como ejemplo la estrategia del método Kanban, el cual promueve la generación de un buen flujo de trabajo terminado, con entregas continuas pero sin trabajar con sprints (sin estimar ni planificar, y en su lugar centrarse en la priorización continua del trabajo pendiente). A propósito de este ejemplo, aprovecho para destacar que la decisión de un equipo respecto de usar o no sprints suele tomarse a través de una cuestión mal planteada, puesta en términos de la elección entre usar de forma excluyente Scrum o Kanban (lectura recomendada. ¿Kanban o Scrum? ... that is not the question).

Finalmente, en la metáfora de la Mona Lisa se diferencia entre pintarla teniendo una concepción previa del todo (Figura 1), o comenzar con una idea vaga, e ir definiéndola y ajustándola en cada paso (Figuras 2 y 3). En mi opinión este aspecto (el tener o no una idea preconcebida y detallada del resultado) no es extrapolable tan directamente a desarrollo de software. Es ampliamente reconocido que los requisitos suelen cambiar durante el desarrollo, tanto en términos de añadir o quitar requisitos, como en cuanto a modificar los requisitos originales. Con lo cual aunque se haga un esfuerzo importante por definir anticipadamente todos los requisitos, de todas formas se esperan cambios en ellos. Es por esto que, siguiendo la recomendación de uno de los 7 Mudas de Lean Development en cuanto a "no producir con demasiada antelación", los ítems en el Backlog no deberían ser definidos en mayor detalle hasta que no se acerque su implementación. Es decir, en el Backlog, podemos tener ítems con escasa definición o muy grandes (Épicas) que sabemos que necesitarán un trabajo previo antes de su implementación, pero, como asumimos que habrá cambios, no conviene anticipar su preparación hasta cuando sea inminente que se van a implementar. Una excepción a esto se daría cuando el contexto nos obliga a planificar con mayor antelación (por ejemplo, compromisos contractuales poco flexibles), y esto consecuentemente ejerce presión para anticipar una preparación y estimación más detallada.


Patricio Letelier