sábado, 11 de abril de 2020

Organización ágil del trabajo: Parte II - Dos dimensiones del trabajo

En este post ilustraré la variedad de alternativas para la organización ágil de una Línea de Trabajo. El concepto de Línea de Trabajo se refiere a un Backlog  (conteniendo el trabajo que hay que hacer) + su Product Owner + su Equipo, encargado de realizar dicho trabajo. Así pues, en un cierto contexto de trabajo podrían existir múltiples Líneas de Trabajo, cada una con una organización del trabajo diferente según sus necesidades.

La organización ágil de trabajo tiene dos dimensiones: Dimensión Contenedor del Trabajo y Dimensión Proceso del Trabajo. En la Dimensión Contenedor del Trabajo por defecto siempre tendremos el Backlog, que es una lista ordenada de Unidades de Trabajo (UT, o llámense ítems o Historias de Usuario). En la Dimensión Proceso del Trabajo tendremos al menos un tablero kanban que refleja el workflow con el cuál abordamos el trabajo. En la siguiente figura se muestra el caso por defecto, tenemos un Backlog y el tablero kanban más simple (To Do, Doing, Done).
La clave está en entender que una UT estará en una determinada posición del orden del Backlog y al mismo tiempo estará en algún estado/actividad del tablero kanban. En la figura se observa que la UT se color naranja está en la parte alta del Backlog (más cerca de terminarse) y en el tablero está en el estado Doing.

Las UT se irán terminando en el Backlog de acuerdo a su orden desde arriba hacia abajo, y las siguientes irían subiendo. Debería existir algún mecanismo para ocultar/mostrar las UT terminadas pues el foco debería centrarse en las UT no terminadas y más prioritarias. Las nuevas UT que lleguen deberían posicionarse en el Backlog compitiendo en prioridad con las ya existentes.

En la siguiente figura se ilustra el caso en el cual el tablero kanban refleja un proceso más detallado que ofrece mayor observabilidad del estado de cada una de las UT. En este caso, por ejemplo, la UT naranja estando en el Backlog como contenedor, al mismo tiempo está en la actividad Diseñar.
En los dos casos anteriores el trabajo se centra en generar un buen flujo de trabajo terminado y siguiendo el orden asignado a las UT, de acuerdo a las prioridades establecidas por el Product Owner. No hay fechas comprometidas para el término de las UT, pero podrían asignarse puntualmente fechas límite para algunas de ellas y hacer un seguimiento al respecto para mantenerlo coherente con el orden asignado a la UT.

Veamos ahora un caso en el cual la Línea de Trabajo tienen regularmente unos compromisos de entrega de UT terminadas. En este caso convendría utilizar Sprints que representan períodos de tiempo (recomendación de no más de un mes de duración), es decir, tienen una fecha de inicio y fin. Si se ponen UT en un Sprint se asume que el esfuerzo asociado a su realización es coherente con la Capacidad del equipo para dicho período. La siguiente figura ilustra el caso en el cual además del Backlog se usan Sprints.
En este caso un conjunto de UT se mueven desde el Backlog al Sprint en el cual se va a ejecutar el trabajo asociado hasta terminarlas. Nuevamente, en este caso tanto si una UT está en el Backlog como si está en un Sprint, al mismo tiempo estará en algún estado/actividad del tablero kanban. Cuando se utilizan Sprints, es importante distinguir dos grupos de estado/actividades en el tablero kanban; columnas de "preparación" de las UT, donde se define con suficiente detalle la UT, y columnas de "ejecución" de las UT, que corresponden al trabajo que se hará dentro del Sprint hasta  terminar la UT. De esta forma la correcta preparación de las UT permite tener una estimación adecuada para establecer el esfuerzo asociado. En este caso la columna "Esperar Sprint" establece dicha división del tablero en "preparación" y "ejecución". En Esperar Sprint se acumulan las UT que ya están preparadas para incluir en un Sprint. En este ejemplo, las actividades Programar y Aplicar Pruebas de Aceptación corresponden al trabajo de ejecución de las UT durante el Sprint.

Aunque podría definirse con anticipación el contenido de UT de varios Sprints futuros no es recomendable, pues los cambios en el contenido de Sprint previos repercutirán en el contenido de Sprint futuros para mantener coherente su relación entre esfuerzo y Capacidad del equipo. Así pues, se sugiere definir el próximo Sprint y cuando se esté agotando comenzar a definir el Sprint siguiente.

Finalmente, en el caso de requerir un seguimiento más detallado de un conjunto de UT que se realizarán durante un período más largo es conveniente asociarles un Proyecto para tener un seguimiento global de las UT.  Pero en este caso también puede ser interesante utilizar Sprints para el seguimiento a corto plazo. Backlog, Sprint y Proyecto son así tres contenedores que se podrían utilizar en conjunto. Una UT estará o no dentro del alcance del Proyecto, y podrían estar en el Backlog o en algún Sprint. En la siguiente imagen se muestra como el Proyecto actúa como contenedor adicional de UT que pueden estar en un Sprint o en el Backlog antes de ser incluidas en un Sprint.
La gestión de alcance del Proyecto se realizaría asociando o no las UT al proyecto. Así, en un Sprint podría haber UT del Proyecto y otras no pertenecientes al Proyecto. Lo mismo pasaría en el Backlog, donde se marcarían las UT que pertenecen al proyecto.

