Toma el control: estrategias para una gestión de dependencias activa.

Las dependencias no solo pueden dificultar el funcionamiento de una organización o el avance de una iniciativa, sino que pueden destruirlas.

A la hora de tratar una dependencia existen dos estrategias: la proactiva y la reactiva. La estrategia proactiva hace referencia a dedicar esfuerzos en identificar y planificar las dependencias. Y por otro lado, está la estrategia reactiva, que trata de responder a la dependencia una vez se manifiesta. Idealmente, una estrategia de gestión de dependencias debería tener un fuerte componente activo. La planificación proactiva es más eficiente y menos traumática que tener que reaccionar a problemas e improvisar. De esto trata este post.

Empecemos por el principio: ¿qué significa "dependencia" dentro de este post? Una dependencia es una necesidad que un equipo tiene sobre otro u otros y que tiene que resolverse para cubrir una necesidad funcional. Y como necesidad funcional, pueden entenderse desde un carrito de compra para una web, hasta necesidades más técnicas como pueda ser la disponibilización de un API o poner en producción una release. Y es que en el ejemplo del API, en definitiva lo que se está cubriendo es una necesidad funcional de un actor, aunque este “actor” no sea un ser humano, sino otro servicio.

¿Y por qué queremos gestionar dependencias? Pues porque las dependencias hacen que aumente la probabilidad de que un proyecto se retrase o incluso se cierre sin haber salido a producción. De hecho, una dependencia, por defecto, es un riesgo. Con mayor o menor probabilidad y con mayor o menor impacto, pero es un riesgo de que la iniciativa no se realice con éxito.

Transparencia

El primer paso es hacer que la dependencia sea visualmente obvia. Es decir, que cuando se visualice el trabajo a realizar, se vea claramente lo que son dependencias necesarias para avanzar y, de la misma manera, visualizar dependencias que bloquean a otros equipos. No subestimemos la importancia de visualizar el trabajo. De hecho, es una de las seis prácticas del Método Kanban. Esto es en lo primero que te tienes que enfocar para la gestión de dependencias.

Para ello, existen varias maneras de hacerlo. Hablaremos de cómo llevarlo a cabo con una de las herramientas de gestión de trabajo más extendidas: Jira.

Empezaremos por relacionar qué tareas tienen la dependencia a través del campo “enlace” de una incidencia (issue). Cualquier tipo de incidencia: Épica, Historia, Bug… Puedes usar las relaciones “bloquea” o “depende” si es una dependencia fuerte o blanda (respectivamente). Una dependencia fuerte es aquella que es necesaria resolver para empezar la tarea dependiente. Y una dependencia blanda es la que puede resolverse en paralelo con la tarea dependiente.

En muchos casos, por distintas razones, no existirá aún la tarea que resuelve la dependencia. En este caso se puede etiquetar la incidencia de alguna manera que ayude a visualizar la dependencia no relacionada. Una vez etiquetada, se podrá visualizar en un panel (dashboard), en el cronograma (roadmap), en la pila de trabajo (backlog) y en el propio tablero (board). Con esta información ya podrás visualizar lo que se llama una matriz de dependencias donde la vertical de la matriz son los equipos de tu organización o departamento, y la horizontal es una línea temporal.

En el mundo pre-covid se utilizaban más los paneles físicos para pintar estas matrices de dependencias. Ahora, que ya es más normal el trabajo remoto e híbrido, plugins de Jira como Advance Roadmaps (disponible en la versión Premium y Enterprise de Jira Cloud), Big Picture o Structure te ayudarán a visualizar estas matrices de dependencias.

Clases de reserva

En el momento que se consiga tener una visión holística de todas las dependencias, incluyendo no solo las de un proyecto o equipo en concreto, sino toda la estructura de equipos que puedan generar y resolver dependencias, se puede dar un paso más en la gestión de las mismas. Y esto es la gestión de dependencias basadas en las clases de reserva, que provienen del Método Kanban.

Las clases de reserva permiten asociar un nivel de servicio a cada una de las dependencias. Entenderemos clase de reserva como una forma de clasificar el trabajo dependiendo de la prioridad, urgencia o tiempos de entrega necesarios. Se parte de hacer el ejercicio de asignar la resolución de dependencias con fechas en un calendario. Se puede asociar resolución de dependencias a días, semanas o iteraciones, si es que los equipos trabajan en iteraciones de trabajo (como Sprints si trabajan con Scrum). Por ejemplo:

Las clases de reserva son 3:

• Garantizadas: capacidad de trabajo reservada para garantizar que, si surge la necesidad, se resuelva la dependencia en una fecha dada. Suelen ser, por tanto, tareas imprevistas.
• Reservadas: capacidad de trabajo ya asignada en el calendario para ser resuelta en una fecha dada. Suelen ser dependencias fuertes que evitan que otro equipo pueda empezar a trabajar.
• En espera: dependencia que será resuelta si hay disponibilidad de capacidad para abordarla. Normalmente son dependencias que pueden ser esquivadas provisionalmente hasta una fecha dada.

