martes, 3 de noviembre de 2015

Tableros kanban. Parte II: Diseño de tablero kanban para aplicarlo con Scrum (desarrollo usando Sprints)

Scrum en su propuesta esencial (The Scrum Guide) no plantea mecanismos para visualización del estado de los ítems de trabajo, ni tampoco ofrece pautas respecto del flujo de trabajo (workflow) que cada ítem sigue desde que se crea hasta que se termina. Sin embargo, muchos equipos que aplican Scrum utilizan tableros para ilustrar el flujo de ítems a través de actividades, llamándolos Scrumboards o refiriéndose al uso de Scrumban como una mezcla de los métodos Scrum y Kanban. De hecho es el método Kanban el que hace muy populares los tableros kanban para visualizar el estado de los ítems de trabajo y para promover un buen flujo de ítems terminados. Es natural que al aplicar Scrum se complemente con algún tipo de tablero kanban, sin que por esto se tenga que aplicar otros elementos del método Kanban. Una cosa es el tablero kanban (o simplemente kanban) y otra es el método Kanban (con K, mayúscula).

En el post Tableros kanban. Parte I: Diseño básico para gestionar flujo de trabajo comenté algunas pautas para diseñar un tablero kanban cuando NO se trabaja con Sprints. Trabajar con Sprints o iteraciones, es decir, aplicar un modelo de proceso iterativo, es una de las prácticas ágiles más protagonistas de Scrum (y también de Extreme Programming) pero puede que no sea conveniente para un determinado contexto de trabajo (lectura recomendada Modelos de proceso para desarrollo ágil). Si el equipo recibe continuamente ítems de trabajo, éstos se van priorizando y abordando según dicha priorización, y en la medida que se terminan se van  entregando, en este caso probablemente trabajar con Sprint no es necesario. Es decir, al cliente le podría bastar con que le ofrezcamos un buen ritmo de entrega de ítems terminados. Sin embargo, cuando el cliente quiere establecer un compromiso más estricto respecto de plazos, alcance y/o costo los Sprints ofrecen el mejor mecanismo para el seguimiento continuo de dichas restricciones. Así, por ejemplo, un proyecto de 6 meses podría descomponerse en 8 Sprints de 3 semanas cada uno, teniendo la oportunidad de evaluar el avance del proyecto y gestionar su alcance al final de un Sprint y comienzo del siguiente, en la reunión de revisión del Sprint (Sprint Review Meeting) y la reunión de planificación del Sprint (Sprint Planning Meeting).

Un Sprint contiene un conjunto de ítems que se terminan entre las fechas de inicio y fin del dicho Sprint. Sin embargo, parte del trabajo requerido por los ítems de un Sprint usualmente se realiza antes del inicio del Sprint.

Cuando se usan Sprints las actividades aplicables a un ítem deberían ser básicamente las mismas que se aplican cuando no se usan Sprints. Sin embargo, como veremos más adelante, es de esperar que necesitemos algunas actividades adicionales.  A continuación se muestra el kanban del ejemplo que expliqué en la Parte I, respecto de cómo diseñar un kanban SIN usar Sprints.


En la Parte I de este post comenté mi recomendación respecto de incluir explícitamente dos actividades (columnas) en el extremo izquierdo del tablero kanban. En el ejemplo yo las he llamado "Introducir" y "Ordenar". La actividad "Introducir", una vez terminada, nos asegura que el ítem tiene la suficiente información para comenzar a procesarse. Esta información depende del contexto, pero podría incluir, por ejemplo: nombre, fecha de solicitud, quién lo solicita, importancia, riesgo, esfuerzo a priori, etc. Así, sin mayor inconveniente, cualquier posible trabajo aunque todavía no esté completo en sus datos básicos puede ya registrarse y mantenerse en "Introducir". La columna "Ordenar" nos asegura que todo ítem que posteriormente siga su procesamiento ha sido priorizado respecto del resto de trabajo no terminado. Los ítems se etiquetarán con un número de orden que debería seguirse en su procesamiento a través de las actividades del tablero kanban.

Usando el mismo ejemplo de flujo de trabajo (actividades por las que debe pasar cada ítem) veremos a continuación qué necesitamos añadir para poder trabajar con Sprints. Lo primero es reconocer que en cualquier kanban tenemos un grupo de actividades a la izquierda del kanban que se refieren a la preparación de cada ítem, y otra a la derecha que se encarga de ejecutar/implementar cada ítem. En la siguiente figura, y para nuestro ejemplo, se identifican ambos grupos de actividades correspondientes a Preparación y Ejecución de los ítems.

