Les dépendances entre équipes, ça coûte cher… Et c'est OK
C'est mieux d'en être conscient que de les ignorer 😉
Le fameux PI Planning. Chaque équipe construit sa roadmap. Et bien sûr, on identifie les dépendances.
Vous connaissez sûrement le célèbre exercice avec la pelote de laine rouge :
(Oui, rouge. Le folklore requiert d’utiliser du fil rouge 🤷
Par contre, la présence des chats n’est pas du tout habituelle 😂)
Ce travail autour des dépendances, c’est souvent ce qui est le plus apprécié par le management et les directeurs dans l’exercice du PI Planning.
Tout d’abord, il faut reconnaitre que c’est sacrément stylé, ce tableau avec des éléments dans tous les sens et tous ces bouts de ficelle qui se croisent. Si j’osais, je parlerais d’art.
Il y a aussi que cela permet de raccrocher les wagons avec une approche traditionnelle de la gestion de projet et le fameux Gantt, où l’on programme les différentes activités en tenant compte des dépendances.
Mais plus important encore : eh oui, dans un fonctionnement à l’échelle avec de nombreuses équipes, la gestion des dépendances c’est le nerf de la guerre. Car une mauvaise gestion des dépendances tue complètement le système, explosant le Lead Time pour accomplir les choses les plus triviales.
Les limites de la gestion des dépendances
Là où les dents grincent, notamment dans le monde des experts agiles, c’est que cet exercice du PI Planning avec son travail sur les dépendances est trop souvent pris avec cette vue abstraite du Gantt : comme s’il suffisait de décaler les choses et d’essayer de les faire dans un certain ordre pour que tout se passe bien.
Ou alors, on identifie que plusieurs groupes vont devoir travailler ensemble, alors on met en place des réunions récurrentes (souvent appelées “rituels”) et on se dit que ça va le faire sans chercher plus loin.
Tout ceci s’appelle gérer les dépendances, dans le sens de faire le nécessaire pour en réduire l’impact, pour réussir à vivre avec ces dépendances.
C’est bien sûr la chose à faire quand on ne peut pas faire autrement, par exemple lorsque deux équipes qui dépendent l’une de l’autre ne peuvent pas se passer de travail (souvent par manque d’expertise, chaque équipe étant l’experte de son domaine), et que des contraintes de temps forcent à trouver comment faire maintenant.
Mais cela devrait être la dernière chose à faire, l’option de dernier recours.
À la place, on devrait au maximum chercher à réduire les dépendances, soit donc non pas faire marcher la ficelle rouge mais bel et bien enlever la ficelle rouge.
Tantôt, il est question de changer la répartition du travail entre les équipes, pour limiter le ping-pong et faire en sorte que les équipes portent au maximum des sujets de bout en bout.
Souvent, ce n’est pas aussi simple. Par exemple il faut faire monter en compétences certaines équipes, recruter ou carrément réorganiser complètement les équipes.
Au-delà des compétences nécessaires pour mener à bien tel ou tel travail, il est également très possible qu’il faille restructurer le produit, aussi bien fonctionnellement que techniquement, afin de créer des Bounded Domains relativement indépendants et sur lesquels une équipe pourrait intervenir en autonomie.
Autant dire que ce type de travail ne se fait pas en claquant des doigts ! Et c’est sûrement là une autre raison pour laquelle ce travail de réduction des dépendances est si peu fait :
Parce qu’il faut se remonter les manches, il faut travailler dur et au niveau du système
Parce que cela nécessite de s’inscrire dans la durée, les changements d’ampleur se faisant petit à petit (et nécessitent potentiellement une conduite du changement)
Parce que ce n’est pas à la portée de tous, cela nécessite des compétences et expertises pointues
(ceci étant dit, franchement, si vous êtes motivés et que les 2 premiers critères ne vous font pas peur, je ne peux que vous encourager d’essayer et de monter en compétence en faisant ! 🙌)
Avant toute chose, ne pas ignorer les dépendances
Trop souvent, les grosses boîtes ont l’habitude de travailler avec des dépendances entre équipes. Les grands groupes s’accommodent le plus naturellement du monde des dépendances !
Cette attitude semblera révoltante aux structures à leurs antipodes : en environnement start-up où l’efficacité de la simplicité prime, comme une évidence. En start-up, on se dit que les dépendances, c’est la galère, structurons-nous pour les limiter !
Pour autant, les grands groupes ne sont pas inconscients du problème. Lors d’un événement type PI Planning, j’ai entendu récemment un discours d’une lucidité frappante : “vous avez des dépendances, identifiez-les comme des tâches à part entière, vous allez devoir vous synchroniser et faire le suivi, tenez-en compte.”
Oui ! Car le premier et plus grand risque est bel et bien d’ignorer une dépendance, en la laissant prendre le contrôle.
Ce risque est réel et j’ai apprécié cette lucidité lors de cet atelier.
Car si j’apprécie au plus haut point l’approche d’une start-up qui n’hésite pas à s’adapter et se restructurer pour réduire les dépendances, ce type d’environnement peut aussi très vite sous-estimer l’impact des dépendances en les laissant vivre leur vie, en les laissant pourrir tout le monde… Dynamique potentiellement renforcée par une culture omniprésente du héro, où chacun fait quotidiennement des efforts sur-humains pour porter le système à bout de bras. Et en apparence, tout fonctionne… Jusqu’au moment où tout explose.
À l’inverse, en grand groupe, j’apprécie le fait que l’on soit bien conscient que les dépendances amènent un surcoût… Mais je suis par contre mal à l’aise vis-à-vis du fait que la réflexion s’arrête là : on se contente de dire qu’il faudra y consacrer du temps ou de l’argent, sans remettre en question cette dépense même.
Ce n’est pas parce que l’on gère un problème qu’il faut accepter le problème !
TL;DR
Connaissez vos dépendances. Rien de pire que de laisser une dépendance sans contrôle.
Par contre, soyez bien conscient qu’une dépendance, ça coûte. Mettez les moyens nécessaires pour la gérer… Et réfléchissez activement à comment la réduire !
