¿Se pueden gestionar dependencias con Jira? Yes, we can.

Seguro que a lo largo de tu vida profesional te has encontrado con bloqueos o retrasos en la entrega causados por falta de información, conocimiento, excesivo control o procedimientos. Todos ellos son una fuente de riesgo para el éxito de un proyecto, por lo que es fundamental identificarlos cuanto antes, para poder gestionarlos y evitar el mayor daño posible. Trabajar con frameworks Agile, como Scrum o Kanban, por su propia naturaleza, nos ayuda a mitigar este tipo de problemas a través de sus eventos, artefactos y roles, pero la gestión de proyectos de Software hoy en día es compleja y no todos los clientes están preparados. En este post cuento cómo la herramienta Jira me ha ayudado para su gestión.

Antes de profundizar, aclarar que, aunque este caso sea sobre un desarrollo de un proyecto de Software bajo metodología agile, las dependencias o tareas interrelacionadas existen en cualquier tipo de proyecto y hay que gestionarlas independientemente de si trabajamos con un gantt, pert o incrementos iterativos.

Lo único que me atreveré a decir es que en agile no solo se identifican y gestionan las dependencias, sino que también se busca cómo reducirlas (devops, pruebas ágiles, retrospectivas, pair programming/review, etc.).

Vamos a entrar en detalle a través de un caso real. Espero que mi experiencia te ayude ;)

Situación: equipo que acaba convirtiéndose en un escalado (dependencias internas)

Nos encontrábamos un grupo de personas realizando un proyecto de software para un cliente que cada vez adquiría mayor complejidad, por lo que el número de integrantes se fue ampliando hasta llegar a ser menos productivos.

Decidimos hacer subequipos y esto se tradujo en dependencias internas (no puedes escalar sin pensar en trabajar las dependencias. Esto no solo consiste en dividir equipos. Te recomiendo leer, del libro Agile 2, el capítulo “Agile 2 at Scale” en el que dicen que si tenemos equipos totalmente autónomos, en la construcción de un producto, no tenemos un producto, sino muchos productos pequeños).

El dividirnos en sí no fue el problema. La cuestión vino cuándo se empezaron a generar bloqueos entre los equipos debido a que no se hizo ninguna planificación o previsión de reposición, es decir, el problema vino por que los equipos no estaban alineados y trabajaban como entes independientes sin tener en cuenta las necesidades de los demás, siendo, que entre todos, estaban construyendo un mismo producto (es fundamental tener una visión u objetivo común para remar en la misma dirección).

Solución: Continuous Discovery y gestión visual del trabajo

Ante esta problemática de bloqueos hicimos 2 cosas: matriz de habilidades para encontrar cuellos de botella a nivel de conocimiento y una matriz de dependencias entre tareas a 1-2 sprints vista (3-6 semanas) para adelantarnos a los riesgos y hacer una planificación o priorización de tareas con estas dependencias en el centro.

Es fundamental que cuando un equipo empiece a desarrollar una tarea, esta tenga el mínimo número de dependencias posibles (si no conoces el término “Definition of Ready” te animo a investigar).

Para la matriz de dependencias utilizamos Jira Software (Atlassian) como herramienta:

1. Proyecto de Jira independiente

Partimos de la base de que cada equipo tenía su proyecto de Jira independiente (hubiera sido ideal tener un único proyecto con un único backlog y con la ayuda de componentes, etiquetas y filtros crear varios tableros de trabajo para tenerlo todo bajo el mismo paraguas peeeero, como bien dice uno de los principios de Kanban, empieza con lo que tienes) y por tanto cada equipo se administraba su propio backlog.

En este backlog, además de crear sus tareas de desarrollo, los equipos creaban tickets que representaban dependencias que tenían con otros. Para diferenciarlas del resto de issues/tickets las creaban de la siguiente manera:

• IssueType: dependencia (habla con el administrador de tu Jira si no tienes un issuetype que te ayude a diferenciarlas).
• Resumen: le añadían el prefijo “[Dep]” (estandarizar is good).
• Etiqueta: nombre del equipo “desbloqueador” (aquí pusimos la política de utilizar sólo una etiqueta tipo “Proy_Team_A”. No usamos los componentes por que eran utilizados internamente por los equipos para diferenciar roles como Front, Back, UX, QA, etc. Tuvimos el problema de que las etiquetas se pueden escribir de varias formas, por lo que hubiera sido mejor usar los componentes que son pre-escritos, pero nuevamente hay que adaptarse).
• Enlaces:
  • Enlazada a la Story o Task que bloqueara “blocks”.
  • Enlazada a la Task del otro equipo que la solventará “is blocked by”.