Al trabajar con Sprints lo ideal es que los ítems ya estén preparados antes de introducirlos al Sprint ya que así nos aseguramos que el contenido del Sprint se puede terminar en el plazo asociado al Sprint. En el ejemplo, durante su preparación los ítems se introducen, ordenan, y definen. Si se tienen ítems preparados, al establecer un compromiso de alcance para el próximo Sprint podremos tener mayor certeza que dicho compromiso es razonable en cuanto a esfuerzo involucrado y capacidad del equipo. Hay que destacar que en este caso, dentro de las tareas de la actividad "Definir", estaríamos incluyendo entre otras la estimación del esfuerzo asociado a la realización del ítem, normalmente en Horas Ideales o Puntos (Lectura recomendada: Estimación en un proyecto ágil). Si se considera necesario, podría promoverse la tarea de estimación como una nueva actividad (columna) en el tablero kanban. En nuestro ejemplo, yo no lo haré y asumiré que esa tarea está incluida en la actividad "Definir", es decir, que la tarea de estimación está en la "definición de Done" (las tareas-criterios para dar por finalizada una actividad) de la actividad "Definir" .

Scrum define dos tipos de contenedores de ítems el Product Backlog y el Sprint Backlog. El Product Backlog contiene todos los ítems que aún no se han incluido en un Sprint. El Sprint Backlog son los ítems contenidos en el Sprint, así cada Sprint tendría su propio Sprint Backlog. Para simplificar prefiero simplemente referirme al Product Backlog como "Backlog" y al Sprint Backlog como "Sprint". Así pues, en nuestro ejemplo el conjunto de actividades de preparación deberían idealmente realizarse cuando los ítems están en el Backlog y las de ejecución deberían realizarse cuando ya son incluidos en un Sprint, haciendo coincidir esos contenedores con el trabajo de preparación y ejecución respectivamemente, tal como se muestra a continuación.

En el caso de no trabajar con Sprints no sería tan relevante el concepto de Backlog, pudiendo asumir que el Backlog contiene a todas las columnas del tablero kanban, es decir, el Backlog simplemente sería el conjunto de todo el trabajo no terminado.

Una variante bastante popular en las herramientas que ofrecen soporte para tableros kanban es una en la cual no se reconocen actividades para los ítems durante el Sprint, sino que para cada ítem se define un conjunto de tareas técnicas que deben realizarse para darlo por terminado. Estas tareas pueden estar uno de los tres estados (columnas) elementales: To Do, Doing y Done. Así, al final del Sprint todas las tareas de los ítems del Sprint deberían estar en "Done". La siguiente figura ilustra esta variante de tableto kanban, que afectaría solo a los ítems que están dentro del Sprint.

No recomiendo esta variante porque supone mayor esfuerzo de gestión, debido a que además de gestionar los ítems de trabajo hay que gestionar las tareas asociadas a cada ítem dentro del Sprint. Por otra parte, trabajando con ítems relativamente pequeños (como debería ser lo habitual) no sería necesario hacer mayor descomposición de ellos.

Por otra parte, Scrum sugiere hacer coincidir el término de un Sprint con el comienzo del siguiente. Esto exige una buena disciplina de trabajo que permita llegar al final da cada Sprint con suficiente trabajo preparado para incluirlo en el siguiente Sprint y así poder iniciarlo de inmediato. Para conseguir esto lo recomendable es que a medida que se vaya extinguiendo el trabajo del Sprint actual se vayan dedicando esfuerzo en preparar los ítems candidatos para el siguiente Sprint.  En nuestro ejemplo esto significaría tener suficiente trabajo terminado en la actividad "Definir". Sin embargo, los ítems preparados no deberían pasar directemente a la columna "Programar", lo cual debe hacerse en el momento en el cual se inicia su Sprint. Así pues, surge la necesidad de una columna buffer que acumule los ítems preparados, candidatos para un Sprint aún no iniciado. El siguiente diseño de trablero incluye la actividad "Asignar Sprint" (o el nombre que se le quiera dar), desde la cual se cogerían los ítems que entran en el próximo Sprint.

Obviamente, no es necesario marcar en el tablero kanban los contenedores Backlog y Sprint como aparece en la figura, basta con que el equipo sepa cuales son las actividades que limitan el Backlog y el Sprint. En el ejemplo, "Asignar Sprint" es la última columna antes de comenzar el trabajo del Sprint. Así, al comenzar el Sprint deberían moverse los ítems seleccionados desde "Asignar Sprint" a la sub-columna To Do de "Programar".

