« Tu veux les accès Jira ? »
C’est presque toujours l’une des premières questions. Cette fois, le CTO me la pose au bout de trois jours, surpris que je ne les aie pas encore demandés.
Un parcours d’activation important devait sortir au printemps. Depuis six semaines, il n’avançait plus.
« Pas encore », je réponds. Il sourit, sceptique. « Tu comptes diagnostiquer quoi sans Jira ? »
On m’avait décrit un problème de delivery. On m’avait donc préparé les suspects habituels.
Les tickets étaient trop gros. Les dépendances techniques étaient mal découpées. La roadmap changeait trop souvent. L’équipe manquait de capacité. Le travail avait été mal séquencé.
Chaque personne avait sa théorie. Et chaque théorie tenait debout.
Toutes désignaient le même endroit : le backlog. Le lieu où le travail est censé se voir.
J’ai commencé ailleurs.
Je ne commence pas par les tickets. Je commence par les personnes, les décisions et le temps.
Je regarde qui participe aux réunions consacrées au sujet. Et surtout qui n’y participe pas. Lorsque l’entrée, le traitement et la sortie d’un même parcours ne sont jamais représentés dans la même pièce, le sujet finit par être décidé en morceaux. Jamais dans son ensemble.
J’écoute ensuite les phrases qui commencent par : « Il faudrait voir avec… » Ce sont des balises. Chacune indique un endroit où une décision attend une personne absente, un périmètre flou ou un arbitrage qui n’a jamais été préparé. Trois « il faudrait voir avec » sur le même parcours, et on commence déjà à voir la carte du blocage. Sans avoir ouvert un seul ticket.
Je regarde aussi l’écart entre le statut officiel et la manière dont les équipes parlent du sujet lorsqu’elles ne présentent plus de slides. Dans le tableau, il est « en cours ». Dans les conversations, il est : « en attente d’une décision », « bloqué chez une autre équipe », ou « presque prêt, sauf que… » L’écart entre ces deux versions donne souvent une meilleure mesure du problème que le statut lui-même.
Ce qui bloquait réellement
Le sujet ne manquait pas de tickets. Il en avait des dizaines. Propres. Bien écrits. À jour.
Ce qui manquait, c’était une décision prise à l’échelle du parcours entier.
Une équipe possédait l’entrée. Une autre, le traitement. Une troisième, la sortie.
Chacune pouvait avancer sur sa portion. L’équipe d’entrée pouvait construire son écran. L’équipe de traitement pouvait développer sa logique. L’équipe de sortie pouvait préparer sa confirmation.
Mais aucune n’avait le périmètre nécessaire pour décider seule des compromis du parcours complet. Et personne n’avait rendu ces compromis assez visibles pour que les sponsors puissent réellement les trancher.
Alors le sujet vivait la seule vie qu’on lui laissait. Chaque équipe transformait sa partie en tickets réalisables. Elle avançait. Elle cochait. Vu de Jira, le projet bougeait. Vu du client, rien ne changeait.
Le backlog ne décrivait pas la raison du blocage. Il décrivait tout ce que les équipes avaient réussi à transformer en travail malgré lui.
Jira montrait l’activité. Il ne montrait pas la friction. La friction n’était pas un ticket en retard. C’était un ensemble de décisions que personne ne pouvait prendre seul, mais que personne n’avait encore préparées pour qu’elles soient prises ensemble.
Ce qu’on a fait
On n’a pas commencé par nettoyer le backlog. Cela aurait rendu le tableau plus lisible sans rendre le parcours plus livrable.
On a posé quatre choses.
D’abord, un résultat partagé. Formulé du point de vue du client, pas du point de vue de chaque équipe.
Ensuite, un propriétaire opérationnel du parcours. Pas quelqu’un chargé de décider à la place des sponsors. Quelqu’un chargé de tenir le problème dans son ensemble, de préparer les arbitrages et de s’assurer qu’ils soient effectivement pris.
Puis, on a sorti une liste courte des décisions qui bloquaient réellement. Elles se cachaient derrière les : « Il faudrait voir avec… » Pour chacune, on a rendu visibles : les options, les conséquences, les équipes concernées, et la personne qui devait trancher.
Enfin, on a défini un premier incrément que les trois équipes pouvaient livrer ensemble. Pas trois morceaux terminés séparément. Un premier changement observable sur le parcours complet.
Deux semaines plus tard, le sujet avançait de nouveau. Pas parce qu’on avait ajouté des personnes. Pas parce qu’on avait réécrit tous les tickets. Parce qu’il existait enfin : un résultat commun, un owner opérationnel, des arbitrages explicites, et une première livraison possible.
J’ai bien fini par ouvrir Jira. Mais à ce moment-là, je savais ce que je cherchais. J’ai pu confronter la trajectoire décidée avec le travail déjà engagé, retirer ce qui ne servait plus le résultat et remettre les éléments dans un ordre réellement livrable.
Jira était redevenu utile. Non pas pour nous dire pourquoi le sujet était bloqué. Mais pour organiser le travail une fois le blocage compris.
Quand un sujet n’avance plus chez vous, que regardez-vous en premier : les tickets, ou les décisions que les équipes attendent encore ?
Julien Brionne Senior Product Manager freelance.