2. Tablero Kanban

¿Cómo se “pasaban” estas dependencias entre los equipos o cómo se avisaban de que tenían una dependencia? Creamos un tablero Kanban, llamado “transversal”, en el que. además de visualizar los riesgos y los bugs, veíamos las dependencias entre equipos (hicimos un filtrado general para que nos mostrase las issues de tipo “Dependencia” de los proyectos de Jira de los equipos y creamos carriles por sprint para visualizar cuándo debían ser resueltas estas dependencias. Conste que los equipos trabajaban con 2 o 3 sprints aterrizados por delante).

Una vez a la semana y siempre antes de que los equipos se fueran a organizar el trabajo, representantes técnicos y analistas se juntaban en una sesión de alineamiento con esta pizarra delante, para visualizar las dependencias que había y replanificar el trabajo de cada equipo para la siguiente fase o bloque de tiempo, ya que el Team_A podía pensar que iba a tener que hacer X cosas pero, tras esta sesión, se daban cuenta que iban a tener que hacer esas X más las tareas que ayudasen a desbloquear al Team_B, por lo que igual tenían que reducir sus X tareas (las dependencias de unos se convertían en tareas para otros. Te recomiendo este post sobre el dual track).

3. Dependencias resueltas

¿Cómo sabía un equipo que su dependencia había sido resuelta? Durante esta sesión semanal de alineamiento, no solo se hablaba sobre qué dependencias tenemos y cuándo necesitamos que estén resueltas, sino que también se hablaba de las dependencias en curso y de su estado (esto no quitaba qué hubiera conversaciones diarias si fuera necesario sobre su avance, ya que o solventábamos las dependencias con tiempo o corríamos el riesgo de tener que replanificar porque se iba a dar un bloqueo. Por cierto, te dejo este fantástico post sobre métricas con Jira).

Ejemplo

El Team_B había creado una dependencia, en su backlog, en el sprint 3 para que la solucionara el Team_A antes del sprint 4 que es cuando ellos realmente iban a abordar la funcionalidad. En la sesión de alineamiento es cuando el equipo A ve que, además de hacer sus desarrollos, el equipo B necesita solventar esa dependencia.

De esta manera el equipo A puede organizar su trabajo con tiempo, crear las tareas oportunas en su backlog, y decir a B si va a poder cumplir o no para que todos se reorganicen y se alineen las expectativas de proyecto y roadmap (es fundamental que, aunque cada equipo tenga un objetivo o goal independiente a cumplir por cada periodo de tiempo, los haya también a nivel conjunto).

En este backlogs de los equipos vemos como la dependencia del equipo B se ha convertido en tarea nueva para el equipo A.

En este tablero transversal vemos cómo se filtran solo las dependencias y podemos ver cómo al equipo A le han declarado una dependencia a resolver en el Sprint 3. Además, podemos ver a qué Story del equipo B está bloqueando y la nueva tarea que se ha creado el equipo A que le dará solución.

Conclusión: tablero transversal

Creamos un tablero transversal de gestión que, además de permitir visualizar las dependencias entre los equipos, ayudaba a la planificación y a la reducción del riesgo.

Lo único decir (por poner un pero a esta solución) que hubo que hacer una labor intensa de concienciación en todos los equipos sobre lo fundamental que era la actualización de los estados de las issues del Jira, ya que sin ello se perdía toda la visual del trabajo (como bien decimos en Paradigma “Ir un paso por delante, es cuestión de actitud. Nuestra proactividad va a marcar la diferencia”).

Extra

Esta solución se centró principalmente en visualizar dependencias internas dentro de un escalado de proyecto de software. Perfectamente se puede aplicar a cualquier tipo de proyecto mientras existan equipos interconectados, ya que permite tener una visión cross de qué necesidades tienen.

Además, permite priorizar objetivos de equipos en función del valor que aporten, es decir, las tareas prioritarias de un equipo a desbloquear por sus objetivos pueden no ser las tareas prioritarias a abordar por el otro equipo por sus objetivos, de ahí la importancia de que haya objetivos claves comunes o que haya una priorización que ayude a los equipos a saber qué camino seguir.

“Expect the best, plan for the worst, and prepare to be surprised”, Denis Waitley.

PD: Ahora estoy investigando sobre opciones de pago como Advanced roadmaps de Jira premium y Bigpicture. Ambos permiten hacer una gestión visual de las dependencias además de muchas otras cosas. Ya os contaré en un próximo post ¡Stay tuned! Mientras, podéis seguir profundizando en el tema con este ebook sobre gestión visual de la información.