Por último, a continuación comentaré algunas situaciones que suelen crear confusión al abordarlas en un tablero kanban, especialmente cuando se usan Sprints.
  • El Sprint ha llegado a su fecha de fin y no se han terminado todos los ítems. Hay varias opciones. La menos recomendable es extender el Sprint pues tal como sugiere Scrum, es importante conseguir una cadencia de trabajo y esto se favorece cuando los Sprints son de la misma duración. Dicho lo anterior, una mejor opción sería que los ítems no terminados podrían volverse al Backlog, a la columna "Asignar Sprint", reevaluando su prioridad (orden). Los ítems ya empezados y que podrían darse por terminados parcialmente (cuando la parte terminada pueda constituir un resultado de valor para el cliente) se terminarían pero se generaría un nuevo ítem con la parte restante del trabajo, el cual se pondría en "Asignar Sprint" reevaluando su prioridad (orden). El caso extremo de ítems ya comenzados, y que no se pueden dar por terminados parcialmente, deberían volverse al Backlog, pero en este caso deberían mantenerse en la columna actual (ya que, por ejemplo, se estaban programando o probando) porque ese es efectivamente su estado. Esta última es una situación excepcional en el tablero kanban pues el ítem está en una columna de Sprint siendo que se ha vuelto al Backlog. Sin embargo, bastaría con marcarlo notoriamente para que no se continue su trabajo hasta que vuelva a incluirse en un Sprint posterior.
  • Se han introducido en el Sprint ítems que no están totalmente preparados o tienen defectos en su preparación. De forma intencional se podría introducir un ítem en un Sprint sin haber hecho la preparación, por ejemplo, si se trata de un ítem urgente. En este caso el ítem estará asignado al Sprint actual pero aparecerá en columnas de preparación hasta que no se finalice su preparación (que se haría durante el Sprint).
  • Se detectan defectos de preparación en un ítem del Sprint. Cuando un ítem ya está en el Sprint actual y en alguna actividad, por ejemplo, Programar o Probar, se detectan defectos de preparación, por ejemplo, algún defecto en la definición del ítem. Si se trata de un defecto "grande" habría que volver el ítem a la columna correspondiente (en nuestro ejemplo "Definir") con una marca para identificar que se trata de re-trabajo y que posiblemente deba tratarse de forma prioritaria. Una vez resuelto el defecto habría que evaluar si el ítem debería volverse a la actividad desde la cual se volvió atrás o si debería pasarse a una actividad intermedia para realizar otros re-trabajos necesarios. Si el defecto es "pequeño" se podría mantener el ítem en la actividad donde se detectó el defecto y marcarlo para solicitar resolver de forma prioritaria dicho defecto (por ejemplo, se prodría re-Definir pero manteniéndo el ítem en la actividad actual).
  • Los ítems del Sprint se han terminado antes de la fecha de fin del Sprint. Siguiendo la recomendación ya indicada respecto de la regularidad de los Sprints lo apropiado sería añadir más ítems al Sprints de forma que se mantenga su fecha de fin.
  • Cuando se quiere establecer de antemano el contenido de todos los Sprints hasta el término del proyecto. Hasta ahora, el trablero kanban que hemos visto solo incluye el Sprint actual, el resto de ítems del proyecto estarían en el Backlog. Recomiendo firmemente no caer en la tentación :-) de pre-asignar todos los ítems a Sprints hasta distribuir todo el contenido del proyecto. Cuando se presentan cambios en cuanto a nuevos ítems, cambios en prioridad de ítems, descarte de ítems, etc. es muy molesto tener que re-establecer en cascada el contenido de los Sprints anticipadamente definidos. Pero además es problemático distinguir en un tablero kanban físico qué ítems están asignados a qué Sprints, pues el Backlog se reduciría prácticamente a las primeras columnas del tablero y el resto de columnas que usualmente serían del Backlog serían columnas donde habría ítems de los Sprints futuros. Si el interés es gestionar el alcance del proyecto debería bastar con tener señalados en el Backlog los ítems que se ha acordado que no están incluidos en el proyecto, por ejemplo, en la columna "Ordenar" indicar a partir de qué ítem (en la lista ordenada) ya no se considera dentro del alcance del proyecto. 
  • Si un ítem de trabajo es una épica (un ítem grande y/o complejo) y ocuparía gran parte de la capacidad del Sprint o incluso no podría terminarse antes del término del Sprint. Mientras el ítem esté lejos de ser incluido en un Sprint (por ejemplo, en más de un mes) no debería preocuparnos mayormente. Si por contrario ya estamos cerca de incluir la épica en un Sprint deberíamos estudiar cómo se abordará. Si la épica puede descomponerse en ítems bastante independientes (desde la perspectiva del cliente) esta sería una buena opción, con lo cual todo o parte de dichos ítems se incluirían en un Sprint, y el resto en otros. Si la épica es difícil de descomponer en ítems independentes pero es factible terminarla dentro de un Sprint, podría mantenerse como un solo ítem a costa de gestionar más colaborativamente su realización dentro del Sprint, por ejemplo, estableciendo que varios programadores o testers deben trabajar en conjunto en el mismo ítem. Sin embargo, mi opción preferida, es darle una "vuelta de tuerca" a la definición de la épica y plantearla como un desarrollo MVP, es decir, desarrollarla incrementalmente. Esto significa establecer un ítem como una primera mínima versión que se incluirá en un Sprint y mantener otro ítem en el Backlog (en la columna "Definir") con el resto del trabajo asociado a la épica. Una vez terminada esa primera versión, establecer otro ítem como una siguiente versión del ítem para el próximo Sprint, y así sucesivamente hasta terminar todo el trabajo asociado a la épica o hasta que la prioridad del ítem restante ya no esté entre lo que debería ser incluido en el siguiente Sprint, con  lo cual dicho trabajo restante debería esperar hasta alcanzar mayor prioridad.  
  • Cuando se quiere utilizar Sprints solo como agrupador de trabajo, es decir, "Sprints flexibles". Esto sucede cuando no existe un compromiso estricto con la parte cliente en cuanto a una fecha de fin de Sprint (o de entrega de versión de un producto), o cuando el contenido del Sprint puede modificarse durante el Sprint. Es decir, tenemos un buffer de tiempo y/o de ítems, pudiendo, sin mayor problema, pasar ítems no terminados al siguiente Sprint cuando ya se quiere dar por terminado el Sprint actual, o extender (o acortar) la duración del Sprint. Obviamente esta situación no ocurre cuando hay un contrato Precio Fijo entre cliente-proveedor :-). Pero en otros casos en los cuales el proveedor ofrece actualizaciones de su producto sin compromiso estricto de fechas ni de contenido con el cliente, estos "Sprints flexibles" suele ser la opción más apropiada. De todas formas, me reafirmo en la recomendación en cuanto a regularidad de los Sprints pues genera confianza al cliente, y puede ser especialmente interesante cuando los Sprints generan nuevas versiones de un producto que ya está en producción.
  • Cuando en el Backlog o Sprint hay ítems que siguen diferentes workflows. Una de los mayores limitaciones de un tablero kanban físico es poder gestionar ítems que tienen diferentes workflows, es decir, que las actividades aplicables son diferentes según el tipo de ítem. Cuando un tablero kanban incluye columnas aplicables que no son aplicables a un ítem, al desplazar el ítem éstas columnas deberían saltarse, lo cual puede llegar a ser complicado de manejar manualmente (pueden darse errores en el movimiento de los ítems). Lectura recomendada: Tableros kanban: ¿por qué recomiendo utilizar una herramienta en lugar de un "tablero kanban manual" y qué funcionalidades debería ofrecer?.
