Un projet agile bloque quand personne n’a le droit de refuser

Une réunion de deux heures vient de se terminer. Sept personnes ont parlé, trois demandes ont été défendues, et personne n’a dit laquelle passerait en premier. L’équipe repart avec la même liste qu’en arrivant, plus une. La semaine suivante, elle travaille sur la demande de celui qui parle le plus fort.

Ce n’est pas une méthode mal appliquée. C’est une décision sans titulaire. Tant que personne ne peut refuser une demande, l’ordre du travail se décide à la voix, et le résultat sert à moitié.

Ce qui bloque n’est ni l’outil ni le rythme

Les entreprises de moins de cent personnes appliquent souvent l’agilité avec sérieux. Elles ont un tableau de suivi, des points hebdomadaires, des cycles de deux semaines. Rien de tout cela ne manque.

Ce qui manque tient en une fonction : l’arbitrage. Une demande arrive, il faut choisir entre elle et une autre, et ce choix n’appartient à personne. Alors il se disperse. Le commercial obtient sa fonctionnalité parce qu’il a appelé le dirigeant. Le support obtient la sienne parce qu’un client s’est plaint. L’équipe exécute les deux, en retard sur les deux.

L’image est celle d’un restaurant avec une seule cuisine et trois salles qui commandent en même temps. Sans un responsable de salle qui décide de l’ordre de service, chaque salle crie plus fort que sa voisine. Le cuisinier travaille beaucoup et sert mal.

Ce que la méthode exige d’une seule personne

Scrum est le cadre le plus répandu. Un cadre, ici, est un squelette de rôles et de rendez-vous fixes : il organise le travail, il ne décide pas du contenu.

Le guide de référence, publié en novembre 2020 par ses deux auteurs, Ken Schwaber et Jeff Sutherland, tient en quelques pages. Il confie une responsabilité précise au responsable produit, appelé Product Owner : rendre maximal « la valeur du produit issue du travail de l’équipe ».

Le même texte ajoute quatre précisions qui rendent le rôle non négociable. Le responsable produit peut déléguer le travail, mais il « reste redevable ». Il est « une personne, pas un comité ». Ses décisions se lisent dans l’ordre de la liste des demandes. Et, pour qu’il réussisse, « l’organisation entière doit respecter ses décisions ».

Le guide va plus loin sur un point que beaucoup ignorent. Seul le responsable produit a le pouvoir d’annuler un cycle en cours. Pas le dirigeant, pas le client, pas le responsable technique. Cette clause existe pour une raison simple : arrêter un cycle est une décision de valeur.

Un cycle, dans ce cadre, s’appelle un sprint. C’est une période d’un mois au maximum, souvent deux semaines, à la fin de laquelle quelque chose doit être utilisable. La liste ordonnée de tout ce qu’on pourrait faire s’appelle le backlog.

En PME, ce rôle tombe presque toujours sur la mauvaise personne

Dans un grand groupe, le responsable produit est un métier. Il a un supérieur, des objectifs, du temps. Dans une PME, ce métier n’existe pas encore, et le rôle se donne par défaut.

Trois attributions reviennent. Le dirigeant le prend parce qu’il connaît le client et l’argent. Un chef de projet le prend parce qu’il parle aux deux côtés. Le client le prend parce qu’il paie.

Les trois se trompent de la même façon. Le dirigeant est en réunion toute la journée : il signe l’ordre des demandes une fois par mois, et le reste du temps, c’est l’urgence qui décide. Le chef de projet n’a le pouvoir de personne : il transmet. Le client, lui, décide de tout, mais il ne voit ni le coût ni la technique.

Ron Jeffries, signataire du manifeste agile et praticien de longue date, a décrit ce mécanisme en septembre 2016. Il écrit qu’en pratique, « il n’y a parfois même pas de responsable produit côté métier. Et quand il y en a un, il n’a probablement pas été formé à ce rôle ».

Il donne un ordre de grandeur. En septembre 2016, les organismes de certification comptaient 388 000 Scrum Masters certifiés, c’est-à-dire des personnes formées à faire vivre le cadre, contre 82 000 responsables produit certifiés. Il en déduit que près de 80 % des équipes travaillent sans responsable produit formé.

Ce n’est pas une enquête de terrain, c’est une soustraction sur des compteurs de certification. Elle indique une proportion, pas une mesure exacte. La direction du constat reste juste : la personne qui décide n’est presque jamais formée à décider.

Le responsable produit boîte aux lettres

