La nouvelle lubie : ne pas vouloir de framework
Comme toujours, la réalité n'est pas binaire et est pleine de compromis
Cela fait consensus parmi les “bons” agilistes : pour “bien” accompagner une équipe ou une organisation, il ne faut pas déployer un framework tel quel mais plutôt adapter les choses.
C’est un discours que j’ai pu porter moi-même, comme cela a pu être promu dans certains épisodes de Scrum Life. 1
Dans cet article, je viens remettre ce point de vue en question. A minima, le nuancer.
Voici la question à laquelle on va tenter de répondre :
Vaut-il mieux du custom ou du standardisé ?
Du custom pour la meilleure performance…
Là où je suis d’accord, c’est qu’en effet construire un mode de fonctionnement adapté au contexte d’une équipe ou d’une organisation c’est ce qui permettra d’en tirer le meilleur niveau de performance.
Voici les atouts d’une approche custom par rapport à une approche standardisée :
Conduite du changement plus facile en partant de l’existant, en tenant compte au maximum de la réalité actuelle
Développement plus efficace du mindset en impliquant les personnes dans la découverte de la bonne approche, menant ainsi à une meilleure pérennité du changement
Eviter l’écueil de vouloir appliquer des pratiques qui ont généralement du sens sauf dans le cas précis de l’équipe
Plus largement, ne pas tomber dans la bureaucratie, les vanity metrics ou encore le cargo cult
Mise en place naturelle de pratiques atypiques ou innovantes, qui émergent du contexte et des besoins spécifiques de l’équipe ou de l’organisation
Bref, on construirait de meilleurs modes de fonctionnement, de manière plus fluide et plus pérenne, en évitant les pièges du faux agile.
Super, non ? Alors pourquoi envisager de faire autrement ? 😏
… mais à quel prix ?
Sauf que…
Admettons que ce custom soit mieux. La question qui se pose juste après, c’est : à quel prix ?
Là où le standardisé tire son épingle du jeu, c’est quand on passe à l’échelle, quand on est dans une grande organisation et que l’on doit adresser un ensemble de départements et d’équipes. On n’a alors jamais les moyens d’avoir, par exemple, un expert agile dédié à chaque équipe pendant plusieurs années.
En voulant faire du custom dans ce type de contexte, on serait alors obligé de choisir entre :
Accompagner tout le monde en même temps… Mais on n’a pas la bande passante de le faire bien. Les experts se retrouvent alors à devoir accompagner chacun de nombreuses équipes en même temps. En s’y prenant ainsi, on n’arrivera pas à générer les gains promis par l’approche custom : pas assez sur le terrain pour en observer la réalité, pour être pertinent et pour former en faisant ensemble. ❌
On peut alors se dire de se focaliser sur certaines équipes uniquement, en les accompagnant par contre au mieux. On est alors sensé générer les gains promis par l’approche custom, sauf que… Seulement sur certaines équipes. Quid des autres ? Au final, on a des gains mais que sur quelques équipes. Est-ce que l’on considèrera que le ROI est suffisant ? Sans même parler des équipes qui ne sont pas accompagnées, qui peuvent se considérer comme abandonnées sur le bord de la route, et qui deviendront certainement les premiers détracteurs de la démarche. ❌
Bien sûr, l’option précédente était simpliste. On va donc faire tourner l’accompagnement : on se focalise sur certaines équipes pendant quelques mois, puis on s’attèle à d’autres, et ainsi de suite. Le risque ici est que tout s’effondre lorsque l’on s’en va : il faut donc réussir à ancrer les apprentissages et les nouvelles manières de faire avant de tourner. Pas évident du tout en l’espace de quelques mois. 😬
Dans tous les cas, on sent bien que l’approche custom coûte simplement trop cher pour être efficace.
Avoir des résultats visibles rapidement pour assurer le financement
D’un point de vue comptable, une initiative de transformation est comme n’importe quelle autre initiative, et un centre d’expertise est comme n’importe quel autre département :
On les finance initialement parce qu’on croit dans le business plan qui justifie que cela va apporter plus à l’organisation que cela ne va coûter.
Puis on continue de les financer parce que les faits le démontrent, ou du moins nous font le penser2
Voici donc l’injonction contradictoire de toute transformation : il faut du temps pour avoir des résultats profonds et pérennes, mais il faut des résultats rapides pour avoir l’opportunité de rentrer dans un temps long.
Faire du custom c’est prendre le risque de ne pas avoir suffisamment d’impact, suffisamment rapidement, pour pouvoir appliquer la démarche partout.
Et c’est pourquoi, en remettant les choses dans le contexte du financement des initiatives et de la gestion de budget des grandes organisations, le standardisé est en réalité on ne peut plus logique, du moins dans un premier temps.
Du standardisé pour des premiers gains à l’échelle
Prenons le contrepied de l’approche custom pour présenter l’approche du standardisé.
✅ Avec du standardisé, on peut assez facilement adresser un ensemble d’équipes ou de départements avec un nombre limité d’experts.
Bien sûr, tous les arguments évoqués plus haut en faveur de l’approche custom tiennent toujours. Ce sont autant de challenges que l’on va se prendre en pleine face.
Peut-être même que l’on créera un certain nombre d’environnements où il se passera exactement ce qui hérisse le poil des agilistes : du grand n’importe quoi où l’agilité est dévoyée et appliquée comme de la bureaucratie.
Mais forçons-nous à prendre un peu de recul, à réfléchir comme un gestionnaire ou comme un entrepreneur, plutôt que comme un contributeur individuel qui subit tout cela.
L’enjeu de l’approche custom est de générer des systèmes hautement performants. 💎
L’enjeu de l’approche standardisé est de pouvoir être appliquée à l’échelle, sur de nombreuses équipes ; on sait très bien qu’on fait de la 💩, sauf que comme on part de très loin, c’est déjà une amélioration. On ne vise pas la meilleure performance d’une équipe donnée, on vise un peu d’amélioration partout, ce qui est beaucoup plus significatif au global.
Avec, encore une fois, cette nécessité de démontrer que la démarche sert à quelque chose pour lui permettre de continuer d’être financée.
Conclusion
Toutes choses prises en compte… Le succès des frameworks dans les grandes organisations n’est pas surprenant. 🤷
Et ce n’est pas parce que ces grandes organisations seraient remplies de gens feignants, incompétents ou carriéristes. Bien au contraire : parce que c’est en fait la seule voie qui a une chance de marcher, du moins dans un premier temps.
On peut notamment citer cette interview d’Emilie Esposito qui mettait en avant une approche #NoFramework, et qui reste complètement pertinente et d’actualité :
Cela peut sembler être une nuance, mais c’est en réalité assez important à saisir : pour décrocher un budget, il faut que les personnes prenant la décision de l’allouer y croient.
Les faits ne sont que des arguments pour y faire croire ; des faits, aussi irréfutables soient-ils, peuvent ne pas convaincre.
À l’inverse, des arguments superficiels peuvent convaincre, et ce même s’ils sont fallacieux.
Attention, je ne suis pas ici en train d’encenser la manipulation. Néanmoins, il me semble important d’être bien conscient que la perception de l’impact que l’on peut avoir ne repose pas uniquement sur l’impact que l’on a effectivement eu.




« sauf que comme on part de très loin, c’est déjà une amélioration. »
La réponse elle est un peu là aussi, sans savoir d’où on part difficile de choisir entre du custom et du prepackagé. C’est pour ça qu’il est toujours important d’auditer fréquemment les systèmes pour savoir comment adapter les cadres de travail.
J’aime beaucoup l’idée de remettre de la nuance sur ce sujet qui prend effectivement pas mal de place aujourd’hui ! :)
La manière dont tu décris l’approche « custom » m’a fait penser à Kanban : partir de l’existant en impliquant les personnes dans la démarche de trouver la bonne manière de faire.
Je trouve que Kanban nous invite à transformer les choses de cette façon, en commençant par visualiser l’existant et prendre des décisions sur cette base là pour s’améliorer.
Alors même qu’il serait probablement catégorisé « framework standard » pour bcp ☺️