Como hemos visto en este post, la práctica del método Kanban que se refiere a la visualización del trabajo no terminado usando tableros kanban, y la práctica de Scrum respecto de realizar un desarrollo iterativo e incremental pueden aplicarse conjuntamente siendo complementarias. Aprovecho, como siempre :-), para insistir en que aplicar agilismo no es necesariamente aplicar al 100% un solo método ágil, sino que es aplicar prácticas ágiles en la mayor cantidad y profundidad posible, independiente del método ágil que provengan (lectura recomendada Carta de prácticas ágiles: Arma tu propio menú ágil).

En nuestro enfoque TUNE-UP Process y su herramienta de apoyo hemos abordado todas las características que he comentado en este post y que son necesarias para dar un buen apoyo para tableros kanban, trabajando con o sin Sprints. 



Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com


viernes, 11 de septiembre de 2015

Algunas anomalías en implantación de prácticas ágiles

La gestión ágil de equipos de trabajo es una clara tendencia en la industria. Este hecho en sí mismo está ayudando a impulsar el lanzamiento de nuevas iniciativas de implantación de prácticas ágiles. Sin embargo, la implantación del agilismo sigue siendo un gran desafío y el grado de éxito conseguido puede ser bastante variable.

Nota: en la literatura ágil el término más popular para referirse a la implantación de prácticas ágiles es "transformación (ágil)" y suele contraponerse a "adopción (ágil)" para enfatizar el hecho que se pretende llevar a cabo un cambio de fondo, no superficial. Sin embargo, aunque apuesto por dicha transformación ágil, yo prefiero utilizar un término menos elegante: "implantación de prácticas ágiles". La experiencia me ha demostrado que si bien la intención de cambio profundo (transformación) es lo ideal, una estrategia pragmática para conseguirlo normalmente conlleva la aplicación progresiva de prácticas ágiles (no todas a la vez), con posible aumento también progresivo de intensidad (más purismo en la aplicación de cada práctica) y posiblemente en convivencia con otras prácticas de ámbito más tradicional.