L’arrangement le plus fréquent en PME porte un nom : le relais. Une personne fait le lien entre ceux qui demandent et ceux qui construisent. Elle collecte, reformule, transmet, et rapporte les réponses.

Le guide autorise la délégation du travail. Il ne permet pas de déléguer la décision, puisque la responsabilité reste sur la même tête. Un relais qui n’arbitre pas n’est donc pas un responsable produit. C’est un facteur qui distribue le courrier sans pouvoir ouvrir une enveloppe.

Le symptôme apparaît à la fin du cycle. La revue de fin de cycle devient une démonstration. L’équipe montre trois écrans, le dirigeant dit que c’est propre, personne ne retire rien de la liste, et deux demandes neuves arrivent dans la semaine.

Le guide dit pourtant l’inverse, en une phrase nette : la revue est « une séance de travail », et l’équipe « doit éviter de la limiter à une présentation ». Une séance de travail veut dire que les participants manipulent le produit, posent des questions, et repartent avec une liste modifiée.

Christiaan Verwijs, Johannes Schartau et Barry Overeem ont donné un nom au résultat visible de cet écart : le Scrum zombie. C’est quelque chose qui ressemble à Scrum de loin. Sur place, aucun logiciel utilisable ne sort du cycle, les parties prenantes ne viennent pas, et l’équipe dispose de peu de marge de manœuvre.

La deuxième cause n’est pas une réunion

Il existe une seconde cause, documentée elle aussi, et elle ne se règle dans aucune réunion. Martin Fowler l’a décrite en janvier 2009 sous le nom de Scrum mou.

Son constat : des équipes adoptent les pratiques Scrum, parfois les principes, et la progression ralentit quand même. La raison n’est pas le rythme. C’est l’état interne du logiciel, devenu difficile à modifier. Chaque nouvelle fonctionnalité coûte plus cher que la précédente.

Fowler précise que Scrum est « centré sur les techniques de gestion de projet » et qu’il omet « délibérément les pratiques techniques ». Ce n’est pas un défaut caché. Le cadre ne dit pas comment écrire le logiciel, il dit comment décider quoi écrire.

Pour un dirigeant, la conséquence est directe. Des cycles courts ne créent pas la dette technique, ils la rendent visible plus vite. Une équipe qui livre toutes les deux semaines expose son rythme réel. Un projet de dix-huit mois peut cacher le sien jusqu’à la livraison.

Trois décisions à écrire, un chiffre à suivre

Le remède ne demande pas d’outil. Il demande trois écrits, chacun tenant sur une ligne.

Premier écrit, un nom. Une personne, pas un comité, avec le droit de refuser. Si c’est le dirigeant, bloquez deux heures par semaine dans son agenda et traitez-les comme un rendez-vous client. Un rôle sans créneau n’existe pas.

Deuxième écrit, la règle d’arbitrage. Que se passe-t-il quand une demande urgente arrive au milieu d’un cycle ? Le guide autorise une réponse nuancée : la portée du cycle « peut être clarifiée et renégociée avec le responsable produit » à mesure que l’on apprend. Écrivez qui appelle qui, et sous quel délai la réponse tombe. Cette règle évite les deux extrêmes, tout figer ou tout accepter.

Troisième écrit, la sortie de la revue. Trois questions, trois réponses écrites, à chaque fin de cycle. Que garde-t-on ? Que retire-t-on ? Qu’est-ce qui change dans l’ordre de la liste ? Quarante-cinq minutes suffisent si la démonstration en dure dix.

Le chiffre à suivre est celui-ci : le nombre de revues terminées sans décision écrite. L’objectif est zéro. Il se mesure sans outil et se compare d’un mois à l’autre.

Ce qu’il faut retenir

• L’agilité ne rate pas d’abord à cause de la méthode. Elle rate quand personne n’a le droit de refuser une demande.
• Le guide Scrum confie cette décision à une seule personne, le responsable produit, et demande que toute l’organisation respecte ses décisions.
• En PME, ce rôle est souvent donné au dirigeant déjà pris, à un chef de projet sans pouvoir, ou au client. Dans les trois cas, il n’est pas exercé.
• Une revue de fin de cycle limitée à une démonstration ne produit aucune décision. Le guide demande une séance de travail.
• Nommez une personne, écrivez la règle d’arbitrage, terminez chaque revue par trois décisions écrites. Comptez les revues sans décision.
• Une deuxième cause est documentée : la qualité interne du logiciel. Des cycles courts la révèlent plus vite, ils ne la créent pas.