Quand deux équipes s'attendent l'une l'autre : une histoire de dépendances
Un organisme public de taille moyenne déployait un nouveau portail de permis. Deux groupes portaient le travail : une équipe d'applications interne qui construisait l'interface, et une équipe de données qui montait la base de données des dossiers derrière. Sur papier, le plan était propre. En pratique, les deux équipes travaillaient à des étages différents, dans des fuseaux différents après le passage au télétravail, et avec deux outils de suivi distincts. Les noms et les dates ont été changés, mais la forme de cette histoire vous semblera familière.
Comment ça a bloqué
L'équipe d'applications supposait que l'équipe de données livrerait une API terminée d'ici la fin mars. L'équipe de données supposait que l'équipe d'applications enverrait d'abord les exigences de champs finalisées. Aucune de ces suppositions n'était écrite quelque part que les deux équipes pouvaient voir. Pendant trois semaines, chaque côté se croyait bloqué par l'autre et travaillait discrètement sur des tâches de moindre priorité. La première fois que quelqu'un a prononcé le mot « bloqué » à voix haute, c'était à un comité de pilotage, quand le commanditaire a demandé pourquoi la date de démonstration avait glissé. À ce moment-là, deux sprints étaient perdus.
Il n'y a eu aucune incompétence ici. Les deux équipes étaient occupées et compétentes. L'échec, c'est que la dépendance entre elles ne vivait que dans la tête des gens — et dans un cadre à distance et hybride, la conversation de couloir qui aurait capté cela n'a jamais eu lieu.
Ce qui l'aurait révélée plus tôt
Une dépendance est une promesse : une équipe s'engage à livrer quelque chose dont une autre a besoin, à une date, sous une forme définie. Le correctif consiste à rendre cette promesse explicite, visible et attribuée. Quelques habitudes font l'essentiel du travail :
Nommer la dépendance comme un engagement bilatéral. Écrivez qui a besoin de quoi, de qui, sous quelle forme et pour quand — et faites-le confirmer par les deux côtés, pas seulement l'équipe destinataire.
Lui donner un seul responsable. Chaque dépendance inter-équipes a besoin d'une personne nommée, responsable du transfert, du côté fournisseur. « L'équipe de données » n'est pas une personne.
La mettre sur une seule vue partagée. Un simple registre de dépendances ou un tableau partagé vaut mieux que deux outils séparés. Si une dépendance n'est pas visible par les deux équipes au même endroit, elle n'existe pas vraiment.
La revoir à une cadence courte. Un point hebdomadaire de 15 minutes entre les deux responsables, centré uniquement sur les transferts à venir et les dates modifiées, repère le dérapage tant qu'il reste du temps pour réagir.
La leçon de fond
Les dépendances inter-équipes sont l'endroit où les projets meurent en silence, parce qu'aucune équipe ne possède l'espace entre elles. Le risque est le plus élevé précisément quand les gens sont dispersés et que la coordination informelle s'est amenuisée. Vous n'avez pas besoin d'une gouvernance lourde pour gérer cela — vous avez besoin d'une liste partagée et honnête de qui attend quoi de qui, revue assez souvent pour qu'une date qui glisse soit remarquée en quelques jours, pas à la démonstration.
Faites de « je suis bloqué » une chose normale à dire tôt, pas un aveu d'échec.
Suivez les dates auxquelles l'équipe fournisseur s'engage, pas celles que l'équipe destinataire espère.
Quand une date bouge, suivez-la vers l'aval : le travail de qui vient de glisser à cause d'elle ?
Si votre livraison cale sans cesse aux jonctions entre équipes, le conseil en réalisation de programmes et de projets de XNM peut vous aider à rendre ces dépendances visibles et à les faire avancer.