Con cierta frecuencia me he encontrado con algunas anomalías en la implantación de prácticas ágiles, ellas son:
  • Implantación "anecdótica". El comentario suele ser como el siguiente: "hicimos un proyecto de forma ágil, nos fue bien y hasta resulto entretenido, pero ahora seguimos trabajando como siempre". :-(.
  • Implantación "inconsciente": cuando se asegura que se está trabajando de forma ágil (incluso indicando un método ágil específico) pero se tiene muy poca argumentación respecto a qué prácticas se están aplicando y en qué nivel de intensidad, o cuáles prácticas explícitamente se han postergado en su aplicación, o cuáles simplemente se han descartado. Ser ágil implica estar aplicando prácticas ágiles, ¿cuáles o cuántas? ... eso ya es otra cosa, abierta a debate. Lectura recomendada: Midiendo (intentando medir) el nivel de agilismo
  • Implantación "limitada": cuando solo se ha implantado una o muy pocas prácticas ágiles, sin la intención de continuar con la iniciativa. Por ejemplo, muchos equipos se conforman con implantar un proceso iterativo e incremental para autodenominarse ágiles. El proceso iterativo e incremental es fundamental en Scrum y en Extreme Programming, pero ni es una exclusividad del enfoque ágil (la metodología tradicional RUP también sigue un proceso iterativo e incremental) ni tampoco es lo único que ofrece el enfoque ágil en cuanto a prácticas, el agilismo es mucho más que desarrollo iterativo e incremental. Es más, el proceso aplicado podría NO ser iterativo (como el propuesto por el método Kanban) y aún así ser totalmente válido como enfoque ágil.
  • Implantación "todo o nada": cuando un equipo trabaja algunos proyectos con enfoque ágil y otros con enfoque tradicional, de forma totalmente alternativa. Si bien existen prácticas excluyentes entre el enfoque ágil y el tradicional, no es muy sensato plantear el agilismo como un todo o nada. Hay muchas prácticas ágiles que podrían aplicarse de forma complementaria en un enfoque tradicional. Además, en general es inviable aplicar todas las prácticas ágiles a la vez, o al menos hacerlo en un plazo relativamente corto pues muchas prácticas requieren un esfuerzo de preparación considerable antes de su aplicación (por ejemplo, aplicar pruebas automatizadas).
El contexto de trabajo de un equipo está caracterizado por: su dinámica de trabajo y prácticas actuales, su experiencia en el dominio de los productos desarrollados, la relación con la parte cliente y en especial la relación contractual, el mercado objetivo, la tecnología y grado de innovación involucrados, etc. Para una implantacion exitosa es esencial conocer el contexto de trabajo y acorde a ello tener una estrategia de implantación de prácticas ágiles.

De nuestra experiencia en implantaciones durante estos últimos años hemos ido refinado una estrategia de implantación, la cual se concreta en nuestra Propuesta de Servicios de Implantación de Prácticas Ágiles.

Lecturas recomendadas:

viernes, 3 de julio de 2015

Midiendo (intentando medir) el nivel de agilismo

Obviamente ser ágil o no serlo no es una cuestión de todo o nada. Aunque en sus inicios el agilismo se planteaba (al menos por algunos) como "ser o no ser", incluso con un ánimo descalificador, a estas alturas debería estar más o menos claro que: por un lado ser idealmente ágíl es muy difícil, casi imposible e incluso a veces no imprescindible, y además, por el solo hecho de iniciar una evolución al agilismo, esto conlleva hacer convivir prácticas más tradicionales con prácticas ágiles.

Ser ágil además no es algo que esté claramente definido. Ver mi post ¿qué es ser ágil? ¿por qué debería interesar serlo?. Entonces ¿por qué podría interesarnos medir el grado de agilismo? :-). Medir nuestro nivel de agilismo, al menos de forma cualitativa, nos ayuda a comprender dónde estamos, es decir, conlleva un diagnóstico de nuestra situación actual. Cada vez escucho con mayor frecuencia equipos o empresas que se declaran ágiles o que dicen, por ejemplo, que están aplicando Scrum. Pero sin embargo no tienen ninguna argumentación muy clara respecto a qué los hace diferentes respecto a un enfoque tradicional, o a otro método ágil. Así pues, por el solo hecho de medir tu grado de agilismo te enfrentas a conocer y entender las prácticas ágiles que se están aplicando y en qué intensidad se aplican, además de identificar qué prácticas ágiles no conocías y/o no estabas aplicando. Esto es lo que yo llamo ser un agilista "consciente" de su nivel de agilismo :-).

En nuestro enfoque TUNE-UP Process tenemos un catálogo de 42 prácticas ágiles provenientes de los métodos agiles más populares (Scrum, Kanban, Lean Development y Extreme Programming). En el sitio Agile Roadmap+ ofrecemos un servicio gratuito para establecer un roadmap para implantación de prácticas ágiles, en el cual se ayuda a ordenar las prácticas que podrían irse implantando gradualmente en un contexto de trabajo. Ahora, como complemento, y basándonos en dicho catálogo de 42 prácticas hemos desarrollado un cuestionario para intentar medir el nivel de agilismo, lo cual constituye un primer paso, antes de elaborar dicho roadmap. La sola respuesta del formulario ayuda a conocer las prácticas ágiles allí utilizadas pues hay enlaces con explicaciones para cada una de ellas.