En este punto del post toca pasar la cuña de publicidad de nuestra herramienta Worki :-), la cual hasta donde sé es la única donde se apoya adecuadamente esta doble dimensión de la organización del trabajo. En Worki, cada Línea de Trabajo puede incluso tener asociados varios tableros kanban en caso que se apliquen diferentes procesos a distintos tipos de UT. En Worki aunque las Líneas de Trabajo tengan diferente organización (en cuanto a uso o no de Sprints y/o Proyecto, o se utilicen diversos workflows) se ofrece una visualización integrada de todo el trabajo. Esto se ilustra en la siguiente figura que corresponde a la interfaz de arranque de Worki.


En Worki se ofrecen múltiples vistas de la información facilitando la gestión en contextos multiproyecto o de varios equipos de trabajo, y quizás con personas trabajando en varios equipos. Por ejemplo, en la siguiente figura se muestra un tablero kanban asociado a la información mostrada en la figura anterior.  


En este post también espero haber dejado una vez más en evidencia que no es una buena idea el enfrentar métodos ágiles, promoviendo el uso de uno u otro de forma alternativa. Hemos visto cómo, cuando es conveniente, pueden usarse Sprints (proceso iterativo propuesto por los métodos Scrum y Extreme Programming) junto con un tablero kanban (la esencia del método Kanban). Con lo cual no se trata de aplicar de forma exclusiva Scrum o Kanban (o cualquier otro método ágil), lo sensato es aplicar las prácticas ágiles que nos ofrecen los diferentes métodos, aquellas que sean convenientes para la Línea de Trabajo, e intentar aplicarlas con la mayor profundidad posible. Lectura recomendada: ¿Kanban or Scrum? that is not the question. Si a la organización ágil de Línea de Trabajo le llamamos Scrum, Kanban u otro nombre, eso es un asunto de simplificación, al cual no vale la pena darle más importancia, solo daría para discusiones puristas infructuosas :-).


Patricio Letelier

www.tuneupprocess.com 




jueves, 20 de febrero de 2020

Ecualizador de prácticas ágiles, sintoniza la agilidad de tu equipo de trabajo

De vez en cuando conviene volver a comentar los fundamentos del enfoque ágil, especialmente cuando comprobamos que ser o no ser ágil parece algo bastante difuso o al menos poco consensuado :- ). Hace tiempo ya publiqué un post llamado "¿Qué es ser ágil? ¿por qué debería interesar ser ágil?" en el cual doy mi opinión al respeto. En este post quiero ilustrar con el "Ecualizador de prácticas ágiles" una forma sencilla y visual para mostrar el nivel actual de transformación ágil en un determinado contexto. Ser ágil no es un "todo o nada", más bien es estar en un cierto nivel de agilidad.

Para la explicación utilizaré el catálogo de prácticas ágiles de nuestro enfoque Agile Roadmap, el cual incluye 42 prácticas ágiles provenientes de los 4 métodos ágiles más populares: Scrum, Kanban, Len Development y Extreme Programming. Este catálogo se muestra en la siguiente figura, en la cual dichas 42 prácticas se ubican en los métodos correspondientes. Resulta evidente que existen ciertas prácticas exclusivas de unos métodos pero también bastantes compartidas, además de 4 prácticas fuera de dichos métodos pero que también considero útiles.


De esta figura se constata que aplicar en exclusiva un método ágil no parece ser lo más conveniente pues se estarían descartando prácticas que también podrían ser útiles. Es decir, una transformación ágil no debería estar restringida a un determinado método, lo importante son las prácticas que podrían representar una oportunidad de mejora en el contexto donde se van a aplicar, independiente del método ágil del cual provengan. Según esto, podríamos parafrasear "Talk is cheap, show me the code" por "Talk is cheap, show me the agile practices" :-). Básicamente en AgileRoadmap proponemos un sencillo modelo para ayudar a iniciar una Transformación Ágil (o reconducir una ya iniciada). Dicho modelo se basa en evaluar los objetivos que interesa conseguir, las prácticas que pueden contribuir a ello y los desafíos que podría conllevar la implantación de dichas prácticas. Con lo cual, lo que conseguimos en AgileRoadmap es visualizar el estado de agilidad de un contexto de trabajo y según eso tomar decisiones respecto a incorporación o intensificación de la aplicación de ciertas de prácticas ágiles. La metáfora de esta evaluación es un ecualizador de prácticas ágiles como el que se muestra a continuación. 


El ecualizador ilustra el nivel de aplicación de cada práctica ágil. Según el contexto y los objetivos de mejora que interesen, la selección de prácticas que deberían aplicarse o intensificar su aplicación son aquellas que más contribuyan a cumplir dichos y que presentes unos desafíos que sean factibles de superar. Cada contexto de trabajo (equipo, línea de trabajo, proyecto, producto, etc.) podría tener su propio ecualizador pues sus objetivos de mejora, la diversidad de su trabajo y las formas de gestionarlo pueden ser diferentes.

En conclusión, ser ágil indudablemente es estar alineado con los valores del Manifiesto Ágil, pero esto, llevado a terreno debe manifestarse en aplicar prácticas ágiles, mientras más y con mayor intensidad mejor pues más significativa será la mejora.


Patricio Letelier

www.tuneupprocess.com