Estas clases de reserva se usan en la gestión interna de billetes de avión. Los billetes garantizados son espacios disponibles que sirven para asegurar que se puede viajar en el siguiente vuelo disponible, aunque con un precio muy elevado. Los reservados son los típicos y los en espera son los billetes más baratos pero es posible que te quedes sin entrar por overbooking.

Esto es lo que se llama un tablero de reservas. Una dependencia no tiene por qué ser siempre de una clase. Es posible que una dependencia empiece siendo de clase “En espera” y escale niveles por acercarse una fecha objetivo sin haber sido resuelta.

En este momento ya tienes una herramienta sobre la cual hacer inspección y adaptación de dependencias. El siguiente paso es disponer de un evento en tu proceso actual de trabajo en el cual hacer esta revisión de dependencias. No tiene por qué ser una reunión nueva, esta revisión puede ser añadida como punto dentro de la agenda de otra ya existente. Lo que sí es importante es que se revisen estando todas las partes involucradas que crean y resuelven dependencias. De esta forma, se coordinará el trabajo de manera más efectiva.

Dependencias “malas” y dependencias “buenas”

Igual aquí te explota la cabeza, pero las dependencias no siempre son malas. Existen las dependencias buenas y las dependencias malas. Siendo más estrictos, estas dependencias se llaman síncronas o asíncronas respectivamente.

Las dependencias asíncronas son aquellas que no ocurren al mismo tiempo. Ejemplos de este tipo de dependencias:

• Equipo que trabaja haciendo Scrum y quiere integrarse en su Sprint actual con el software definido en otra tarea que tiene que resolver un segundo equipo en otro Sprint.
• Equipo que realiza una petición de acceso a un recurso que necesita urgentemente para trabajar.

Por otro lado están las dependencias síncronas, que son las que ocurren en el mismo espacio de tiempo. Ejemplos de este tipo de dependencias son:

• Equipos que comparten un entorno de desarrollo y pruebas.
• Librería de software común a toda la empresa y abierta a que cualquier persona de desarrollo pueda mejorar su funcionalidad o rendimiento.

Este tipo de dependencias hacen que las personas dentro de una organización colaboren más de lo que lo harían si no existiese una dependencia entre ellas. ¿Qué pasa si dos equipos no colaboran? Que se crean silos. ¿Y los silos son malos? Pues bueno, entre otras cosas, fomentan que los individuos de un silo pierdan empatía con el resto de la organización o equipo y se pierda la visión global de la organización.

Entonces tenemos las dependencias buenas (sincronas) y las dependencias malas (asíncronas). Ya hemos visto cómo gestionarlas pero, ¿cómo podemos eliminar las dependencias malas? La estrategia está en conformar equipos que sean lo más autónomos posible en poner software a disposición del usuario final. Si conoces Team Topologies de Matthew Skelton y Manuel Pais, te sonará por la topología de equipo stream-aligned teams. Un equipo autónomo 100% está a cargo de inicio a fin, de un dominio de negocio o una porción del dominio, dentro de la organización.

Y es que el esfuerzo que conlleva a una organización a gestionar dependencias es inversamente proporcional a la autonomía de los equipos.

Más ejemplos sobre gestión de dependencias

Muchas organizaciones contratan servicios de consultoría para realizar componentes o funcionalidades que no pueden abordar y deciden externalizar porque piensan que la empresa que presta el servicio será autónoma. A posteriori, se dan cuenta de que existe una dependencia muy fuerte con su organización interna, pues necesitan acceso a distintos entornos, disponibilidad de ciertas personas de negocio, acceso a servicios,... Aquí es clave identificar estas dependencias desde el principio, planificar los esfuerzos que le conllevará a la propia organización y encontrar puntos de inspección y adaptación donde revisar estas dependencias.

Otro ejemplo son las dependencias funcionales a la hora de lanzar una release. Por ejemplo, una funcionalidad que depende de otra funcionalidad que debe proveer otro equipo y, por tanto, bloquea la release del producto dependiente. Pues bien, existe el concepto de toggle features. Toggle features es una técnica que permite activar o desactivar ciertas funcionalidades de una aplicación en tiempo de ejecución sin necesidad de desplegar código nuevo. De este modo se “eliminaría” esta dependencia que impide el despliegue de la aplicación.

Conclusiones

A lo largo del post se han hablado de conceptos que pueden parecer de “libro” y que puedes ver difícilmente aplicable en tu organización “porque tu organización es especial”. Es cierto que alcanzar el estadio perfecto es complicado y seguramente se necesiten puntos intermedios en el camino. Lo importante son los conceptos, que des el primer paso en ese camino y te dejes acompañar para garantizar tus probabilidades de éxito. En Rev by Paradigma ayudamos a revitalizar organizaciones a través de una gestión integral y sostenible, todo adaptado a cada organización.