Encontramos bastantes iniciativas similares que pretenden medir el nivel de agilismo. La mayoría se orientan solo a un método ágil, y en particular a Scrum. Además, se limitan a hacer un conjunto de preguntas y medir el agilismo en términos de cantidad de respuestas afirmativas (que no necesariamente tienen correspondencia con métodos y prácticas ágiles), sin considerar el diferente protagonismo que pueden tener las prácticas ágiles en el contexto que se está midiendo el agilismo.

Nuestro cuestionario tiene dos perspectivas de medición. Una referente a medir el nivel de aplicación de grupos de prácticas, considerando cada grupo como una dimensión que podría ser interesante cubrir. La otra referente a dar un marco de importancia a práctica, es decir, puede que para un equipo una practica sea fundamental, pero para otro no sea tan interesante. Dicho marco lo ofrece la identificación y priorización de los objetivos del contexto de trabajo. Así pues, ya que en nuestro catálogo tenemos una correlación entre las prácticas ágiles y los objetivos que ayudan a cumplir cada una de ellas (junto con el nivel de contribución que aportan a un objetivo), podemos establecer una noción de aporte ágil de prácticas con respecto a cada objetivo establecido como más relevante.

Con el siguiente enlace se accede al cuestionario de evaluación:

http://agilismo.tuneupprocess.com

Al finalizar el cuestionario obtendréis por email un informe de la medición de nivel de agilismo de acuerdo con la información proporcionada. A continuación, a modo de ejemplo, se muestran las gráficas que se proporcionan como resultado de la evaluación. La primera corresponde a la medición de nivel de agilismo en grupos de prácticas y la segunda, el nivel de agilismo asociado al cumplimiento de objetivos.



Animáos a rellenar el cuestionario!!
  

Patricio Letelier


twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

miércoles, 24 de junio de 2015

Tableros kanban. Parte I: Diseño básico para gestionar flujo de trabajo

En el énfoque ágil, el tablero kanban es la técnica por excelencia para visualizar el estado del trabajo y promover el buen flujo del trabajo. Si bien esta técnica, de Taiichi Onho, se desarrolló en los años 50's y en el contexto de cadenas de montaje, actualmente se ha popularizado dentro de la comunidad ágil de la mano del método Kanban (de David J.Anderson), en el cual el tablero kanban es el protagonista.

Para que un tablero kanban resulte eficaz debe estar bien diseñado y deben estar claras las reglas del juego según las cuales el equipo interactúa con el tablero (algunas de ellas se traducen en decoraciones extra que se añaden al tablero o a los ítems de trabajo). En este post me centraré en el diseño básico del tablero kanban, orientado a visualizar el flujo de trabajo. En un próximo post abordaré el diseño y mecánica cuando además se trabaja con Sprints, en lo que se suele denominar Scrumban (combinando Scrum con tableros kanban) y aclararé el concepto de Backlog cuando se usa en el mmarco de un tablero kanban.

La siguiente figura muestra el tablero kanban en su diseño más simple.

Las fichas con letras representan ítems de trabajo. Las fichas van fluyendo desde la izquierda a la derecha. En el contexto ágil estos ítems deberían representar el resultado esperado (o parte de él), tal como lo solicita el cliente. Las columnas "Pendiente" (To Do), "En Proceso" (Doing) y "Terminado" (Done) representan el estado del ítem de trabajo. Si el procesamiento que se hace de un ítem (en la columna "En Proceso" es muy sencillo y atómico (cuando básicamente se realiza una sola actividad para darlo por terminado) nos bastaría este diseño de tablero kanban. Sin embargo, si por el contrario para procesar el ítem se aplican varias actividades sobre él nos gustaría tener mayor observabilidad respecto de la actividad en la cual se encuentra el ítem en un momento determinado. Es decir, en estos casos quisiéramos reemplazar la columna "En proceso" por un conjunto de columnas que ofrezcan mayor observabilidad del proceso y permitan localizar en qué actividad específica se encuentra el ítem. Por lo tanto en este caso necesitamos hacer explícito el proceso que aplicamos a un ítem para darlo por terminado. El planteamiento es similar al de definir un procedimiento que seguiremos para abordar nuestro trabajo, es decir, lo que hacemos cuando establecemos nuestros workflows de trabajo. Sin embargo, en el caso de kanban lo acotamos a un diseño de proceso secuencial, ya que columnas contiguas representarán actividades consecutivas. Es decir, no consideraremos explícitamente operadores de paralelo (no representable directamente en un kanban) o de selección, ni tampoco añadiremos detalles respecto de roles, puntos de sincronización, mensajes, etc., elementos típicos en notaciones tales como BPMN. Debido en gran parte a su notación tan reducida es que los tableros kanban se han popularizado pues son suficientes para gestionar la mayoría de las situaciones de proceso que suelen presentarse.

Siendo minimalistas, podremos coincidir en que para cualquier típo de ítem podríamos tener que realizar al menos 3 actividades para darlo por terminado: Definirlo, Ejecutarlo y Probarlo. Por ejemplo, en el ámbito de desarrollo de software estas actividades podrían llamarse: Definir (D), Programar (P) y Probar (T). Ellas se muestran a continuación:


Es importante destacar que dentro de una actividad pueden realizarse varias tareas, cada una de ellas podría convertirse en actividad (una columna independiente) pero mientras no se justifique, es preferible tener menos actividades (columnas), aunque entro de ellas se realicen varias tareas.

Correspondientemente un tablero kanban que incluya las actividades indicadas antes podría ser el siguiente:


No es el propósito de este post el explicar o recomendar la mecánica de interacción con el kanban, pero en esencia, tal como comenté antes, la idea es que los ítems fluyan de izquierda a derecha hasta terminarse, y a un buen ritmo pues eso significará que estamos terminando parcialmente (incrementalmente) el trabajo que nos solicita nuestro cliente. Dependiendo del ámbito de trabajo pueden existir saltos de actividades (columnas), tanto hacia adelante como hacia atrás (en casos de re-trabajo por detección posterior de defectos o que el trabajo no está completo).

Cada ítem de trabajo podría tener un kanban diseñado específicamente para él. Sin embargo, es obvio que si ciertos ítems de trabajo son procesados de forma similar, tengamos un kanban para todos esos ítems de trabajo. Por ejemplo, en un ámbito de desarrollo de software los ítems suelen ser de tipo: Nuevo Requisito, Mejora o Corrección de Fallo y aunque se trate de diferentes típos de ítems, todos requieren básicamente el mismo procesamiento, aunque quizás con diferente intensidad. Por ejemplo, una Corrección de Fallo puede que no requiera tanta definición como una Mejora o un Nuevo Requisito. Sin embargo, si por el contrario hay ítems de trabajo que tienen un procesamiento particular, convendría que tuviesen su propio tablero kanban, puesto que si mezclamos ítems con diferentes procesamiento en un mismo kanban el equipo de trabajo debe tener muy presente qué actividades deben aplicarse a unos ítems o a otros, saltándose las actividades que no deban ser aplicadas a un ítem. Por contraparte, para una gestión integrada siempre es preferible tener menos tableros kanban, especialmente si se trata del mismo ámbito de trabajo, con lo cual si solo existen pequeñas diferencias de procesamiento, basta con identificar la o las columnas que podrían ser opcionales o no aplicables a un determinado tipo de ítem. Pero también deberíamos considerar si tenemos diferentes líneas de trabajo. Una línea de trabajo puede ser un producto en desarrollo, un servicio ofrecido al cliente, o una agrupación de ítems asociados a un proyecto). En términos de gestión resulta más sencillo tener un kanban para cada línea de trabajo (auque tengan tipos de ítems con procesamiento similar), ya que de esta forma nos evitamos tener que introducir decoraciones (por ejemplo colores para ítems) que ayuden a distinguir en un mismo kanban ítems de diferentes líneas de trabajo.

Un nivel adicional de detalle que resulta interesante es poder conocer si un ítem en una actividad está pendiente, en proceso o terminado. Es decir, lo mismo que nos planteábamos de forma global en el kanban más simple mostrado antes, pero ahora visto a nivel de actividad. De manera que pudíesemos, por ejemplo, saber qué ítems están pendientes de Programar, los que ya se están Programando y los que se han terminado de Programar pero aún no se han pasado a Testear. Como vemos en la siguiente imagen, si aplicamos este detalle a cada actividad de procesamiento se produce solape entre el Done de una actividad y el To Do de la siguiente. Por eso, lo que hacemos es fundir esas dos subcolumnas en una sola. Dado que normalmente al finalizar una actividad se sabrá si es necesario pasar el ítem a la siguiente columna o si conviene saltarse ciertas columnas, prefiero que las dos subcolumnas solapadas se fundan en el To Do de la siguiente.


Así, haciendo dicha fusión de subcolumnas, nuestro kanban de ejemplo quedaría como se muestra a continuación.


Adicionalmente, existen dos situaciones comunes que conviene considerar:
  • Cuando ya se ha identificado la necesidad de realizar un cierto ítem pero aún nos falta información para dar comienzo a su procesamiento (incluso puede que dicho ítem finalmente se desestime). En mi experiencia, me ha resultado efectivo tener una actividad llamada "Introducir" en la cual aseguro que un ítem que finaliza esta actividad tiene la información suficiente para empezar a ser procesado (la que se determine en el contexto), además en esta actividad se revisa si el ítem está repetido o tiene solapes con otros ítems.
  • Cuando un ítem ya está listo para ser procesado pero debe evaluarse su prioridad respecto del resto de ítems que aún no se han comenzado a procesar. Nuevamente, mi experiencia me confirma la conveniencia de incluir siempre una actividad llamada, por ejemplo, "Ordenar". Se trata más bien de un búffer de contención para evitar que se comience a procesar un ítem que no es el más oportuno realizar en dicho momento. Hay que establecer la prioridad, o mejor dicho, hay que determinar el orden de procesamiento de los ítems, pues no es solo una cuestión de importancia del ítem. Para esto deberían considerarse diferentes criterios y de su evaluación obtendríamos una posición (orden) de procesamiento para cada ítem. Lectura recomendada: Gestión eficaz del Product Backlog. Además, dicho orden debería intentar respetarse durante el procesamiento del conjunto de ítems. En esta columna "Ordenar" se acumularían todos los ítem que aún no se empiezan a procesar (tengan o no tengan orden) y periódicamente se ordenarían los último en llegar y que no tengan aún orden. Así, pasar un ítem de To Do a Doing en esta columna "Ordenar" implica intercalar el ítem en la posición que le corresponda entre los ítems que ya están en la subcolumna Doing (es decir, asignarle un orden respecto a todos los ítems todavía no procesados). En esta actividad los ítems se mantendrían en Doing hasta que no se decidiera comenzar a procesarlos (pasándolos a To Do de la primera actividad de procesamento).
 Estas dos columnnas (por ejemplo, llamadas: "Introducir" y "Ordenar") reemplazan a la columna "Pendiente". Por lo tanto, la versión final de nuestro ejemplo quedaría como se muestra en la siguiente imagen:


Me gustaría insistir en que lo recomendable es comenzar a aplicar tableros kanban de forma minimalista, menos tableros y con menos actividades (columnas). Algunas sugerencias al respecto:
  • Cada línea de trabajo podría tener su propio kanban pero si estamos en una situación multi-proyecto hacerlo con kanban físicos esto puede resultas complicado, puede que nos falten paredes donde poner todos los tableros :-). En estos casos mejor es utilizar desde el principio algún software.
  • Si actividades consecutivas las realiza la misma persona y siempre una inmediatamente después de la otra quizás sea mejor fusionar dichas columnas en usa sola. Por contraparte, aunque se trate de una misma persona que realiza dos tareas dentro de una actividad (columna), pero dichas tareas no se realizan una tras otra inmediatamente y se quiere saber en qué tarea está un ítem, podemos promover dichas tarea a actividades, es decir, dividir la actividad original en dos (dos columnas).
El éxito de la implantación de un tablero kanban depende en gran medida de que esté "vivo", que esté actualizado y refleje el estado del trabajo del equipo. Esto debe conseguirse con la participación de todos los miembros del equipo, no es recomendable que existan "encargados de actualizar el kanban", cada miembro del equipo debe mover el ítem cuando comienza o finaliza la actividad correspondiente. Algunas recomendaciones que ayudan a mantener un kanban "vivo":
  • Hacer reuniones frecuentes de puesta en común del trabajo del equipo, realizadas frente el kanban. Scrum y Extreme Programming recomiendan una reunión diaria de 15 minutos y de pié (las denominan Daily Scrum y Stand-up meeting, correspondientemente), lo ideal es realizar esta reunión en semicírculo frente al kanban.
  • Usar alguna decoración para indicar quién está trabajando en un determinado ítem. Por ejemplo, poner un avatar que representa a la persona trabajando en el ítem.
  • Si los ítems pasan días o semanas en una actividad el kankan no mostrará cambios y esto restará interés por verlo. Puede que la mayoría de nuestros ítems tienda a ser Épicas (ítems muy "grandes"). En este caso se podría intentar dividirlos (teniendo cuidado de no dificultar la gestión puesto que los ítems resultantes de la división podrían ser muy dependientes entre sí) o hacerlos incrementalmente, identificando un item por el cual se comenzará a trabajar y dejando como otro ítem el resto del trabajo. Otra posible causa de la poca movilidad de ítems en el kanban es que en algunas actividades se estén haciendo demasiadas tareas, con lo cual podría evaluarse si conviene promover algunas de dichas tareas como actividades (columnas), cuando por ejemplo, son realizadas por diferentes personas o en distintos momentos.
  • Si bien en un principio un kanban físico (montado en una pared con post-it) da un buen impulso en cuanto a motivación, ya que conlleva algo de bricolaje y esto resulta entretenido, hay bastantes limitaciones que luego se pueden volver en contra de la sostenibilidad de dicha motivación y actualización del tablero. Más pronto que tarde sugiero pasar a utilizar un tablero soportado por alguna herramienta software. Sin embargo, al hacer esa transición debe asegurarse que el tablero físico, como punto de reunión, sea reemplazado por una pantalla (ojalá de grandes dimensiones).
A continuación tenéis una lista de otros posts que he escrito con temas asociadas a tableros kanban:
Puedes continuar leyento la segunda parte de este post: Diseño de tablero kanban para aplicarlo con Scrum (desarrollo usando Sprints).



Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

lunes, 22 de junio de 2015

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