Ce n’était déjà pas facile : tantôt à poser et renforcer le cadre, tantôt à donner la vision et à déléguer.

Mais dans l’ensemble, devenir manager voulait dire ne plus être contributeur individuel, ou alors de manière ponctuelle, par exemple en tant que backup lors d’une absence dans son équipe.

Ces dernières décennies, des changements majeurs ont complexifié le rôle de manager. En particulier :

• Une économie moins favorable, plus compétitive, qui nécessite d’optimiser plus le temps de chacun, à être plus efficace

• De nouvelles générations, en écho aux différents changements sociétaux, pour qui l’autorité du chef n’est nullement acquise, et à qui le manager doit démontrer sa légitimité

Le rôle de manager est pris en tenaille entre une direction qui demande plus de résultats avec moins de moyens, et des collaborateurs qui demandent à leur manager de faire ses preuves au-delà de la posture.

Bref, être manager veut dire rester doer.

En soi, cela apporte son lot de bonnes choses. Cela permet de s’assurer que le ou la manager garde les pieds sur terre et reste pertinent auprès de son équipe. Cela lui permet aussi de prendre une posture collaborative avec l’équipe. Cela rend aussi on ne peut plus naturel de montrer par l’exemple.

Par contre, cela rend d’autant plus difficile de déléguer. Cela renforce cette phrase qui trotte toujours dans la tête des managers : “si je le fais moi-même, ça ira plus vite, et en plus je serai sûr que c’est bien fait !”

L’un dans l’autre, cela me donne envie d’utilise la fameuse expression du “mouton à 5 pattes” pour désigner ce qui est attendu des managers : leader inspirant, coach qui fait grandir son équipe, garant du cadre et des enjeux de l’entreprise, responsable qui explicite… Et contributeur au quotidien !

Bon courage à tous les managers 💪

Cela arrive naturellement, soit parce que ces compétences sont vues comme alien, nécessitant des profils spécifiques, avec des modes de fonctionnement bien à eux, ou parce que des éléments de gouvernance s’en mêlent — le premier étant bien entendu la cybersécurité.

Pour autant, tous les signaux ne pointent pas dans cette direction. C’est pourquoi il est normal de voir diverses initiatives qui prennent forme au sein des départements métiers ; des initiatives historiques, qui datent d’avant cette DSI, comme des initatives récentes, où l’on pourrait presque avoir l’impression que la DSI est ignorée.

Bien sûr, quand cela arrive, les explications sont multiples :

• La DSI est considérée comme inefficace, trop lourde, trop coûteuse… Ou tout simplement on n’a pas confiance dans la qualité de ses livrables. Logique, dans ces conditions, que les métiers cherchent des alternatives.

• Il peut aussi y avoir des dynamiques très humaines : on aime encadrer directement les personnes qui font le travail.

  • Parfois, ce sont pour de mauvaises raisons : un besoin de contrôle.

  • D’autres fois, ce sont pour de bonnes : il n’y a en effet pas plus agile que des développeurs directement intégrés dans le quotidien des métiers, dans le même bureau et en échange direct.

• Une perception que la DSI est là pour des sujets techniques que l’on ne comprend pas. On veut bien envisager que ce soient des choses nécessaires et pour lesquelles il faille donc payer, mais on ne les comprend pas pour autant. Donc, quand il est question d’adresser un sujet dont l’impact sur le business est direct et clairement compris, on ne se dit pas que c’est à la DSI de s’en charger, car, “c’est un sujet métier”. (sous-entendu : contrairement à ce que fait la DSI)

Pour couronner le tout, l’IA amplifie ça ! Il est désormais possible d’enclencher des chantiers d’envergure pour bien moins cher, rendant la DSI comme une alternative encore plus coûteuse et inefficace en comparaison. On voit aussi de plus en plus de métiers s’emparer eux-mêmes du sujet, que cela soit via des applications Low Code / No Code ou même via du Vibe Coding.

Se pose donc naturellement la question :

Quel positionnement devrait prendre une DSI ?

En soi, il n’y a pas de mauvaise option.

Il y a des bénéfices ainsi que des problèmes à gérer, autant dans une démarche de centralisation que dans une démarche de décentralisation.

Dans les faits, il est même habituel, et en réalité normal et désirable, de suivre un cheminement un peu chaotique entre ces deux extrêmes :

• Pour explorer, expérimenter et trouver ce qui fonctionne le mieux

• Parce que le contexte change au fil du temps, et ce qui correspondait aux enjeux métiers ainsi qu’à son organisation à un moment donné n’est plus le même quand ces enjeux et cette organisation évoluent

• (et d’ailleurs, les deux aspects s’influent mutuellement : on va chercher un mode de fonctionnement adapté aux enjeux et à l’organisation, mais l’organisation ainsi que les enjeux dont on peut se saisir vont évoluer en fonction du mode de fonctionnement expérimenté…)

• Enfin, car tout est en nuances ! Rien ne marche parfaitement bien, on est rarement uniquement dans les extrêmes, c’est un chemin de crête qui nécessite d’alterner

Pourquoi décentraliser ?

La décentralisation, cela va être la cible idéale dans l’esprit des agilistes. Un monde merveilleux où l’on découpe les problématiques métiers en plus petits morceaux pour pouvoir les adresser par des petites équipes indépendantes, autonomes et en capacité de prise de décision. On aime bien utiliser le terme anglais d’empowered teams pour passer ce sens. 1

On désigne souvent cette approche par “passer en mode produit” ou de faire une “organisation produit”. On l’oppose également souvent à un fonctionnement à l’échelle, on évoquant une organisation qui cherche à unscale les problèmes à résoudre, plutôt qu’à scale l’organisation. 2

Spoiler : c’est très beau sur le papier, mais ça ne marche pas vraiment en pratique — ou plutôt, ça ne marche pas avec la simplicité avec laquelle on l’énonce.

• Tout d’abord parce que le fond du sujet, la vraie difficulté, ce n’est pas tant la manière de s’organiser que les niveaux de délégation. Ce type de changement est une modification fondamentale de philosophie et de contrats sociaux au sein de la société. Possible, oui — des organisations le font !3 — mais cela nécessite une véritable volonté, profonde et authentique. Si la majorité des organisations sont en transformation ou en nécessité de se transformer, celles prêtes à passer ce cap se font bien plus rares.

• Ensuite parce qu’en pratique, on reste dans un contexte à l’échelle. On veut garder une forme de contrôle sur les équipes. On veut construire tout un écosystème autour de ces équipes pour les aider, mais également pour les garder alignées avec les enjeux collectifs.

Pour conclure cette section :

Pourquoi centraliser ?

À l’inverse, on peut plutôt chercher à centraliser. Les raisons de passer par là ne manquent pas :

• Des enjeux collectifs qu’il est très difficile de porter à l’échelle sans aucune centralisation — un des meilleurs exemples restant, à nouveau, la cybersécurité

• Optimiser les coûts, par exemple en s’assurant que l’on ne se saisit pas de la même initiative en double, ou en mutualisant les coûts d’hébergement et autres licences

• Mettre en place une gouvernance pour garantir un niveau de qualité élevé, ou pour s’assurer d’une bonne utilisation de la capacité disponible (priorisation)

• Reprendre le contrôle sur l’existant et couper court au shadow IT où il n’y a aucune garantie de qualité, de maintien en conditions opérationnelles, de cybersécurité, de coûts de fonctionnement…

• Un turn-over élevé, potentiellement lié à un recours massif aux externes, et qui nécessite une forme de centralisation pour garantir la pérennité de la connaissance et un niveau satisfaisant de maintien en conditions opérationnelles

Cette liste n’est pas exhaustive, mais elle couvre probablement les raisons les plus courantes.

La centralisation est souvent inévitable

Même avec l’ambition de décentraliser, on doit souvent passer par une étape de centralisation.

Décentraliser, c’est beau sur le papier.

Pour que cela marche bien, il faut réussir à mettre en place de nombreux éléments techniques et organisationnels — en plus des enjeux culturels évoqués plus haut autour des niveaux de délégation.

• L’excellence technique : sans filet de non-régression automatisée et sans architectures visant à réduire les adhérences, l’autonomie des équipes ne fera pas long feu. La gestion des dépendances entre équipes prendra le pas sur la volonté d’autonomie.

• Plus largement, la rationalisation et l’industrialisation des modes de fonctionnement.

• Au-delà des processus et outils, il est aussi simplement question de faire monter en compétence le collectif sur ces aspects, et à développer le leadership nécessaire à tout les niveaux.

• Et également avoir une vision globale suffisamment forte, un alignement suffisamment clair pour permettre l’autonomie. Par extension, le style managérial dans la société va également être un ingrédient clé.

Sans ces prérequis, tout reste possible, mais le chemin à parcourir devient alors bien plus difficile ! La sagesse suggère plutôt de limiter les challenges et de les adresser par étapes.

La dimension transformationnelle

Un autre aspect, c’est la dimension transformationnelle que porte la DSI.

Souvent, la DSI se retrouve également en charge de la transformation des métiers. Parfois en soutien, d’autres fois à donner l’impulsion et à embarquer les métiers. Tout dépend du contexte : mécaniquement, plus la transformation est liée à la digitalisation des manières de travailler, plus la DSI va se retrouver au cœur du réacteur.

La manière dont la DSI se transforme elle-même va poser des bases essentielles par rapport aux métiers, comme par exemple la mise en place d’une gestion capacitaire avec un plan au trimestre forçant à prioriser les initiatives.

Une phase de centralisation aide à insuffler, porter et supporter cette dynamique de transformation. On pose les règles du jeu, ce que la centralisation permet ou facilite.

Le plus important : ne rien figer dans le marbre

Je ne suis pas en train de promouvoir la centralisation comme la réponse absolue à tous les problèmes. Je reste persuadé que la décentralisation permet d’atteindre des niveaux de performances bien supérieurs.

Néanmoins, la mise en place de la décentralisation nécessite généralement d’y aller progressivement. À court et moyen terme, la centralisation apporte de nombreux bénéfices par lesquels il faut passer avant d’espérer embrasser la décentralisation.

Besoin de transparence

On attribue cette maxime à Lénine :

“La confiance n’exclut pas le contrôle”

Cela ressemble beaucoup au titre de cet article.

Avec tout de même une grosse différence : en parlant de preuves, je ne cherche pas nécessairement à contrôler mais j’explicite un besoin de transparence.

Dit autrement, il est normal de rentrer dans le contrôle si on n’a aucun feedback sur comment se passent les choses — mais le contrôle n’est pas la seule issue si on a suffisamment de transparence.

Presque irrationnel

Il se joue là quelque chose de viscéral : sans visibilité sur la progression, j’imagine qu’il se passe le pire. Et l’interventionnisme devient alors quasiment inévitable !

En tirant le trait, j’irais même jusqu’à dire que l’on se sentirait même mieux en sachant que cela se passe mal, qu’en n’ayant pas de statut clair à date. Au moins, pourra prendre des actions correctives ! Que cela soit soi-même, ou en s’assurant que les personnes en charge sont elles-mêmes au courant et vont donc reprendre le contrôle de la situation.

Le savoir est une chose, le vivre en est une autre

Je pense que ce que j’énonce ici ne surprend pas grand monde.

On le sait.

Moi-même, dans mes précédentes vies de consultant, accompagnant, coach ou formateur, je connaissais l’importance de la transparence dans la mise en place de l’agilité, d’une démarche d’amélioration continue, ou de n’importe quelle transformation. J’y faisais attention, je la promouvais, je la mettais en avant.

Et pourtant… Quelle claque je me prends à nouveau à chaque fois que je passe de l’autre côté du miroir, lorsque je suis dans la position de celui qui délègue.

Comme si, quand on est du côté de celui à qui on délègue, la notion de transparence était un concept un peu flou. On est conscient de son importance — tout en la minimisant. Ca peut toujours attendre… C’est toujours moins prioritaire que de faire le travail ou avoir de l’impact.

Alors que quand on est du côté de celui qui délègue, c’est extrêmement concret : suis-je en capacité de dire sur quoi travaillent ces personnes, où ça en est, et comment ça se passe ? Oui ou non ?

Je reviens sur l’adjectif que j’ai utilisé dans la section précédente pour décrire cette mécanique : c’est viscéral.

👉 Quand ce besoin de visibilité n’est pas satisfait c’est quelque chose que l’on sent en soi, que l’on n’arrive pas à ignorer malgré tous ses efforts pour être “un manager qui n’est pas dans le contrôle”, et pourtant c’est aussi quelque chose que les autres n’arrivent pas à palper de manière aussi concrète.

La solitude du manager

Dans cette section, je vais prendre un ton assez sombre.

Toutes les personnes qui ont eu des responsabilités, et surtout lorsqu’elles ont eu à gérer des situations difficiles, seront d’accord avec cette phrase :

“C’est toujours la faute du patron”

C’est à dire que, quoi qu’il arrive, et quelle que soit la bonne volonté du responsable, ultimement c’est à lui ou elle qu’on reprochera la situation.

D’une certaine manière, c’est justifié, car justement cette personne, en tant que responsable, est responsable de ce qu’il se passe et de comment ça se passe.

Le principe de délégation n’implique pas de se laver les mains des actions de ses subordonnés. Bien sûr, s’ils ne sont pas au niveau, on les sanctionne ou on en change. Mais en tant que responsable, on partage les échecs, que cela soit en n’ayant pas posé le bon cadre, pas donné les bons moyens, pas suffisamment accompagné ou recadré la personne, ou pas sélectionné la bonne personne pour ce travail. Il n’y a pas d’échappatoire à sa propre responsabilité.

Une fois que l’on réalise cela, on comprend mieux la solitude qui accompagne irrémédiablement les responsables en général.

Il ou elle n’est pas isolée du monde, la personne peut se tourner vers divers groupes pour l’aider. Mais cela reste une charge qu’elle portera et qu’elle ne pourra pas partager, intimement liée à cette notion de responsabilité.

Surtout, les personnes qui ne sont pas passées par là, qui ne sont pas passées de l’autre côté du miroir, ne peuvent pas vraiment imaginer ce que c’est. Il faut l’avoir vécu. 1

Je n’écris pas cela pour faire mon Calimero, pour me plaindre de cette situation et en accuser les contributeurs individuels. Bien au contraire, mon intention est d’appuyer sur l’importance, en tant que responsable, d’en être conscient. Ajustez votre attitude et vos attentes en conséquence.

On tombe tous dans le piège !

Cette dynamique se joue en fractale : elle se joue par rapport à son équipe à qui on délègue… Mais elle se joue également, dans l’autre sens, avec son propre responsable !

Bien sûr, d’être dans la posture où l’on délègue soi-même aide à être conscient de ces mécaniques. Malgré tout, ce n’est pas forcément suffisant… On peut très facilement tomber dans le piège, en se plaignant que ses subordonnés ne font pas preuve d’assez de transparence et en même temps négliger le manque de transparence dont on fait soi-même preuve auprès de son responsable.

C’est un vrai paradoxe. On est dans le registre des biais cognitifs : même lorsqu’on en est conscient, on y reste soumis. Mais surtout, on ne vit pas la même chose dans les deux cas, et le travail de se mettre à la place de l’autre reste toujours difficile, cela nécessite un effort explicite que l’on fait rarement lorsqu’on est dans le feu de l’action.

Cet article est autant un partage que je vous fais, qu’un rappel pour moi-même ! 🤗

Pour ces équipes, cela leur semble l’évidence même :

1. Que les métiers savent mieux que nous ce dont ils ont besoin, et

2. Qu’il faut faire tester par les utilisateurs (toujours ces mêmes métiers donc) pour valider le travail.

Dans cet article, je vais expliquer en quoi cette manière de voir les choses est fondamentalement faussée. Mais avant cela, je vais commencer par illustrer tous les problèmes de cette approche, en quoi c’est un frein majeur à la performance. Je conclurai en donnant des pistes pour faire autrement.

Les problèmes de l’approche UAT

Sans même philosopher de la pertinence ou non de l’UAT, le problème majeur est que cela introduit une dépendance envers des personnes externes à l’équipe au cœur de son flux de travail.

C’est directement antinomique avec le principe d’une équipe qui travaille en cycles courts. Voici ce que l’on constate généralement, tous des scenarios que l’on voudrait éviter :

• On fait des sprints à durée variable, car on ne sait pas combien de temps durera la validation avant de pouvoir mettre en production. Au moins, cela permet d’avoir une vision honnête de ce qu’il se passe d’un point de vue utilisateurs…

• Ou alors, on fait des sprints à durée fixe, mais on exclut alors la mise en production de la Definition of Done. L’équipe considère que son travail est “terminé” non pas lorsque le problème utilisateur est résolu, mais lorsqu’elle a codé une solution, qu’elle soit bonne ou mauvaise. Et s’il faut retravailler la solution… Se pose alors la question insoluble de s’il faut ou non compter ce travail dans la vélocité des sprints suivants pendant lesquels ont lieu ces corrections.

• Dans tous les cas, on ne travaille pas au fil de l’eau à faire du déploiement continu. Au contraire, cela encourage voire force à faire des gros morceaux, que l’on validera en une seule fois. Au mieux, on fait donc un déploiement par sprint… Et de manière plus réaliste, sûrement un déploiement tous les quelques sprints. Ce qui finalement est logique quand on n’intègre pas le déploiement dans la Definition of Done. 🤷

• Même constat pour une équipe qui ne fonctionne par en sprints : ça dérape, ça prend du temps, on fait des grosses releases plutôt que des déploiements au fil de l’eau.

• Quoi qu’il arrive, de grosses releases impliquent des tests plus difficiles et coûteux, plus de régressions, plus de retravail, moins de satisfaction, une dynamique d’équipe moins optimiste… Bref, tout s’aligne vers moins de performance.

Cas particulier 1 : l’agence qui pose contractuellement la réactivité du client

Pour être complet et équitable dans mon analyse, je me dois tout de même de parler de quelques cas particuliers où l’approche marche plutôt bien.

Le premier cas particulier est celui d’une agence qui pose clairement que le client doit être réactif, à chaque étape clé, pour donner ses retours sur le travail livré. Dit autrement, on lui impose d’être là en Sprint Review ou de faire des tests dans un environnement dédié à intervalles donnés, planifiés en avance — sous peine de pénalités financières autrement !

Concrètement, on reste dans le même modèle, mais on met en place des éléments qui vont drastiquement contraindre la dépendance externe à l’équipe de sorte à ce que cela reste gérable.

Ma première remarque sur le sujet pourrait être de se demander si, dans ce mode de fonctionnement, la personne qui fait les validations est bien externe à l’équipe ? Ou si justement on ne pourrait pas considérer que, d’une certaine manière, le cadre contractuel force l’intégration de cette personne dans l’équipe.

Dans tous les cas, cela ne fonctionnera qu’à ces trois conditions :

1. Ces dimensions contractuelles et financières qui permettent de forcer la participation de la personne et d’éviter que cela ne soit un point de blocage de l’équipe.

2. Autre élément également lié au contexte agence : le client est considéré comme pertinent pour valider de la pertinence du travail fait.

3. Dernier point et non des moindres : l’excellence technique est un prérequis absolu. Si l’on soumet régulièrement pour validation une solution bourrée de régressions, le client refusera de jouer le jeu — à raison.

Cas particulier 2 : “continuous delivery, release on demand” avec les Feature Flags

Un autre cas particulier qui permet de faire fonctionner l’UAT, c’est d’utiliser les Feature Flags2 afin de pouvoir décorréler mise en production et mise en service.

L’UAT n’est alors plus un prérequis pour la mise en production, l’équipe met en production de son propre chef sans dépendance externe. L’UAT fait partie du processus préliminaire à l’activation en production qui enclenche la mise en service, selon une temporalité toute autre.

Ce concept poussé jusqu’au bout s’appelle “continuous delivery", release on demand” :

• L’équipe fonctionne en livraison continue, en mettant en production les plus petits incréments possibles, et idéalement chaque jour

• Côté demandeurs, métiers, marketing ou autres, on est en total contrôle de la mise à disposition aux utilisateurs

Cela va sans dire, cette approche nécessite également une véritable excellence technique et une totale maîtrise des effets de bord potentiels.

C’est d’ailleurs une telle évidence que la plupart des équipes n’imaginent même pas que cela soit possible de fonctionner ainsi : parce qu’elles sont actuellement incapables de mettre en production facilement, rapidement et sans régression. Quand on n’a jamais connu ça, on pense que c’est impossible. C’est normal.3

Quoi qu’il arrive, il me semble intéressant de noter que les deux cas particuliers ont l’excellence technique comme prérequis fort. Quoi qu’on fasse, on n’y coupe pas ! 😉

Le principe d’UAT ne tient pas debout

Après avoir expliqué les conséquences négatives du principe d’UAT, revenons au pourquoi les équipes en font. J’avais évoqué en introduction les raisons suivantes :

1. Les métiers sauraient mieux que l’équipe ce dont ils ont besoin, et

2. Il faudrait faire tester par les utilisateurs (toujours ces mêmes métiers donc) pour valider le travail.

Ces hypothèses sont erronées. A minima elles méritent d’être nuancées, et ainsi laisser entrevoir que l’UAT n’est pas la seule solution.

La vérité est en prod’

Qui sait ce qu’il faut construire ?

Ultimement, la réponse, c’est… Personne. Même les utilisateurs eux-mêmes ne savent pas réellement.

Bien sûr, je ne suis pas en train de dénigrer la pertinence de donner une vision, des études marketings ou de l’expertise métier. Tous ces éléments sont extrêmement pertinents et utiles.

J’aime bien résumer ce constat avec cette phrase : “La vérité est en prod’.”

Cela ne veut pas dire que cela ne sert à rien de faire des tests avant de mettre en production. Cela ne veut pas dire non plus que les métiers n'ont aucune valeur et qu’on n’a pas besoin d’eux.

Cela veut dire que, quoi que l’on fasse, il ne faudra jamais oublier de vérifier les résultats en production, et que rien n’aura plus de poids que ces derniers.

Qu’attend-on réellement de l’équipe ?

Une autre manière d’analyser le principe d’UAT, c’est de réfléchir en termes de responsabilités et par extension de voir quelle dynamique d’équipe cela encourage-t-il.

Cela revient à se poser cette question : qu’attend-on de l’équipe ?

Avant d’aller plus loin, je tiens à préciser que mon propos n’est absolument pas de suggérer que les métiers seraient superflus ou que l’équipe devrait se passer de ces derniers.

Par contre, il y a souvent des dynamiques contre-productives, comme les équipes DSI en posture d’exécutant vis-à-vis des métiers. Mais attention ! Quand cela arrive, ce n’est pas toujours la faute aux métiers qui les positionneraient ainsi. Bien au contraire, c’est même généralement les équipes DSI qui se positionnent en tant que tel, d’elles-mêmes, alors que les métiers aspireraient à avoir un véritable partenaire en face.4

Prenons cet angle pour analyser le sujet de l’UAT. Si cela part d’un bon sentiment, il est important de réaliser ce l’UAT encourage ou renforce cette dynamique où les équipes DSI sont des exécutants vis-à-vis des métiers. On s’interdit de mettre en production quoi que ce soit qui n’a pas eu le go des métiers : ainsi, on laisse reposer toute la responsabilité sur les épaules des métiers.

Je m’attends à ce que pas grand monde ne soit d’accord avec moi, car ce n’est pas l’intention qui est derrière — ce que je ne remets pas en cause. Néanmoins, j’invite à prendre du recul et à observer la situation de manière dépassionnée, pour réaliser qu’indépendamment de l’intention c’est bien la dynamique qui est créée.

Paradoxe même de cette situation, la perspective de changer cette dynamique peut faire peur : car cela implique un changement de responsabilités qui n’est pas anodin.

La pertinence des métiers est dans la définition des cas de test, pas dans leur exécution

Je redis que mon but n’est pas que les équipes DSI se passent des métiers. Cela n’aurait aucun sens. Il est par contre crucial de créer une relation différente avec les métiers, de continuer de s’appuyer sur ces derniers mais pas pour les mêmes choses.

Concrètement, la valeur des métiers est justement dans leur connaissance métier. C’est bien leur connaissance métier que l’on veut extraire et non directement les faire tester.

J’explique plus loin dans cet article, à propos du Shift Left, comment actionner ce changement de dynamique. Toujours est-il qu’il n’est nullement nécessaire que les métiers testent eux-mêmes.

Eviter la facilité

Bien sûr, impliquer les métiers dans la définition des tests mais pas dans leur exécution, cela nécessite de véritables compétences et excellences techniques et méthodologiques. La triste réalité, c’est qu’on voit trop souvent une forme de facilité qui s’en remet intégralement à l’UAT, plutôt que de juger soi-même de la pertinence des tests et surtout d’en assumer les conséquences ensuite.

Sans en faire une généralité, force est de constater que de trop nombreux développeurs trouvent normal de livrer du code qui ne fonctionne pas. Comme souvent, c’est surtout qu’ils n’ont jamais connu de contexte où ce n’était pas ainsi.

Pourtant, cela ne devrait pas être le cas. On devrait toujours livrer du code qui marche !!!

Les approches alternatives que je vous partage ci-dessous font, au contraire, cette hypothèse que l’on peut livrer du code qui marche — en s’y prenant bien.

Comment faire autrement que l’UAT

On vient de voir que le principe d’UAT, en plus de poser des problèmes, n’avait pas réellement de sens sur le fond. Alors, comment faire ? Quelles sont les alternatives ?

Les réponses s’appellent : Shift Left et Shift Right. Ces deux approches sont complémentaires.5

Leur point commun est qu’elles font en sorte de ne plus avoir de phase de validation formelle avant mise en production qui dépend de personnes externes à l’équipe, ce qui est le reproche principal de l’UAT en termes d’impact sur la performance.

Il y a plein d’autres avantages à appliquer ces approches 😉 et je vous invite fortement à vous y intéresser quoi qu’il arrive !

Shift Left : travailler avec les métiers en amont plutôt qu’en aval

Dans un processus de développement logiciel typique, l’effort de test se situe après le développement et avant la mise en production.

Le Shift Left consiste à décaler vers la gauche l’essentiel de cet effort de test, avant et pendant le développement plutôt qu’après. Dans notre cas de figure, cela se manifeste en particulier par ces deux approches : 6

• Lors des différents affinages ou refinements pour spécifier les fonctionnalités via les scénarios de test et les jeux de données. On peut par exemple s’outiller avec des approches telles que le Behavior-Driven Development et l’Example Mapping. 7 S’il y a toujours une phase d’exécution des tests qui suit le développement, celle-ci se réduit à peau de chagrin car le gros de l’effort est fait en amont sur la conception de ces derniers.

• En automatisant les tests, autant les tests d’acceptation que l’on aura défini précédemment via l’approche BDD, que les tests de non-régression. Ces tests peuvent alors être lancés à foison pour un coût dérisoire. L’essentiel de l’effort passé sur ces tests est concentré sur leur écriture via des tests automatisés.

Cela peut sembler difficile à mettre en place. On est généralement persuadé que les métiers ne voudront jamais lâcher la main sur la validation avant mise en production. De mon expérience, j’ai plutôt vu ceci :

• Spécifier le plan de test détaillé en amont du développement et demander une validation là-dessus, c’est avant tout faire preuve de professionnalisme. Inutile d’avoir peur ou honte de proposer de faire ainsi.

• Les métiers ne voudront pas lâcher la main sur la validation s’il y a un historique de versions bourrées de bugs, auquel cas la confiance est clairement brisée. Dans ce cas, n’essayez pas de les convaincre de faire autrement : la confiance ne se décrète pas. Donnez-leur simplement des versions sans bug. Au bout d’un moment, ils arrêteront de tester d’eux-mêmes. Ils auront bien mieux à faire !

Voici mon dernier conseil : une phrase puissante qui m’a beaucoup servi pour impliquer pleinement les métiers dans ce travail de spécification du plan de test en amont du développement. L’idée est de commencer par préparer une première version du plan de test, au mieux des possibilités de l’équipe. Puis de la soumettre à un métier en lui demandant :

Voici la liste exhaustive des cas de test que nous avons imaginé.
Dans l’hypothèse où nous exécutons tous ces cas de test nous-mêmes, et où tous les résultats sont OK, est-ce que pour toi on peut pousser cette fonctionnalité en production sans que tu n’aies à vérifier quoi que ce soit d’autre ?

Implication garantie 👌

Shift Right : surveiller les comportements réels après mise en production plutôt que dans un environnement artificiel avant

Cette fois, le Shift Right consiste à décaler vers la droite l’effort de test, après la mise en production plutôt qu’avant.

Si le Shift Left vise à mieux gérer le travail de validation avant mise en production, le Shift Right vise à aller vérifier en production la véritable adéquation avec le terrain plutôt que d’essayer de s’en assurer dans un environnement forcément artificiel, autre que la production.

Cette fois-ci, il est donc question de mettre en place du monitoring pour pouvoir suivre le comportement de la solution et de ses utilisateurs en production. On peut compléter par de l’alerting pour réagir au plus tôt lorsque des incohérences sont détectées.

Il est également question de faire des tests A/B en validant en production si un changement apporte les bénéfices attendus ou non, plutôt qu’avec des représentants des utilisateurs dans un environnement contrôlé de pré-production.

Avec ces pratiques, on résout directement le problème des métiers qui ne sont que des représentants des vrais utilisateurs, en instrumentant directement la prod’. Cela rend caduque d’avoir une phase d’UAT, puisque l’on peut avoir ainsi un feedback bien plus pertinent.

Pour conclure

Dès lors que le flux de travail de votre équipe est en attente de personnes externes, ce qui en bloque la fluidité, ne l’acceptez pas comme une contrainte naturelle et normale avec laquelle il faut vivre. Au contraire c’est certainement un signal qu’il faudrait travailler autrement.

Avec des approches comme le Shift Left et le Shift Right, les bénéfices de ces approches vont bien au-delà de la fluidification du flux de travail. Par contre, cela nécessite souvent de véritables changements de paradigme et c’est pourquoi leur mise en place n’est pas toujours une évidence pour les équipes.

C’est tout naturel. Dans ce type d’organisation l’IT est une fonction support du métier, et la dynamique suivante se joue en permanence :

• Le métier : “J’ai tel problème, j’ai besoin de ça”

• La DSI : “OK, laisse-nous regarder… On peut te faire ça pour la fin du trimestre.”

• Le métier : “Ah génial ! Ca va vraiment nous aider. On se revoit à la fin du trimestre, alors !”

La dynamique clé que l’on retrouve ici, c’est celle de la promesse.

Et quand, pour une raison ou une autre, on se retrouve à ne pas pouvoir tenir cette promesse, alors on passe un sale quart d’heure.

C’est pourquoi ces responsables cherchent alors à améliorer leur prédictibilité : en somme, faire en sorte d’arriver à tenir leurs promesses.

Jusqu’ici, tout est normal

Le problème n’est pas tant dans le fait de faire une promesse, que sur ce qui est promis.

On est bien obligé de faire des promesses. Quelqu’un qui ne veut s’engager sur rien, ça va être compliqué de travailler avec lui. 1

Donc, bien sûr qu’on prend des engagements.

Changer la nature des promesses

Néanmoins, il y a toutes sortes de promesses.

L’enjeu est de prendre de la hauteur dans ses engagements, pour se mettre au niveau du partenaire auprès duquel on s’engage.

S’engager à livrer un composant technique avant une date donnée, non seulement c’est casse-gueule car trop contraignant, mais qui plus est le partenaire s’en fiche royalement !

Ce qu’on veut, c’est s’engager à ce que le problème du partenaire soit corrigé.

Sortir du paradigme de la prédictibilité

Voici ce qui se joue derrière ce focus sur le problème à résoudre :

• L’important est d’être là au rendez-vous, non pas avec ce que l’on imaginait ou proposait de faire initialement, mais avec une résolution du problème — peu importe comment !

• Les excuses ne comptent pas : on est là pour faire face à toutes les embûches et autres imprévus qui se mettent en travers de la résolution du problème. Et si la solution n’est pas la bonne, on change de solution !

Un changement de posture

En réalité, les excuses ne comptent jamais. Ce que je veux mettre en exergue ici, c’est qu’en s’engageant sur les livrables, on ne peut pas faire grand-chose à part s’excuser face à l’imprévu qui arrivera forcément. D’où l’intérêt de s’engager plutôt sur les résultats.

Par ailleurs, on peut déjà remarquer que le simple fait de s’excuser ou non indique le type de posture que l’on prend par rapport au demandeur :

• Assumer l’échec, sans chercher d’excuse, c’est prendre une posture de partenaire 🤝

• Alors que s’excuser, se justifier, chercher à expliquer comment le fait de ne pas être au rendez-vous n’est pas de sa faute… Cette fois, c’est prendre une posture d’exécutant en se défaussant 🤷

En s’engageant sur la résolution du problème, sur les résultats plutôt que sur les livrables, on prend la posture du partenaire qui a compris ce qui se joue et sur qui on peut compter.

Être un partenaire fiable

Une manière fluide et efficace de passer ce message, c’est de changer de vocabulaire en ne parlant plus d’améliorer la prédictibilité mais de devenir un partenaire fiable.

La fiabilité, c’est cette idée plus fondamentale que celle de la prédictibilité où l’on s’engage à être au rendez-vous. Où l’on parle de ce qui compte, on prend de la hauteur pour se focaliser sur les enjeux du partenaire plutôt que sur ses propres enjeux.

Pas de réussir à faire ce que l’on a dit qu’on ferait. (= exécutant prédictible)

Mais de faire sa part pour atteindre des enjeux communs. (= partenaire fiable)

Changer de vocabulaire, c’est très puissant ! Cela aide à passer les bons messages, à expliquer les dynamiques qui se jouent et les changements de posture, mais également à les vivre et à en faire une réalité. 💪

Je me suis fait charrier cette semaine par rapport à mon article de la semaine dernière, intitulé de manière provocante : “Et si SAFe avait raison ?” 1

On m’a ainsi dit, non sans ironie, que désormais j’appréciais visiblement SAFe.

Je me suis dit que cette remarque, et ma réponse, pourraient intéresser une communauté plus large. Je profite bien sûr de cet article pour mettre en forme et étayer plus mes propres réflexions. 2

Je ne suis toujours pas fan de SAFe…
Mais c’est pas le sujet

Oui, je n’ai jamais fait partie des supporters de SAFe.

Oui, je tiens le discours selon lequel il vaut mieux réduire les dépendances et donc améliorer l’organisation, que de gérer les dépendances en ajoutant plus de synchronisation, plus de réunions, plus de bureaucratie.

Et pourtant.

Et pourtant, je suis obligé de reconnaître que, dans la vraie vie, souvent il n’y a pas vraiment de meilleure solution que SAFe à court terme.

Les deux éléments suivants sont clés dans cette réflexion :

• dans la vraie vie

• à court terme

Préambule : c’est le quotidien de ceux qui mènent une transfo

Ce que je vous partage dans cet article ne devrait surprendre que les personnes qui n’occupent pas elles-mêmes un poste de type “directeur de transfo” ou similaire.

“dans la vraie vie”

Je me focalise ici spécifiquement sur le contexte des grandes entreprises, les grands groupes.

Ma foi, il me semble que c’est le sujet principal quand on parle de SAFe. Je ne compte pas débattre dans cet article de la pertinence de SAFe dans une organisation de taille modérée. 3

Et donc, c’est quoi la réalité d’une transformation agile dans un grand groupe ?

• Des moyens limités,

• Une forte inertie, et

• Malgré tout, le besoin de montrer des résultats rapidement.

Des moyens limités

Des moyens limités, toutes proportions gardées. On peut avoir l’impression qu’il y a une armée de coach, mais qui doivent accompagner des dizaines voire des centaines d’équipes : l’un dans l’autre, on n’a pas les moyens de fournir un accompagnement dédié à chaque équipe.

Avoir des moyens limités n’est absolument pas spécifique aux grandes organisations. Cependant, je rappelle ce point car il renforce la difficulté à obtenir des résultats rapidement.

Une forte inertie

Détaillons pourquoi, généralement, on a une forte inertie :

• Les équipes sont sous l’eau. Toute initiative de transformation passe après le reste. Ce qui veut dire que toute démarche d’accompagnement est contrainte par le rythme existant. Certains parleront de la capacité des équipes à absorber le changement : pour moi, c’est le même sujet.

• En lien avec le point précédent, il est essentiel d’avoir un fort sponsorship. C’est encore plus vrai si l’organisation a une culture traditionnelle vis-à-vis de la hiérarchie (“la parole du chef vaut plus que celle des autres”), ce qui est souvent le cas dans une grande organisation. Si la transformation est sensée, pertinente et légitime, ce n’est pas un problème en soi d’obtenir ce soutien par la direction. Par contre, cela va prendre du temps.

• Une culture du “busy-ness” — être occupé est valorisé. Les agendas sont pleins, il faut s’y prendre à l’avance pour prendre du temps aux personnes… Ce qui, à nouveau, ralentit le rythme. 4

Toujours est-il que si le changement est tout à fait possible, il est par contre difficile de l’inscrire dans une temporalité rapide. Les changements d’envergure prennent du temps, et encore plus si l’on veut s’assurer de leur pérennité.

Comme on peut l’imaginer, cette inertie est antinomique avec le besoin d’obtenir des résultats rapidement.

Le besoin de montrer des résultats rapidement

Je viens d’expliquer comment le rythme d’une transformation dans une grande entreprise ne pouvait pas être trop rapide.

Pour autant, cela ne veut pas dire que l’on s’attend à ce que la transformation prenne du temps. Bien au contraire !

La transformation est souvent vue comme quelque chose de transitoire ou de facile, il suffirait de déployer une nouvelle méthodo et c’est bon ! En faisant fi de toute la complexité de la conduite du changement, des moyens limités et de l’inertie de l’organisation.

Même lorsque la dynamique d’une transformation est bien comprise, on se heurte alors aux problématiques de budget et de financement des initiatives : pour que le financement de l’initiative continue dans la durée, l’initiative doit montrer des résultats. Sans résultats, l’initiative de transformation est arrêtée. 5

Ce qui, à vrai dire, est très sensé ! C’est exactement le discours que portent eux-mêmes les agilistes quand il est question de gestion de produit ou de projet. Pourquoi en serait-il différent d’une initiative de transformation agile ? 😉

“à court terme”

Il faut donc avoir des résultats à court terme alors que tout se ligue pour rallonger le délai nécessaire pour avoir des résultats.

C’est bien ce paradoxe qui m’amène à reconsidérer la pertinence de SAFe.

SAFe est un rouleau compresseur. On impose, on écrase, on nivelle par le bas.

C’est cette caractéristique qui fait qu’il est détesté par la communauté agile.

C’est également cette caractéristique qui lui permet d’obtenir des résultats relativement rapidement malgré toutes les contraintes des grandes entreprises.

D’où mon constat que, oui, SAFe est adapté aux grandes entreprises.

Le vrai risque est après

Avec cette approche, on arrive donc à passer les premiers cycles de négociation de budget. On déploie le bousin SAFe, on montre des résultats et l’initiative de transformation continue.

Et après ? C’est là que les vrais ennuis commencent. Il ne faut alors pas s’enliser dans ce qui a été démarré, et trouver comment démontrer de nouveaux résultats sans simplement se reposer sur l’effet rouleau compresseur de SAFe. Sinon… Pas de résultats, on arrête l’initiative, et on reste bloqué dans un SAFe simpliste, de surface ou de façade, qui ne va pas réellement chercher l’optimisation.

Voici le type de challenges qui attendent dans cette phase plus avancée :

• Mettre en place du Lean Portfolio Management et s’attaquer à de la gouvernance à plus haut niveau

• Adresser tous les problèmes de dette technique, et notamment les enjeux d’automatisation des tests et de déploiement automatisé ; aller vers le paradigme “continuous delivery, release on demand”

• Restructurer les équipes pour réduire les dépendances, en osant aller jusqu’à changer l’organigramme

• Changer la culture au global et la posture du leadership

Et bien sûr… Se pose là encore la question de comment adresser ces sujets tout en apportant des résultats régulièrement et à court terme. 🤷

Conclusion : des petites roues pour démarrer rapidement

Finalement, SAFe est un excellent cadre pour bien démarrer, encore une fois en tenant compte de toutes les contraintes des grandes entreprises.

Pour continuer et aller au-delà de cette phase de démarrage, on ne coupe pas à devoir rentrer dans toute la complexité d’une transformation agile, mêlant à la fois organisation, gouvernance, excellence technique et culture.

Ca dépend à qui vous demandez.

Il y a ici un véritable paradoxe, que je vais vous exposer dans cet article.

Définition :

Je parle ici de PI Planning dans le sens du Big Room Planning, c’est à dire la pratique de mettre dans la même salle l’ensemble des contributeurs d’un produit ou service avec des interactions et dépendances, qu’elles soient techniques, fonctionnelles ou métier.

Je ne parle pas nécessairement ici de SAFe qui s’est approprié la démarche et qui l’a popularisé sous le nom de PI Planning, en le complétant notamment de System Demos et de Inspect & Adapt qui ponctuent le cycle des PI.

L’intégration de la pratique de PI Planning sans mettre en place SAFe est devenu assez fréquent.

Les bénéfices visés du PI Planning

Pour poser le contexte, voici une liste non exhaustive de bénéfices visés par une démarche de PI Planning :

⭐ Alignement sur les priorités du moment

• Donner plus de sens

• Réduire le Rework

• Réduire les silos

⭐ Vision globale sur les objectifs et sur le travail à venir

• Améliorer la transparence

• Donner une vision claire et consolidée

• Fluidifier le pilotage

⭐ Gestion des dépendances

• Améliorer le Lead Time

⭐ Engagement collectif

• Améliorer la prédictibilité

• Détecter les risques plus tôt, mieux les traiter

Ca parle beaucoup à certains…

Les directeurs et directrices

Du côté des directeurs et directrices, ils et elles sont très preneurs de tous ces bénéfices, c’est-à-dire d’une meilleure vision, d’un meilleur pilotage, d’un meilleur engagement et plus largement d’une meilleure performance de delivery.

En général, ce public est souvent très réceptif à la démarche proposée par le PI Planning, puisque cela répond directement aux problèmes souvent rencontrés dans leurs organisations.

Les équipes transverses

Du côté des équipes transverses, elles sont très preneuses d’avoir enfin un forum partagé où l’on peut arbitrer en direct les conflits de priorités vis-à-vis de leur capacité limitée.

En effet, il est souvent difficile voire impossible de challenger un engagement qui a déjà été pris. Sans démarche de PI Planning globale, on empile les couches de planifications, et chaque engagement rend plus futile les planifications suivantes qui sont contraintes par les engagements déjà pris.

Ainsi, pour ces équipes transverses dont le quotidien est un casse-tête de gestion de ressources et de compromis, le PI Planning est vu comme une porte de sortie de cet enfer qu’ils vivent chaque jour.

C’est l’horreur pour d’autres !

Les équipes orientées flux de valeur

Parlons maintenant des équipes orientées flux de valeur — ces équipes orientées vers le business et qui ne sont pas transverses. Pour elles, quand on leur présente une démarche de type PI Planning, ce qui leur saute aux yeux, c’est de la bureaucratie et de la complexité en plus.

Ces équipes galèrent déjà avec leur propre planification, à leur niveau.
À prendre des engagements qui soient pertinents et qu’elles arrivent à tenir.
En quoi faire ça avec tout le monde les aiderait ?
Par contre, ce qui est sûr, c’est que ça va prendre un temps de dingue 🤷
Alors qu’on est déjà sous l’eau à gérer le quotidien, le vrai, celui qui compte, celui qui rapporte des sous ou évite qu’on en perde ! 🤯

Pourquoi cette démarche PI Planning est poussée au forceps 🔨

Parce qu’y aller progressivement est contre-productif !

Il y a un véritable paradoxe autour de la mise en place de cette pratique de planification à l’échelle : on ne peut pas vraiment la déployer progressivement, incrémentalement, alors que pourtant les équipes n’ont pas envie qu’on y aille trop vite, d’un seul coup.

Le risque d’y aller progressivement

Que l’on parle de conduite du changement ou d’agilité, le réflexe est d’y aller progressivement : faire à petite échelle puis élargir progressivement, incrémentalement et itérativement.

Et c’est naturellement l’approche que proposeraient les équipes : en admettant qu’on doive y aller, vu comment c’est un sacré gros morceau à mettre en place et à faire vivre, essayons plutôt d’y aller progressivement !

C’est sensé. On n’investit qu’un peu dans un premier temps, cela permet d’en voir les bénéfices, cela convainc tout le monde et justifie la démarche, on peut alors investir plus — et ainsi de suite.

Sauf qu’ici, ça ne marche pas.

En y allant progressivement :

• On ne va pas bénéficier des atouts promis par la démarche

• Mais on va rajouter la complexité de sa mise en place

Ce serait alors plus galère pour tout le monde, sans en tirer les bénéfices. 😬

En deux mots, cela va simultanément prouver aux opposants qu’ils ont raison d’être contre, et aux supporters qu’ils ont tort d’être pour.

Echec total, donc. ❌

On investit un peu, on voit que ça ne marche pas et que c’est même pire qu’avant… On arrête 🛑

Préférer un déploiement “big-bang”

Si on ne peut pas déployer la démarche progressivement, par étapes, il ne reste que l’option de la déployer d’un seul coup, au global.

Cela fait mal à nos petits cœurs d’agilistes, mais cela ne surprend pas les experts de la conduite du changement : il est alors d’autant plus important d’insister sur l’accompagnement au changement.

Si le changement se fait en une seule fois, cela ne veut pas dire que l’on ne peut pas le préparer et l’accompagner ! En formant tout le monde, en leur donnant des outils, en les accompagnant au maximum dans la nouvelle manière de faire, de sorte à fluidifier au maximum la bascule.

Remise en perspective du déploiement de SAFe

Pour conclure cet article, je veux élargir cette réflexion à tout SAFe.

Sous cet angle de vue, la SAFe Implementation Roadmap a beaucoup de sens. Elle fait grincer les dents de par son embrigadement collectif et rigide, mais elle pose tous les éléments pour réussir à accompagner ce genre de changement.

Par définition, SAFe se positionne comme un outil pour résoudre les problèmes que l’on rencontre à l’échelle. Il n’est donc pas surprenant que l’ensemble du cadre proposé puisse souffrir du même symptôme que celui que je viens d’exposer à propos du PI Planning : en y allant progressivement on ne collecte que des gains marginaux, pour un coût et une complexité réelle, le tout menant à un compromis qui tue l’initiative dans l’œuf.

Dans cet article, je vous partage cette grille de lecture personnelle de la séniorité d’un ou d’une Scrum Master, séniorité qui n’est pas directement liée au nombre d’années d’expérience. C’est évidemment l’expérience qui provoque le passage des paliers, mais pas uniquement, et surtout pas au même rythme selon les personnes : certains passent ces caps rapidement alors que d’autres stagnent dans les premiers niveaux.

Voici ces grandes phases par lesquelles j’ai pu passer moi-même ou que je constate de manière récurrente.

Niveau 0 : Scrum Master de service

“J’ai été Scrum Master”

De nombreux Scrum Masters démarrent leur carrière dans un contexte de bouche-trou, personne n’a vraiment ce rôle dans l’équipe, on se dit qu’il faut l’assumer alors on en fait par exemple un rôle tournant — en plus des autres responsabilités.

Ce profil anime les réunions. Enfin… Façon de parler. Il suit juste l’horloge ainsi que des éléments à haut niveau comme qui a parlé en Daily. 🙄

Il s’assure aussi d’un bon reporting. En deux mots : le bon remplissage de Jira. 😬

À ce niveau, difficile de considérer que la personne a réellement été Scrum Master. Elle n’a d’ailleurs probablement pas eu de résultats à démontrer qui soient liés à sa mission de Scrum Master.

La personne a juste tenu le rôle parce qu’il fallait bien que quelqu’un le fasse…

Niveau 1 : Scrum Master “intuitif”

“J’ai accompagné des équipes, on a amélioré les choses”

On va être cette fois sur des profils qui ont réellement pu prendre en main le rôle de Scrum Master. Que cela soit parce que c’était leur responsabilité principale, ou parce que la personne s’est découverte une passion pour le rôle et s’y est alors pleinement investie en dépit du fait qu’elle avait d’autres responsabilités à tenir en parallèle.

Ce profil a des résultats mais n’a pas formalisé de mode opératoire, il ou elle y va au feeling.

La personne démontre manifestement une certaine compétence dans le rôle, mais elle va avoir du mal à reproduire ses succès. Pas évident face à la grande diversité des contextes, encore plus difficile d’avoir des résultats dans un délai contenu.

Souvent, ce profil n’a pas une véritable vision systémique des dynamiques et peut se sentir prisonnier des plafonds de verre dans ses missions. 1

Variante freelance

Dans le cas d’un ou d’une freelance, cela peut donner cette variante :

“J’en ai marre de ces missions de 💩 où je ne peux pas vraiment accomplir de choses”

Ici, la personne n’est pas passée freelance pour gagner plus d’argent ou par appétit pour la dimension entrepreneuriale (et notamment commerciale), mais pour la liberté, la liberté de choisir ses missions, de pouvoir n’aller que sur des “ bonnes” missions.

Cette ambition me fait réagir car c’est, pour moi, révélateur d’une vision tronquée de la réalité, typique de ce niveau d’expérience :

• On est frustré de ne pas avoir le mandat de faire tout ce que l’on veut

• Alors on fantasme des missions où l’on aurait ce mandat

• Sans réaliser que ces fameuses contraintes sont la normalité

• Et que le problème est plutôt soi-même, sur notre propre capacité à avancer dans ce type de contexte

Je ne critique pas : à nouveau, au travers de cet article je décris les différentes étapes que je constate dans la progression d’un ou d’une Scrum Master. Etapes par lesquelles je suis moi-même passé : moi aussi, j’ai pensé ce genre de choses à un moment donné de ma carrière. 🤷

Impact flou et peu durable

Globalement, ce type de profil de Scrum Master “intuitif” a également du mal à articuler et démontrer sa valeur. Ca va tourner autour de “l’équipe s’entendait mieux” 🤔

On entend souvent ce genre de chose :

“Quand je m’en vais c’est moins bien, tout ce que j’ai mis en place s’effondre, on voit ma valeur à ce moment-là”

(mais c’est alors trop tard pour continuer ma mission, je suis parti…)

Ce constat n’est pas surprenant. Sans démarche structurée, difficile de mettre en place les éléments permettant d’articuler l’impact de son intervention, ni de comment faire perdurer ce qui a été mis en place quand on n’est plus là pour le porter soi-même.

J’ai intitulé ce niveau le Scrum Master “intuitif”, mais j’aurais pu parler de “dilettante” si je cherchais un vocabulaire plus négatif.

Niveau 2 : Scrum Master “éclair”

“Voici comment j’accompagne une équipe”

Ce type de profil a suffisamment d’expériences, et a pris suffisamment de recul sur ces dernières, pour avoir structuré une démarche générale qu’il peut appliquer à chaque fois.

Cela peut sembler contre-intuitif à quelqu’un qui n’a pas encore atteint ce niveau, qui pensera que chaque contexte étant spécifique, l’accompagnement doit l’être également.

Pour autant, en pratique, on retombe toujours sur les mêmes types de problèmes et la même approche générale pour les résoudre.

Certes, les solutions peuvent beaucoup varier et dépendent du contexte. Mais on s’appuie sur un ensemble de trousses à outils bien remplies, ainsi que sur de l’intelligence collective par exemple via des ateliers.

Au-delà d’avoir une démarche générale reproductible, elle est également partageable ce qui permet d’accroitre la visibilité sur l’intervention, et par exemple de proposer une feuille de route de l’accompagnement. Avec des durées types pour chaque étape !

Enfin, ce travail amène à une meilleure maîtrise des composants des interventions, ce type de profil arrive alors généralement à détecter rapidement ce qui ne va pas et à déterminer ce qu’il faudrait faire, ainsi que de le mettre en place — tout cela dans un délai contenu.

Attention tout de même à ne pas prendre une posture trop sûr de soi, qui pourrait être perçue comme condescendante ! 😁

Rapide mais pas pérenne ?

Se pose tout de même la question de la pérennité des interventions de ce type de profil.

OK il a de l’impact rapidement. Mais est-ce que cela continue après son départ ?

En effet, on peut avoir un changement rapide, mais la transmission prend, elle, toujours du temps. Et cette transmission reste généralement superficielle.

Niveau 3 : Scrum Master “Lean”

À ce niveau, au-delà de suivre une démarche structurée et reproductible, ce type de profil s’appuie sur des métriques.

Attention, le sujet est bien plus complexe qu’il n’y parait :

• Trop de métriques tuent les métriques

• Mais pas assez de métriques amène à des angles morts problématiques

• Il n’est pas juste question de choisir quelques métriques cibles, mais de construire un système de métriques entre indicateurs tardifs et indicateurs précurseurs, chacun avec leurs usages et temporalités 2

• Enfin, le sujet ici n’est pas de démontrer qu’on a de l’impact, mais que l’on pilote l’amélioration continue par des métriques

👉 L’idée semble simple, mais nécessite une très profonde maturité pour la maîtriser en pratique.

C’est le PDCA. Le vrai PDCA du vrai Lean : dont l’application complète du cycle se compte en heures, maximum en jours, pas en semaines ou en mois.

Il y a de nombreux bénéfices à cette approche par rapport au niveau précédent, mais le point sur lequel je veux appuyer c’est la capacité à la transmettre aux équipes accompagnées.

Ce type de profil arrive non seulement à diviser le Cycle Time d’une équipe par 3 en l’espace de quelques mois, mais il aura également formé l’équipe à piloter ses Daily via le suivi de son WIP et du WIA, ainsi qu’à utiliser le Cumulated Flow Diagram en rétrospective. (ce qui implique, bien sûr, de le comprendre et le maîtriser !)

Tant et si bien que, sans être parfait, cette équipe continue son chemin sur l’amélioration continue après le départ du Scrum Master.

Quid de l’IA ?

On est en 2026, je suis bien obligé de faire cette section, non ? 😅

Comment l’IA se compare-t-elle à ces différents niveaux ?

• Niveau 0 Scrum Master “de service” : l’IA remplace.

• Niveau 1 Scrum Master “intuitif” : l’IA peut remplacer, cela dépend du talent de la personne. Ses intuitions peuvent justement être pertinentes. Attention tout de même, l’IA est globalement de bon conseil aujourd’hui…

• Niveau 2 Scrum Master “éclair” : la démarche structurée permet de ne plus se comparer à l’IA mais de s’appuyer dessus pour élargir son champ d’action de Scrum Master. L’IA peut également aider sur la transmission.

• Niveau 3 Scrum Master “Lean” : en complément, l’IA peut également être utilisée pour accompagner sur la définition de métriques, leur suivi, l’utilisation des différents outils… Là aussi l’IA permet d’élargir son champ d’action de Scrum Master. Mais l’IA permet aussi d’aller bien plus loin dans le suivi en continu des métriques, et dans la structuration des expérimentations de contre-mesures !

Les DORA Metrics c’est bien...

Si vous ne connaissez pas le livre Accelerate et plus globalement le travail du DORA ainsi que le rapport qu’ils éditent chaque année, vous passez à côté de quelque chose ! 1

Le DORA Model, c’est une véritable mine d’or :

• Un modèle, avec des preuves empiriques basées sur des corrélations statistiques significatives, qui illustre et explique le lien entre un certain nombre de pratiques d’ingénierie logicielle et la performance de livraison (le delivery) ainsi qu’avec les résultats de l’organisation : autant sa performance commerciale que non-commerciale, et également le bien-être des collaborateurs.

• Des métriques clés — les célèbres DORA Metrics — pour mesurer la performance de delivery, ainsi que des benchmarks permettant à chacun de positionner son équipe ou son organisation par rapport à l’état de l’art et par rapport à l’ensemble des praticiens.

• Un référentiel de pratiques, d’outils et de métriques permettant d’outiller toute démarche d’amélioration continue, d’audit ou de transformation.

• Le modèle se focalise sur l’ingénierie logicielle et donc sur “l’IT“, mais les répondants viennent de toutes les industries : cela ne s’applique donc pas uniquement aux solutions “IT for Tech“. Au contraire, tous les départements IT sont concernés, y compris dans la majorité des organisations où l’IT n’est pas la finalité mais une fonction support du business — du “IT for Business”. Bref, ça s’applique à tout le monde, pas d’excuse possible ! 2

Bon, je m’arrête là. En résumé, va te renseigner dessus, ça va changer ta vie.
Le site du DORA 👉 dora.dev

Des métriques sacralisées

Le travail du DORA et notamment le livre Accelerate ont eu un tel impact, que les DORA Metrics ont été positionnées dans de nombreuses organisations, conférences et meetups comme un mètre-étalon à avoir absolument.

Jusqu’au point où, comme souvent avec ce qui marche, on rentre dans le dogmatisme…

Il faut avoir ces métriques, et puis voilà !

Le but de cet article est de challenger cela.
Et de poser cette question, un peu coquine :

Une mise en œuvre pas si évidente que ça

Quand on lit les rapports DORA, on a une définition qui semble claire des différentes métriques, ça a l’air super, on se dit qu’on n’a qu’à y aller et les mettre en place.

Mais en pratique… ça ne marche pas comme ça.

À chaque fois que j’ai accompagné une organisation à les mettre en place, c’est compliqué.

À chaque fois :

• Soit on n’arrive pas à mettre en place toutes les métriques, et on finit avec une vision incomplète et orientée

• Soit on bricole en prenant une définition qui ne reprend pas exactement celle du DORA, avec le risque d’être moins pertinent

• Ou les deux en même temps 😬

À chaque fois, on bute sur des projets où la réponse technique de comment mesurer n’est pas évidente.

⛔ On n’a pas accès aux bonnes choses (droits d’accès et outillages)

🫢 Manque de rigueur pour avoir les éléments (on ne trace pas de manière claire, précise et sans ambigüité les mises en production)

📚 Diversité des outils de références, toutes les informations utiles ne sont pas au même endroit, et c’est compliqué de tout recroiser

⚙️ Utilisation de progiciels (comme des ERP) où les développements se passent dans des écosystèmes spécifiques et avec des contraintes propres

🤷 Ou on ne voit tout simplement pas comment s’y prendre !

Premier constat : toujours ce même perfectionnisme qui a du mal avec l’approximation et avec l’apprentissage empirique. Se dire qu’on va y aller avec quelques pilotes et aviser ensuite, ce n’est pas évident.

Et quand on passe ce cap, on bute cette fois à la difficulté à se positionner dans un temps long, en faisant évoluer progressivement les approximations et incomplétudes.

Bien sûr, on bute sur toutes ces contraintes sans intégrer à quel point ce sont des symptômes de choses bien plus graves :

• On n’est pas capable de savoir quels ont été les déploiements et leurs contenus exacts ? C’est en soi un problème bien plus grave que celui de ne pas réussir à extraire les DORA Metrics…

• On n’est pas capable de faire la différence entre des déploiements normaux et planifiés, ainsi que des déploiements de type hotfix de correction en urgence ? Même remarque…

• On ne sait pas remonter dans l’historique GIT jusqu’au premier commit ? Ca pose beaucoup de questions sur la rigueur de l’utilisation de GIT… La pratique du squash est souvent là pour masquer l’inexistence ou l’inutilité des commentaires des commits intermédiaires. 3

Mais surtout, pour quoi faire ?

Oui, à quoi bon s’embêter si ces métriques sont si galères à mettre en place ?

La réalité est la suivante :

On a juste vu l’émulsion autour des DORA Metrics, ce sont devenus autant de buzzwords qui font rêver sans qu’on ne sache trop pourquoi, et cela s’est alors imposé comme une évidence qu’il fallait les mesurer.

La suite logique : on mesure… Et on en fait du reporting. Bête et méchant.

On a alors perdu complètement de vu l’objectif du DORA :

“Get better at getting better”

L’objectif n’est plus l’amélioration continue, une vraie bonne démarche d’amélioration continue qui repose sur des métriques et plus largement qui se calque sur la démarche scientifique…

L’objectif devient les métriques elles-mêmes. 😭

Voici donc pourquoi mesurer les DORA Metrics 🎁

Si vous cherchez à rentrer dans une démarche d’amélioration continue via la mesure, vous n’avez pas besoin des DORA Metrics. Pas spécifiquement des DORA Metrics. Les DORA Metrics peuvent vous servir, mais elles ne sont pas les seules métriques pertinentes. Vous pouvez en utiliser d’autres.

Et même, vous devez en utiliser d’autres, a minima en complément, car les DORA Metrics ne suffisent pas.

Voici par contre 3 raisons qui justifient de se calquer spécifiquement sur les DORA Metrics :

Pour se comparer aux autres

Une des raisons pour lesquelles Accelerate a ébranlé la tech, c’était en apportant une vue globale et comparative de l’industrie, et la notion de performers.

Bref, fournir un benchmark public et reconnu auquel tout un chacun peut se comparer.

Que cela soit pour frimer, ou comme levier de négociation en brandissant les rapports DORA, en mode “regardez comme on est nuls et comment on pourrait être incroyables, allez go go go” 😀

Pour utiliser le DORA Model comme framework de transformation

Le travail du DORA peut être utilisé comme base pour structurer une démarche complète de transformation. La sortie du DORA Core Model 2.0 avec le rapport de 2024 ne laisse plus de doute là-dessus, c’est un cas d’usage validé et encouragé par le DORA.

Par exemple, avec Robin Béraud-Sudreau, on avait appelé ça faire une data-driven transformation. On le promouvait sur Scrum Life via des formations et des accompagnements spécifiques. 4

Dans ce cadre, l’utilisation des DORA Metrics permet de légitimer l’approche en renforçant le lien avec le DORA Model.

Pour motiver les ingénieurs via une démarche reconnue à l’externe

DORA propose également un programme pour reconnaître publiquement l’utilisation du modèle. Ce sont les Google Cloud DORA Awards. 5

Comme la plupart des macarons à décrocher, c’est surtout un outil de communication, autant en interne pour motiver les collaborateurs, qu’en externe pour inciter des candidats à rejoindre la société. 6

“Start with why”

Mais surtout... Demandez-vous POURQUOI.

Vous pouvez par exemple faire un “Start With Why” de Simon Sinek 🙂

Les DORA Metrics ne sont jamais la finalité. Toujours un moyen.

📏 Partez de ce moyen

❓Demandez-vous POURQUOI dans votre contexte — POUR QUOI

🧠 Puis seulement après réfléchissez aux moyens à mettre en œuvre, en ayant en tête vos véritables objectifs : vous retomberez peut-être sur les DORA Metrics… Ou au contraire pas. Et vous vous éviterez alors bien des problèmes.

🚀 Enfin, et toujours en gardant en tête le Why, mettez-vous en action !

1

Nous avions d’ailleurs commencé sur Scrum Life une série sur le sujet, qui pose d’excellentes bases. Voici ci-dessous les vidéos principales, ainsi que les documents que nous offrions en complément des vidéos. Ces derniers ne sont plus disponibles suite à l’arrêt de Scrum Life.

Accelerate en résumé

Scrum Life Poster Accelerate En Résumé

2.61MB ∙ PDF file

Download

Download

Le DORA Core Model en français

Scrum Life Accelerate Vue D'ensemble

1010KB ∙ PDF file

Download

Download

Les DORA Metrics

Evolutions entre le livre Accelerate et le rapport DORA de 2024

Focus sur les Capabilities

2

Je suis obligé de rebondir sur ce point. Cette mention du rapport DORA de 2024 nous avait inspiré chez Scrum Life pour faire un poster reprenant une célèbre phrase de Schwarzy :

“On peut avoir des résultats ou des excuses, pas les deux.”

Scrum Life Poster Accelerate Schwarzy

3.69MB ∙ PDF file

Download

Download

Résumé

• Une initiative de transformation doit porter des résultats remarquables relativement rapidement, sinon elle ne recevra plus de financements — l’initiative se fera tuer.

• Il vaut mieux avoir des résultats modérés mais visibles à l’échelle, que des résultats incontestables mais uniquement sur une seule équipe par exemple.

  • Si on n’aide qu’une seule équipe, on ne va avoir qu’un supporter de l’initiative et le reste qui se demandera à quoi ça sert !

  • À l’inverse si on apporte une amélioration, même mineure, à l’ensemble de l’organisation, alors tout le monde dira du bien de l’initiative.

• Ainsi, l’utilisation de frameworks clés en main et déployés de force est une stratégie qui prend tout son sens dans un grand groupe : ce n’est pas parce que c’est mieux, c’est parce que cela permet justement d’avoir une amélioration modérée à l’échelle.

• Cette stratégie n’interdit pas en soi de vouloir déployer une agilité adaptée à chaque contexte pour en tirer le maximum de bénéfices. Elle séquence la démarche en commençant par une première approche globale et générique, pour positionner l’agilité custom dans un second temps.1

Autres articles en lien

C’est généralement pertinent et justifié :

• Cybersécurité : “Ne partagez pas vos mots de passe…”

• Architecture : “Nous mettons en place une Design Authority pour éviter de faire les mauvais choix…”

• Coaching Agile : “Découpez le travail en incréments les plus petits possibles…”

• Support : “Documentez vos processus et les évolutions de vos produits…”

• Etc.

Sauf que :

Ça ne marche pas comme ça.

Dans cette phrase, je mets bien des guillemets à “on apporte notre support” car finalement — certes sans s’en rendre compte — on a surtout tendance à leur rajouter plein de choses en plus, à penser et à faire.
On leur en rajoute plus qu’on ne les soutient.

😭

Parfois, on tombe dans le grand n’importe quoi, en ajoutant des contraintes qui n’ont ni queue ni tête.
C’est par exemple le fameux syndrome de l’architecte dans sa tour d’ivoire, qui fait des recommandations voire impose des décisions qui sont déconnectées de la réalité.

Souvent, on est plutôt sur des contraintes et injonctions qui sont justifiées et pertinentes.
Malgré tout, cela reste une charge cognitive supplémentaire qui est rajoutée “on top of“, qui complexifie un quotidien qui est déjà surchargé.

Pour autant, les équipes sont demandeuses

Les équipes ont le nez dans le guidon à gérer tant bien que mal leur run et leur build.

Mais ça ne veut pas dire qu’elles sont aveugles, insensibles ou incompétentes.

Ces équipes se rendent bien compte qu’il y a plein de choses qui ne marchent pas comme il faudrait. Que ce n’est pas fluide. Qu’elles passent trop de temps en mode pompier. Qu’elles pourraient faire mieux.

Donc, déjà, attention à ne pas juste pointer du doigt tout ce qui ne va pas. Et surtout pas avec une posture condescendante.

Tout d’abord parce que, cela va sans dire, ce n’est pas comme ça qu’on pose de bonnes bases pour la suite en termes de relation. 🤷

Ensuite parce que le risque est de finir en Captain Obvious, à dire des évidences sans vraiment de valeur ajoutée.

“Oui merci, ça on le savait déjà, la question c’est plutôt qu’est-ce qu’il faut faire, et surtout comment tu peux nous aider !” 🙄

Les équipes sont demandeuses d’aide. Elles sont conscientes de leurs propres limites. Potentiellement en termes d’expertise, mais surtout en termes de temps, de focus et de budget.

Justement, ce qu’elles veulent, c’est bien de l’aide.
Pas qu’on leur en rajoute plus à faire.
En plus de tout ce qu’elles ont déjà à gérer… 🤨

Responsabilité vs charge cognitive

En tant que fonction support, après quelques loupés où l’on est mal reçu quand on essaie d’apporter son aide, on peut se méprendre et voir cette demande d’aide comme une volonté de se décharger d’une part de responsabilité.

Par exemple, imaginons le lancement d’une démarche d’architecture d’entreprise, jusqu’ici absente.
Les équipes sont contentes, elles se réjouissent de cette initiative qui apporte un œil plus global et qui ose prendre des décisions.

Justement, ces décisions…

En se faisant l’avocat du diable, en prenant un angle politique (et en étant mauvaise langue), on pourrait plutôt se dire que cette initiative est bien reçue parce qu’elle décharge de la responsabilité de la prise de décision.

Quelque chose de cet acabit :

“Si le projet part en couille après à cause de cette décision, ce ne sera pas ma faute car ce n’est pas moi qui ait pris cette décision.”

Ce ne serait ainsi pas tellement une demande d’aide, qu’un moyen de s’assurer qu’en cas de soucis c’est quelqu’un d’autre qui trinque ?

C’est pas faux, mais c’est trop simpliste.

Il y a surtout que les équipes ont déjà trop à penser et qu’elles sont heureuses de se décharger.
Elles cherchent à réduire leur charge cognitive.

Une fonction support qui réduit la charge cognitive

Comment accompagner, comment apporter son support, d’une manière qui RÉDUIT la charge cognitive au lieu d’en rajouter ?

“Faites comme ceci ou comme cela”

❌ On en rajoute

“On s’en occupe à votre place”

✅ On réduit la charge cognitive…

⚠️ … ou pas : si l’on doit vérifier après que c’est fait correctement et que ça ne casse rien, on garde la charge cognitive ! ❌

“L’outil vérifie automatiquement et vous alerte directement”

❓ Cela peut réduire la charge cognitive (on n’a pas à penser à la vérification) mais au final cela peut aussi en rajouter (ça donne du travail en plus, qu’on n’a pas forcément prévu !)

Ce n’est pas simple. C’est tout en nuances.

On peut facilement se planter, et il ne suffit pas de faire l’inverse de ce qui ne marche pas pour que ça fonctionne. 😬

La confiance et la fiabilité sont souvent des éléments clés : on peut alors déléguer le sujet sans avoir à y penser ensuite.
C’est la définition même de la délégation.

Team Topologies

Les concepts que je manipule ici sont au cœur de Team Topologies, qui s’appuie sur cette notion de charge cognitive. 1

Le message clé de Team Topologies est de se structurer en équipes qui ont le bon niveau de charge cognitive.

Ainsi, le rôle des équipes type plateforme est de réduire la charge cognitive des autres équipes. Pas de leur fournir des contraintes ou des services en plus, mais de leur permettre d’accomplir plus en ayant à penser à moins de choses.

On retrouve également une forte orientation vers la gestion de produit, y compris et surtout sur les équipes au service des autres équipes : il faut s’assurer que les services aident bien ces autres équipes. Cela tire autant des ficelles du service lui-même, que de comment il est mis en œuvre et mis à disposition.

Un exemple tiré du monde DevOps :
ticket factory vs self-service

Un exemple concret et bien connu pour illustrer cette nuance, c’est la manière dont une équipe infrastructure offre ses services aux équipes applicatives.

Dans la littérature DevOps, on compare ainsi souvent plusieurs modes possibles d’interaction.

En particulier, on a d’un côté la ticket factory : par exemple lorsqu’on a besoin d’ouvrir une nouvelle route, on crée un ticket à destination de l’équipe infra. L’équipe infra s’en charge quand elle peut (délais pour le demandeur) et éventuellement demande plus d’informations si le ticket est incomplet (imprévus pour le demandeur).
Voire, le pire scénario, dans une organisation peu collaborative : on rejette purement et simplement le ticket incomplet. Charge au demandeur de se débrouiller pour faire un bon ticket. Bonne ambiance ! 💔

Continuons l’exemple avec cette fois le self-service : pour ouvrir une nouvelle route, l’équipe demandeuse remplit un formulaire, ce qui déclenche directement le travail nécessaire. La demande est résolue sans délai et avec un feedback immédiat.

En mode ticket factory :

• En théorie, on soulage les équipes en leur enlevant l’expertise nécessaire.

• En pratique, on crée un bottleneck externe à l’équipe et au lieu de réduire leur charge cognitive, au contraire on leur en rajoute car il faut suivre la demande déléguée jusqu’au bout, faire des relances si nécessaire, être disponible pour compléter la demande, et planifier la demande suffisamment en avance pour pouvoir gérer tous les aléas… 🤯

• On part donc d’une bonne volonté, pour un résultat catastrophique. On est là pour aider les équipes, qui au final cherchent à la moindre occasion comment se passer de nous. ❌

En mode self-service :

• Bien sûr, la difficulté qui saute aux yeux de cette approche, c’est qu’il faut automatiser le travail pour pouvoir être mis à disposition en mode self-service.

• Il faut également travailler sur l’interface et la gestion des droits pour que les équipes puissent lancer ce travail automatisé seuls, de manière sécurisée et sans risque.

• Sans oublier de bien remonter le feedback, efficacement et de manière compréhensible ! Si quand on lance le formulaire le truc plante sans que l’on comprenne ce qui ne va pas, ça casse le modèle : car on doit alors demander de l’aide et donc ce n’est plus du self-service.

• Par contre, une fois mis en service avec succès, on a alors des équipes qui peuvent réellement faire abstraction d’un concept. L’équipe est autonome, elle fait la demande au moment où elle en a besoin et elle a un retour immédiat. On réduit effectivement la charge cognitive des équipes et on les aide réellement. On leur libère du temps, de l’énergie et du focus pour se concentrer sur la valeur ajoutée qu’elles doivent apporter. 🚀

Observer, créer du lien, itérer

Cet exemple tiré du monde DevOps est assez parlant mais ce n’est pas évident comment faire quelque chose de similaire dans d’autres domaines.

Dans ce précédent exemple qui compare ticket factory à self-service, si on voit bien tous les avantages de la seconde approche sur la première, ne nous leurrons pas sur la difficulté de le faire, et de le faire bien. Il y a un gros travail de fond d’automatisation mais également de lien entre les outils. Et comme souvent, le diable se cache dans le détail.

Il est donc critique de se mettre à la place de ses clients et utilisateurs en les observant et en créant un lien continu avec ces derniers, pour concevoir la bonne solution et détecter ce qui coince actuellement, pour itérer jusqu’à trouver une solution satisfaisante.

Scrum Master…

Le Scrum Master, c’est la personne qui intervient directement au niveau de l’équipe et normalement avec un réel engagement dans les résultats de l’équipe.

Si elle sait probablement prendre une posture de coach, cette personne n’est pas juste coach.

Par extension, de nombreux autres noms de rôle rentrent dans cette catégorie. Je pense en particulier au Delivery Manager qui le remplace de plus en plus, un vocabulaire qui appuie sur la responsabilité d’un delivery fluide et efficace et donc sur son partage des enjeux de l’équipe.

Et donc, cette personne vise l’excellence de son équipe, pour lui permettre d’atteindre ses objectifs, de les dépasser, d’aller toujours plus loin.

Coach agile…

À l’inverse, le Coach Agile, c’est une personne qui intervient à un niveau plus global, avec une mission et des enjeux centrés sur la transformation ou l’accompagnement.

Elle ne fait donc pas partie des équipes à proprement parler et ne partage pas directement leurs engagements de résultats.

Par extension, on pourra donc aussi ranger dans cette catégorie la plupart des variantes de coach, ainsi que les consultants en transformation et autre.

Ce que l’on demande avant tout à cette personne, c’est d’avoir de l’impact à l’échelle. Bon an, mal an, elle doit se contenter de la médiocrité car on aura au global plus d’impact, plus rapidement, en accompagnant de nombreuses équipes et en nivelant par le bas plutôt qu’en se concentrant sur seulement quelques équipes à la fois. 1

Un changement radical de perspective

Cette distinction est importante.

Elle n’est pas liée aux personnes et à leur manière de penser : je ne suis pas en train de dire qu’un Scrum Master ne peut pas être Coach Agile ou inversement.

Cela découle des contextes dans lesquels on les place : les enjeux, objectifs et attentes sont différents.

Cette distinction est importante justement parce que les deux rôles et carrières sont perméables. Il est habituel par exemple pour un Scrum Master de s’attaquer à une mission de Coach Agile… Pour découvrir trop tard la réalité que je décris ici.

Voici ma propre expérience

C’est exactement ce qu’il m’est arrivé.

Je me souviens d’avoir été Scrum Master et au contact de Coachs Agiles. Je critiquais ces Coachs Agiles qui se contentaient de la médiocrité. Je les entendais dire des choses comme :

“Voilà, l’équipe est lancée, maintenant on les laisse gérer leur amélioration continue.”

De mon expérience de Scrum Master qui visait l’excellence, à ce moment-là je n’avais pas encore compris que ce Coach Agile avait la bonne attitude, ou du moins qu’il avait la seule attitude tenable au vu de la situation.

Je me contentais donc de penser — pétri de certitudes, et en gardant bien pour moi ce jugement de valeur — que cette personne, et sûrement son ESN au global, était nulle. En tous cas, j’étais certain que je ferais mieux si j’étais à leur place 😅 sans me rendre compte de ma propre ignorance 😬

Je compris plus tard, notamment lors de ma première mission en tant que Coach Agile freelance, que cette personne avait raison et que c’était bien cela qu’il fallait faire.

À l’époque où je nous comparais, on n’avait pas du tout le même mandat. Elle était là pour faire bouger au global et n’avait pas le temps de s’occuper d’une équipe en particulier. Pas la même mission que moi, tout simplement.

Et clairement, je me suis sacrément planté lorsque j’ai assumé des mandats de Coach Agile avec un état d’esprit et une approche de Scrum Master.

Quand un Coach Agile intervient comme un Scrum Master 😕

Plus, tard, je fais quoi quand je suis Coach Agile et qu’on me donne le mandat d’accompagner un département entier ?

Je me comporte en Scrum Master.
Et les résultats ne sont pas géniaux. 🤷

Littéralement, on me laisse décider comment intervenir. Après tout, c’est moi l’expert. Et je décide de me focaliser sur une seule équipe à la fois.
Logique dans mon état d’esprit de Scrum Master qui vise l’excellence.
Erreur fatale vis-à-vis de mon mandat de coaching agile à l’échelle du département.

Au final, sans surprise : mon impact est très discutable. 👎

Après le recul de plusieurs plantages du genre, je finis tout de même par comprendre que ce que faisaient ces Coachs Agiles que je critiquais tant, c’était bel et bien la bonne chose à faire.

Et l’inverse ? Le Coach Agile en Scrum Master ?

Le Coach Agile est souvent présenté comme une sorte de “super Scrum Master” !
Si tel était le cas, alors un Coach Agile devrait faire des merveilles dans une mission de Scrum Master, non ?

Non. À nouveau, on est plus sur des approches différentes.

Si, comme je viens de l’illustrer avec ma propre expérience, le Scrum Master qui vise l’excellence aura beaucoup de difficulté à avoir de l’impact à l’échelle…

… Le Coach Agile, qui doit se contenter de la médiocrité de gré ou de force, aura beaucoup de difficulté à emmener une équipe en particulier à l’excellence !

Pour conclure : une distinction à maîtriser

Cette distinction n’est pas évidente au début et souvent on mélange les deux rôles, voire on les positionne comme une hiérarchie. Je vous suggère d’éviter de faire cette erreur et de chercher la bonne personne qui correspond aux enjeux de votre contexte.

Et bien sûr, pour être capable d’assumer les deux rôles avec succès, cela demande une réelle expérience et surtout maturité.

TL;DR

• Je ne souscris pas au discours démagogique selon lequel approches agile et traditionnelle seraient tous les deux biens, et qu’il faudrait juste utiliser le bon en fonction du contexte… ❌

• Je ne souscris pas non plus au discours dogmatique selon lequel : “l’approche traditionnelle c’est mal, agile c’est bien” ❌

• En résumé : ces 2 discours sont trop simplistes !

• Je partage dans cet article un certain nombre de nuances 😊

Le discours démagogique : “agile ou traditionnel, tout dépend du projet”

On entend souvent ce discours, notamment dans la bouche de ceux qui défendent la gestion de projet traditionnelle : il ne faudrait pas opposer approches agile et traditionnelle, ce serait deux trousses à outils distinctes et toutes deux pertinentes.

⚠️ Je ne cautionne PAS ce visuel !
Il est donné à titre d’exemple pour illustrer ce premier type de discours.

Je ne vais pas rentrer dans le détail en prenant un par un les arguments pour expliquer en quoi ils me semblent au mieux simplistes, au pire fallacieux.

Je me contenterai de dire ceci :

Désolé, mais non. Ca ne se passe pas comme ça dans la vraie vie. 🤷

Le discours dogmatique : “traditionnel c’est mal, agile c’est bien”

On entend souvent aussi ce discours, cette fois plutôt dans la bouche des agilistes : les preuves ne manquent pas pour démontrer les soucis de l’approche traditionnelle, et c’est pourquoi les approches agiles ont été inventées. Bref, agile c’est mieux.

⚠️ Je ne cautionne PAS non plus ce visuel !
Il est également donné à titre d’exemple pour ce deuxième type de discours.

Mes propos de la section précédente peuvent suggérer que c’est ce que je pense.
Et bien, oui et non.

Sur le fond, oui c’est ce que je pense. Et il est vrai que les preuves ne manquent pas pour démontrer les soucis de l’approche traditionnelle, et que l’approche agile fonctionne mieux.

Néanmoins, sur la forme, ce discours est dogmatique et surtout simpliste. Ce qui le rend maladroit et contreproductif. Et c’est aussi un peu faux car on fait un mélange des genres.

Plus globalement, cette manière d’expliquer et d’amener les choses manque de beaucoup de nuances, que je vais apporter dans la section suivante.

Le vrai ennemi : faire n’importe quoi

On aime bien faire des versus pour faire passer des messages — que cela soit pour dire que agile et traditionnel sont différents mais complémentaires, ou pour dire que agile est mieux que traditionnel.

Pourtant, le vrai ennemi, celui qui mériterait réellement d’avoir son versus, c’est de faire n’importe quoi, comme le fameux Larrache. 1

Je me permet donc de refaire un visuel explicatif traditionnel vs agile, qui cette fois appuie plus sur la similarité des deux que sur l’opposition, tout en appuyant sur les difficultés et les nuances pour bien appliquer les approches :

• D’un côté, on n’est pas sensé faire un projet traditionnel sans jalons, sans cycles, sans validation au plus tôt, sans gestion de risque dynamique. En somme, sans gestion de projet !

• De l’autre, l’excellence technique, la qualité et la discipline sont les prérequis qui permettent les itérations rapides promues par l’agilité.

Il n’y a aucune opposition 🤔

Si ce n’est une opposition à faire n’importe quoi : sans cadre, sans logique, sans boucle de feedback ou sans expertise.

L’approche traditionnelle EST agile

Ainsi, plutôt que d’opposer les approches traditionnelle et agile, ou de les considérer comme à destination d’usages différents, je préfère dire que, bien faits, on parle de la même chose. Même si parfois le vocabulaire varie.

Quand Tesla met en production entre 27 et 40 modifications par modèle et par jour, dans du hardware, dans une industrie réglementée et hautement complexe avec de nombreux sous-traitants, alors comment justifier qu’un quelconque projet logiciel pourrait durer un an, un trimestre ou même un mois sans avoir de jalon intermédiaire, de démonstration réelle ou de boucle de feedback ?2

La gestion de projet est agile par défaut

On pourrait penser qu’en écrivant que les approches traditionnelle et agile sont la même chose je risque m’attirer la foudre de la communauté des chefs de projets. C’est tout l’inverse : la gestion de projet moderne utilise le même vocabulaire que l’agilité et a les mêmes points de référence.

Par exemple, le PMI, le Project Management Institute, a complètement adopté l’agilité depuis longtemps déjà :

• Le PMI sponsorise des événements agiles, et d’ailleurs la Agile Alliance a rejoint le PMI

• Le PMI a fusionné avec DAD, Disciplined Agile Delivery, qui propose peut-être bien la meilleure source d’information sur l’agilité — disponible sur le site du PMI ! 3

• Ou encore le PMBOK, Project Management Body Of Knowledge, fait la part belle à l’agilité comme une évidence depuis des années

Pour aller au bout de l’argumentaire, j’ajouterais que le cycle en V est censé fonctionner… En cycles 🤷

On oublie très souvent que Winston Royce, auteur d’un article souvent mis en avant comme la référence décrivant le cycle en V, dit lui-même dans cet article que :

• L’approche en cascade (waterfall) ne marche pas, et

• Qu’une approche itérative est dans tous les cas nécessaire.

Le vrai problème de l’approche traditionnelle mal faite reste donc l’absence d’itération et de boucles de feedback. On pourrait arguer que des sprints Scrum comme autant d’itérations de cycle en V, c’est un mode de fonctionnement qui marcherait. 4

L’argument recevable : le coût du changement

Reste un argument que je veux bien entendre :

“On a toujours fait comme ça, et c’est trop risqué d’essayer de changer nos manières de faire au vu des délais courts du projet.”

OK. Admettons que l’on soit sur un projet avec des contraintes fortes, notamment en temps, qui ne nous permettent pas d’envisager de sereinement tester de nouvelles manières de travailler sans mettre en péril le projet.

Je peux totalement comprendre que l’on se dise alors, dans cette situation : “ce n’est pas le bon moment pour apprendre à mieux travailler.”

J’ajouterais même que c’est super d’être aussi clair, tant que c’est bien de la lucidité et pas une excuse pour ne jamais essayer de s’améliorer.

Ca s’appelle la conduite du changement. Un moment pour chaque chose.

Tant qu’on n’utilise pas cet argument pour se complaire dans la médiocrité, bien entendu.

On parle souvent de offsite, déjà parce que ça sonne toujours mieux en anglais 😉, mais aussi et surtout parce que le mot “séminaire” est souvent associé à un événement insipide où la direction passe des grands messages corporate et où les ateliers de team-building sont plus infantilisants qu’autre chose.

Non, je veux parler ici de vraies sessions d’ateliers, qui visent à résoudre des problèmes que l’on arrive pas à adresser via le quotidien.

Voyons ensemble pourquoi ce type d’approche est pertinente, puis ses limites.

Pourquoi c’est pertinent

• Parce que cela permet de rassembler physiquement des personnes qui ne se croisent que rarement voire jamais. Cela permet de créer du lien et de l’empathie, des éléments qui vont grandement faciliter la suite de la relation.

• Parce que cela permet de voler du temps aux participants. Leur quotidien est rempli de réunions et d’urgences du matin au soir. Dans ces conditions, pas étonnant qu’on n’arrive pas à adresser les problèmes de fond. Ce type d’événement permet de se poser, de prendre du recul et de réellement travailler sur ce qui compte.

• Parce que cela pose un cadre propice à la réflexion. On n’est pas en train de courir d’une réunion à une autre, la tête pleine de ce que l’on faisait avant, de ce qui va suivre, et de ce qu’on sait qu’on doit gérer et qu’on se demande bien quand on trouvera le temps pour les traiter. Au-delà de cette charge cognitive réduite, on a également la possibilité de se concentrer pendant des créneaux plus longs et donc d’aller plus en profondeur, de creuser vraiment les sujets.

• Enfin, on amène un cadre positif, propice à la remise en question et au travail en groupe.

Tout pris en compte, c’est un super outil qui peut vraiment débloquer pas mal de situations.

Bien fait, c’est toujours un succès.

Cela améliore toujours les choses… du moins, à court terme !

Le piège : ne pas réussir à aller plus loin

Ce type d’événement est libérateur et est parfait pour donner une impulsion.

Néanmoins, et comme on peut s’en douter, si l’on se contente de cette impulsion, alors elle va progressivement s’essouffler puis on va revenir sur la situation d’origine.

Finalement, le plus dur reste encore à faire : changer réellement les manières de travailler, en profondeur et de manière pérenne.

En tirant le trait, c’est toujours la même histoire : combien d’ateliers, de rétrospectives ou de post-mortems on donné lieu à des discussions passionnées et à des plans d’actions brillants, pour finalement ne pas être mis en place ou alors de manière uniquement transitoire ?

Quelques éléments clés qui manquent souvent pour pérenniser :

• Une démarche qui s’appuie sur la mesure qui permet de voir et pérenniser la progression

• Un véritable ownership des actions, et un suivi de ces dernières

• Une reconnaissance des gains du changement, une communication sur ces derniers

• Un espace pour continuer de penser autrement, comme on a pu durant l’offsite en changeant de lieu — ce qui avait posé un cadre permettant au cerveau d’être plus ouvert ou de penser autrement.

Bon… Cette liste est un peu de la conduite du changement plan-plan, mais en même temps : c’est bien ça le sujet !

J’ajouterais un autre point qui manque souvent : une évolution du cadre pour encourager et rendre naturelles les nouvelles dynamiques.

Par exemple, on crée de nouveaux rôles avec des dynamiques inédites au sein de l’organisation. Une fois qu’on a validé que cela fonctionne et apporte des bénéfices lors des premiers pilotes, il faudrait intégrer cela côté RH au niveau des fiches de postes, recrutements et parcours de carrière. Les officialiser, les reconnaitre et les entériner. 👑

Ou encore, on expérimente avec le flux de travail d’une équipe. Une fois qu’on a validé que cela permettait de trouver de meilleures manières de travailler, il faut trouver le moyen de continuer à expérimenter par la suite via une gouvernance qui facilite les évolutions du flux de travail. Difficile s’il faut faire le tour de la terre (ou faire un séminaire) à chaque fois que l’on veut essayer de nouvelles choses. 🤷

Dernier exemple, on change radicalement les dynamiques entre deux entités, historiquement en mode client/fournisseur, pour intégrer une plus forte collaboration et insuffler une dynamique de gestion de produit interne. Mais tant qu’on n’a pas toucher au modèle financier derrière, à comment les entités refacturent entre elles, cela repose uniquement sur leur bonne volonté, qui finira par s’étioler. 💸

Parfois, on a besoin d’un déclic profond pour passer au niveau supérieur. Comme…

• Le fait de faire des releases plus souvent pour réduire le nombre d’incidents (c’est évident une fois qu’on a le vécu qui le démontre, avant ça c’est totalement contre-intuitif)

• Passer d’un mode de fonctionnement entre équipes où l’on se donne du travail à faire pour passer à du self-service où la réalisation du travail est automatique (clé pour que les équipes plateforme ne soient pas des bottlenecks, très dur à envisager sans l’avoir jamais mis en place ou vécu)

• Ne plus faire valider le travail par les métiers, mais rentrer dans une démarche dite de shift-left où l’on travaille et valide le plan de test avant le développement pour prendre à sa charge le fait de valider le travail (cela semble logique sur le papier mais on n’imagine pas comment ça peut marcher en pratique, comment on peut accepter que cela soit mis en pratique)

Des journées d’atelier permettent d’oser concevoir et tester des manières très différentes de travailler. Mais là encore il faut les légitimer ensuite pour que cela puisse devenir le “nouveau normal”.

Croire qu’améliorer le relationnel suffit

J’aime bien citer cette maxime attribuée au Lean selon laquelle :

Face à une situation difficile, le relationnel se dégrade rapidement. Les résultats ne sont pas au rendez-vous et on commence à s’insulter ou à s’accuser mutuellement.

Le réflexe est alors de vouloir améliorer ce relationnel, en perdant de vue que ce mauvais relationnel est la conséquence d’un mauvais opérationnel.

Sans amélioration de l’opérationnel, toute amélioration du relationnel ne sera que superficielle et ne perdurera pas.

Bien sûr, les séminaires ont leur utilité, car cela ne peut qu’aider à améliorer le relationnel, mais sans jamais le réparer réellement car le problème est bien dans l’opérationnel.

Ca peut aider… Mais juste à démarrer, quoi. 😊

La politique.

Il y a ceux qui la fuient, que ça gonfle ou révulse.

Et il y a ceux qui s’en accommodent et qui apprennent à la naviguer tant bien que mal.

(Il y a peut-être même ceux qui aiment ça et qui y prennent un malin plaisir, mais ce n’est pas le sujet de cet article.)1

🪧 Dans cet article j’aimerais creuser le sujet de la politique en entreprise :

• Pourquoi c’est normal d’en avoir, et

• Pourquoi il ne faut pas en avoir peur !

Propre à tout écosystème sociétal complexe

On trouve de la politique dans quasiment toutes les entreprises.

On pourrait penser que ce serait lié à une certaine toxicité de ces entreprises en particulier, voire même du monde professionnel dans son ensemble.

La réalité est à la fois bien plus simple et sans jugement. Toute organisation humaine forme une société qui développe au fil du temps un véritable écosystème. Plus cette organisation grandit, mais également plus elle vieillit, alors plus la complexité de son écosystème augmente.

On retrouve alors des dynamiques similaires à celles que l’on trouve dans une société civile, avec ses règles sociales, ses lois juridiques et son économie. Bien sûr, ce ne sont pas les mêmes règles et dynamiques, mais la structure générale est similaire. C’est donc sans surprise que l’on y retrouve également cette fameuse politique.

Autant dire qu’elle est inévitable et qu’il vaut mieux s’y faire.

Il est également important de se défaire de l’idée selon laquelle est serait négative ou problématique : la politique est le résultat d’un écosystème complexe, qui a suffisamment réussi pour dépasser l’étape de la simplicité.

La similitude du marketing interne avec le marketing tout court

Effet de bord : que l’on soit au sein d’une organisation ou au sein de la société civile, les dynamiques son similaires.

Faire du marketing interne c’est pour l’essentiel de faire du marketing tout court, avec potentiellement les mêmes outils, les mêmes démarches et les mêmes astuces.

• Bien entendu, on s’adapte à la culture et aux règles sociales de l’organisation. Mais c’est vrai pour n’importe quelle audience.

• De même, on promeut des services dans le cadre des règles économiques qui sont posées dans l’organisation. Là aussi, c’est ce que l’on ferait pour adresser n’importe quel marché.

Finalement, le plus important ici, c’est de ne pas traiter le marketing interne comme annexe.

Une compétence clé à développer… Même quand on est désintéressé

On vient de voir que c’était normal. On peut vouloir fuir un contexte très politisé mais il faut alors bien être conscient que le problème n’est pas dans cette tendance à la politique, mais dans notre propre inconfort à la gérer.

On n’est pas tous à l’aise avec ça. (qu’il s’agisse de la politique ou de la conduite du changement)

Certains détestent toute cette gymnastique mentale pour en permanence convaincre les autres et développer sa propre influence, quand d’autres s’y font voire en tirent une certaine fierté.

Attention : on ne tire pas la fierté de faire de la politique ou de manipuler les autres. On tire de la fierté d’avoir réussi à faire bouger le système !

Je ne peux donc que vous enjoindre à vous habituer à la politique et à vous entrainer à être confortable en sa présence, si vous désirez avoir de l’impact.

Bonus : SAFe n’adresse pas la complexité des produits mais celle de l’organisation (et sa dimension politique)

En bonus, je vous partage l’extrait d’un échange par commentaires interposés sur LinkedIn :

[…] SAFe ne fonctionne pas, et c'est pas parce qu'il est forcément mal appliqué, c'est surtout parce qu'il est mal conçu pour répondre à la complexité
— Bruno Carlyle 2

Ne nous trompons pas sur SAFe : la complexité numéro 1 qu'adresse SAFe n'est pas celle des solutions et produits que construisent les équipes, mais celle de l'organisation, de la dette technique et de la conduite du changement. […]
— Jean-Pierre Lambert 3

Lors de l’évaluation d’un cadre de travail, on a tendance à se focaliser sur son efficacité opérationnelle, en négligeant sa capacité à se faire déployer dans un contexte donné.

Je n’ai jamais été fan de SAFe mais à l’aulne du niveau de politique intrinsèque d’une grande organisation, j’ai du mal à ne pas considérer SAFe comme un choix logique et cohérent.

J’ai également longtemps tenu le discours selon lequel le grand drame de SAFe n’aurait pas été son choix et son déploiement initial, mais plutôt l’enfermement dans ce dernier par la suite. Alors que le framework lui-même promeut de l’amélioration continue qui pourrait, dans la durée, remettre en question SAFe au fil des changements progressifs !

Je réalise aujourd’hui que pour en arriver là, il ne suffirait pas de faciliter d’une main de maître des sessions de Inspect & Adapt en prenant une vue systémique. Il faudrait littéralement réduire la complexité intrinsèque de l’organisation ce qui est un travail extrêmement difficile. Pas étonnant alors que cela n’arrive que si rarement.

“Outcomes > Outputs” c’est un meme popularisé notamment par John Cutler. 1

Toute la communauté agile adore ce concept. Bien sûr la communauté produit adore aussi si ce n’est encore plus. Cela résonne dans tous ces cœurs qui ne demandent qu’à avoir de l’impact, et qui dénoncent l’existence omniprésente des “Feature Factories”, un autre élément introduit par le brillant John Cutler. 2

Aujourd’hui, je viens à contre-courant pour annoncer que c’est faux, que les outcomes ne sont pas plus importants que les outputs, et que c’est même souvent l’inverse.

Bien sûr, je vais expliquer ce que j’entends par là et étayer mon point de vue 🙂

La véracité d’un argument est secondaire

En préambule, je veux articuler un état de fait qui va crisper les plus cartésiens d’entre-nous : pour beaucoup de monde, peut-être même pour la majorité, ce n’est pas la véracité d’un argument qui le rend convaincant. 😬

Bien sûr, ce n’est pas conscient : personne ne va vous regarder en face et vous soutenir qu’un argument fallacieux bien amené le convaincra plus qu’une réalité mesurée. On aime tous croire que nous sommes rationnels.

Dans les faits, c’est par exemple le niveau de storytelling qui va convaincre, le fait de raconter une belle histoire qui embarque le public, et encore plus si le public peut s’y identifier. C’est un véritable art, une compétence qui s’acquiert. On peut aussi parler d’éloquence ; l’éloquence d’une personne pouvant être pour une bonne partie décorrélée des propos en tant que tels.

Plus fort encore, vous pourriez vous retrouver à énoncer des faits irréfutables à une personne et elle vous répondrait en vous regardant droit dans les yeux :

“j’entends ce que tu dis mais je n’y crois pas”

Ou voire même, tout simplement :

“je ne suis pas d’accord”

Certes, il peut s’agir ici de mauvaise foi.

Cela peut aussi être un mécanisme du cerveau en pleine action pour donner du sens à des éléments contradictoires : si ce que vous annoncez à votre interlocuteur va à contre-sens de ses enjeux, une manière inconsciente de son cerveau pour les réconcilier est de refuser purement et simplement ce que vous énoncez. Ce n’est pas de la mauvaise foi mais un fonctionnement nominal du cerveau.

Les outputs convainquent plus que les outcomes

Pourquoi ce préambule ?

Parce que dans l’opposition entre outputs et outcomes, il y a l’idée que les outcomes changent le monde, ont un véritable impact, quand les outputs sont des éléments dont l’impact réel sur le système n’est pas établi.

Un outcome est un impact réel quand l’output n’a pas nécessairement d’impact. Pour convaincre un interlocuteur de la pertinence d’une démarche :

• Si la démarche a généré des outcomes alors c’est un fait établi qu’elle a de l’impact

• Si par contre la démarche n’a généré que des outputs alors prétendre qu’elle a eu de l’impact est un argument potentiellement fallacieux

… Et vous voyez peut-être ici le cœur du raisonnement que je vais énoncer : des outcomes ne convainquent pas nécessairement plus que des outputs.

En réalité, des outcomes sont souvent moins convaincants que des outputs car à la fois moins visibles et plus longs et difficiles à obtenir.

De la visibilité des outputs

Voici un exemple pour illustrer ce propos : imaginons que vous ayez organisé et animé avec succès un atelier d’équipe qui vise à dénouer un point dur, par exemple autour des rôles et responsabilités.

• D’avoir fait cet atelier est un output.

• Le nombre de participants à cet atelier est un output.

• Que ces personnes soient contentes d’avoir fait cet atelier est aussi un output.

Quel outcome par contre ? Très difficile à mesurer en sortie de l’atelier. Toujours pas évident à mesurer quelques mois plus tard. Probablement même que s’il y a un impact, il ne tiendra pas uniquement à cet atelier sur les rôles et responsabilités.

Malgré tout, cet atelier, cet output est très visible. Visible dans les agendas, visible dans les feedbacks des participants qui en sont ressortis satisfaits et reboostés, visible auprès des autres personnes à qui les participants en ont parlé ensuite.

Outputs + outcomes = 💖

Bien sûr, opposer outputs et outcomes est trop simpliste.

Si je suis en train d’expliquer que les outputs permettent de promouvoir bien plus efficacement une démarche que les outcomes, ne nous leurrons pas : au bout d’un moment il faut bien entendu avoir des outcomes. Sinon, ça va bien finir par se voir que tout ça, c’est du flan. 🤷

⚠️ Attention à ne pas se focaliser uniquement sur les outcomes : le risque serait trop grand de ne pas mettre assez en visibilité la démarche entreprise… Et de ne pas avoir l’opportunité de convaincre avec ces outcomes. 3

⚠️ Attention à ne pas se focaliser uniquement sur les outputs : tôt ou tard, la démarche va être arrêtée car sans ROI clair. 4

Le risque du désalignement sur les outcomes

Un autre problème des outcomes, et qui explique pourquoi ils ne convainquent pas, c’est qu’ils s’appuient sur un référentiel de connaissance et de culture qui n’est pas partagé.

Par exemple, si vous me demandez comment mesurer l’amélioration de la performance d’une équipe, je vais vous parler des Flow Metrics et des DORA Metrics. Et je tomberai sûrement d’accord là-dessus avec pas mal d’experts.

Sauf qu’une amélioration du Lead Time de l’équipe de 32%, autant ça fait un super case study qui en jette, autant ça ne convainc pas une personne qui ne sait pas ce qu’est le Lead Time, ou qui ne comprend pas l’impact sur le business d’une amélioration du Lead Time.

Ce n’est pas simple. Il faut déjà ouvrir les yeux et se rendre compte que l’on n’a pas le même référentiel, que le Lead Time ça ne parle pas. Mais expliquer ne suffit pas : présenter l’étude DORA et utiliser l’argument “prouvé par la science” ne convainc pas nécessairement.

C’est normal. Ce qui se joue derrière une réduction du Lead Time, c’est la capacité à expérimenter plus. Quand on n’a pas encore eu le déclic que c’est la capacité à expérimenter plus qui permet de gagner de nouveaux marchés et d’en rester leader, les contre-arguments sont légions :

“C’est du réglementaire, on s’en fiche d’aller vite, l’important c’est que ce soit fait.”

“Je connais le marché et les utilisateurs, il suffit de faire ce que je dis.”

“Nous avons peu de concurrence sur notre marché.”

Si l’on vous sort ce genre de phrase, je vous souhaite bonne chance pour avoir l’air convainquant avec une amélioration du Lead Time. 5

Court terme vs long terme

Ce qui se joue est donc bien dans la temporalité :

• Avoir des outputs bien visibles et convaincants à court terme

• Avoir des outcomes compréhensibles à long terme

• Les outputs à court terme permettant d’accéder au long terme nécessaire pour les outcomes, mais aussi d’acculturer pour que ces outcomes soient reconnus

Ainsi, une bonne stratégie doit avoir en tête ces deux temporalités. On pourrait parler de front room et de back room, ou en français d’un côté ce qu’il se passe sur scène et de l’autre ce qu’il se passe en coulisses : 6

• On doit en permanence avoir des choses visibles sur scène, c’est ce qui assure la pérennité de la dynamique de transformation…

• Et qui laisse le temps de construire des choses en coulisses, qui mettent du temps à être mis en place mais surtout à porter ses fruits.

Avec de l’output on ménage le temps d’avoir de l’outcome.

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 :

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 :

1. 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.

2. 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.

J’ai adoré comment elle a amené ce propos de manière abrupte, avant de l’étayer de ses expériences dans des rôles comme DSI. Car oui, cela ne sert à rien d’essayer d’enjoliver la réalité : être DSI, c’est-à-dire travailler dans la tech d’une entreprise dont le domaine métier n’est pas la tech, c’est fondamentalement ingrat — et il faut être OK avec ça, ou changer de métier ou d’entreprise.

Les discussions tournaient autour du rôle de DSI car il est représentatif, et cela correspondait au public cœur de l’événement. Ces propos sont une excellente piqûre de rappel. Néanmoins, pour moi, ils s’appliquent plus largement, au-delà du cas du rôle de DSI.

Les entreprises qui ne vendent pas de la tech

Tout d’abord, quand on dit DSI on pense à des entreprises déjà établies. Or, de mon expérience, ces propos s’appliquent tout autant en start-up et en scale-up. J’ai notamment connu de l’intérieur :

• WeMaintain, qui révolutionne le marché de la maintenance des bâtiments

• Stairling, qui crée un nouveau modèle salarial à la faveur des travailleurs indépendants, notamment les VTC

Start-up oblige, la tech est clé dans ces entreprises. Une de leurs forces est justement de s’appuyer sur la tech pour développer un business model et des propositions de valeur innovantes.

Pour autant, tout ce que nous a partagé Joanne fait totalement écho aux dynamiques de ces start-ups. Logique : dans ces start-ups aussi, le tech est une fonction support au service des métiers, de ceux qui font tourner la boutique.

Je n’énonce absolument pas cela comme un problème. Comme l’a si justement dit Joanne : c’est ingrat, c’est comme ça, il faut en être conscient et l’accepter.

À une époque j’aimais bien dire qu’il y avait en France une certaine perception selon laquelle “la tech, c’est sale.” J’en blaguais en disant que lors d’un dîner de famille c’était presque honteux d’avouer travailler du côté des développeurs, quand les chefs de projet et autres MOA étaient vu comme la tête pensante, comme la partie noble du travail. J’en rajoutais peut-être un peu en disant ça… Et en même temps cela illustrait bien cette vision rétrograde où le métier de développeur était perçu comme un exécutant, le fameux pisseur de code.

Depuis, j’ai bien sûr fait évoluer ma vision des choses. Mais surtout, cette vision de rôle ingrat évoquée par Joanne est bien plus nuancée et juste.

Le rôle de la tech est essentiel : ce n’est pas un business tech mais le business repose sur la tech ; sans tech il n’y a plus de business. Pour autant le rôle restera toujours ingrat, culturellement et en pratique.

On peut construire une dynamique où l’on n’est pas en rôle d’exécutant, mais n’espérons pas devenir la tête de proue.

Un rappel de tous les jours…

Honnêtement, cet état de fait est une bonne chose.

Car ce qui fait la différence entre une fonction support qui a sa place au COMEX, et une fonction support qui ne l’a pas, c’est la capacité à parler la langue du business, à comprendre ses besoins, à s’engager sur ce qui compte vraiment et à ne pas se défiler face aux difficultés : bref, à se comporter en véritable partenaire du business.2

Ou comme a pu le dire Arnaud Lemaire, alors CTO de la scale-up Sunday : ”Tech et Business, on doit être du même côté du flingue.” 3

Ce que l’on attend d’une fonction support pour mériter sa place au COMEX, c’est de jouer le même jeu que le reste du COMEX.

Qualité numéro 1 : fiabilité.

Être fiable. Oser s’engager, et tenir ses engagements 💪

Ne pas faire porter la responsabilité sur d’autres entités ou sur des prestataires en cas de soucis ; au contraire, assumer un ownership sans faille sur les résultats.

👉 Ses actions démontrent que l’on se sent concerné par le business.

Qualité numéro 2 : communication.

Être transparent, de manière compréhensible et au bon niveau 🧠

Ne pas rajouter une charge mentale de plus au mais au contraire construire une abstraction qui marche : on articule clairement ce que ça apporte au business, et les conditions nécessaires pour y arriver.

👉 On ne parle pas le langage de la tech, mais le langage du business.

… Pour toutes les fonctions support

Ce partage de Joanne a continué de me trotter dans la tête. Non seulement j’élargis le constat à la tech en général et pas seulement aux DSI, je pense que cela s’applique également à l’ensemble des fonctions support.

Quand j’écris ça, je pense en particulier à un milieu que je connais bien : celui des Scrum Masters et coachs agiles. Depuis quelques années, ce sont des rôles en déclin, de moins en moins demandés, de moins en moins rémunérés.

Au-delà du renommage du rôle tellement est devenu chargé et connoté négativement, le changement que j’ai vu est l’exigence d’être redevable de résultats. C’est ainsi que c’est maintenant des rôles comme Delivery Manager qui ont le vent en poupe, pour au final faire la même chose — l’exigence de s’engager sur les résultats en plus !

J’ai donc envie de continuer le parallèle entre les propos de Joanne et ces rôles de Scrum Master et coach agile : on veut toujours de ces rôles, quitte à les renommer, mais surtout à la condition qu’ils soient pris dans le sens du business.

Je n’écris pas ces mots à la légère ni en reniant le fameux rythme soutenable si cher aux agilistes.

La réalité du terrain, c’est d’avoir des périodes de rush ou de crunch.

Ce qui fait la différence c’est :

• Comment les gérer de la meilleure manière possible, autant du point de vue des résultats que du respect des individus

• Comment faire en sorte que cela soit exceptionnel et non pas la normalité

• Comment faire passer en priorité les enjeux du business, sans tomber dans la toxicité

Mais tout ça, cela n’intéresse pas votre DG ou votre CEO. Voici ce qui l’intéresse :

Est-ce que tu peux faire que ça marche ?

Si votre réponse est oui, c’est tout ce dont il ou elle veut savoir.

👉 Comment ne pas devenir esclave de son agenda et réussir à consacrer le bon volume de temps à chaque catégorie de sujet.

Quand on est en bas de la hiérarchie d’une grande organisation, cela saute aux yeux dès lors qu’on ouvre l’agenda d’un “grand chef” : il n’y aucun créneau de disponible 🤷

On utilise ainsi souvent l’expression “avoir un agenda de ministre” pour parler de ces personnes qui semblent se faire aspirer par un tourbillon de réunions.

Spoiler : dans cet article, je n’aurai malheureusement pas la réponse miracle à cette situation. 😬

Explorons tout de même pourquoi on a ce type de situation pour essayer de la dédramatiser un peu, ainsi que quelques pistes pour la rendre plus vivable.

Comment arrive-t-on à avoir des agendas de ministre ?

Cela dépend de votre rôle dans l’organisation.

Dans un rôle de gestionnaire (direction / management), la personne gère des personnes et des budgets, et elle doit donc passer un temps conséquents à cadrer, aligner, suivre et accompagner ces personnes et budgets.

De plus, il n’est pas inhabituel que la personne en question doive également faire profiter l’organisation de son expertise. Que cela soit parce que son équipe est en cours de construction, ou tout simplement parce qu’il n’est pas possible de se faire épauler sur le sujet (pas le budget ou pas assez de charge pour justifier l’ajout d’une personne).

Et avec des personnes qui n’ont pas un profil de gestionnaire ?

On a le cas de figure du chef de projet ou du Product Owner qui se fait solliciter par la terre entière pour collecter diverses idées, exigences et autres doléances. En parallèle on demande aussi à cette personne de pouvoir tout expliquer sur le projet ou produit, ce qui fait qu’elle assiste également à de nombreuses réunions qui ne sont pas a priori de son ressort, mais on veut “rester dans la boucle” comme le dit l’expression.

On peut aussi parler de surcharge cognitive : ce qui serait gérable à l’échelle d’une seule équipe ou d’un seul projet, devient compliqué quand le périmètre grandit et que l’on se retrouve à devoir comprendre ou piloter le travail de plus de 20 personnes. D’une certaine manière, le rôle de la personne change pour devenir plus managérial… À condition qu’il y ait bel et bien des recrutements pour l’épauler. Souvent, on demande de faire plus avec autant…

Si je voulais être méchant, je rajouterai encore une autre raison à ce type de situation. Derrière tout ça, il y a aussi le plaisir de la personne. Elle a envie de faire ça, de venir à ces réunions, de contribuer à ces sujets. Potentiellement c’est sa bulle d’air dans son quotidien !

Alors elle ne les lâche pas, en plus du reste qui lui a été mis sur le dos.

La facilité de se laisser porter

Je me dois également de citer l’évidence, qui fera le pont avec la suite de l’article : la facilité que nous avons à procrastiner. Quand on vous met une réunion, ou qu’on vous propose de participer à un sujet, c’est facile de dire oui et difficile de dire non. C’est facile de se faire aspirer.

En soi, ce n’est pas problématique quand on vient d’arriver ; dans cette situation, finalement, ces réunions permettent a minima de prendre de l’information, dont on a désespérément besoin dans cette phase éponge où l’on essaie d’appréhender le contexte.

Sauf que voilà : arrive le moment où l’agenda commence à être plein. Alors qu’on devrait se libérer du temps pour prendre du recul ou travailler sur autre chose, et bien… Le réflexe est de suivre, en roue libre, le tunnel de réunion qui constitue la journée.

On est occupé, on parle, on travaille. On a l’impression d’être productif. On est fatigué en fin de journée. On rentre chez soi avec le sentiment du devoir accompli.

Mais en réalité… On s’est juste laissé porter, sans réfléchir.

Et si jamais, à un moment de la journée, on a eu un doute… Si jamais on a pensé à un sujet important qu’il faudrait passer en priorité… C’est là que la procrastination est entrée en jeu : pourquoi tout chambouler quand il est si facile de se laisser porter par les réunions qui sont déjà programmées dans son agenda ?

Mea culpa

⚠️ Attention ! Je ne suis pas en train de critiquer tous ces managers et directeurs qui passent leurs journées en réunion. Bien au contraire, je fais preuve d’empathie et je compatis pour eux. Car je suis moi-même victime de cette dynamique ! J’ai souvent vécu cette facilité à aller dans une réunion qui pourrait se passer de moi, plutôt que de me forcer à travailler sur un des sujets qui attendent dans ma liste de priorités.

Alors, que faire ?

Voici quelques conseils, qui n’ont rien de révolutionnaire 😉

Prendre de la hauteur, segmenter et fixer des cibles de répartition

Prenez du recul sur vos responsabilités et définissez un pourcentage cible de votre temps à consacrer à chacune d’elles, chaque semaine. Puis voyez comment en faire une réalité, potentiellement en libérant le temps qu’il vous manque.

C’est très sain : cela vous force à prioriser votre présence sur les différents sujets et donc à rentrer dans une logique de délégation plus forte. Ou même, à simplement lâcher prise sur des sujets qui n’ont pas ou plus vraiment besoin de vous mais que vous continuez de suivre par habitude, par plaisir ou par réflexe de contrôle.

Bien entendu, le plus difficile est de commencer par réussir à se poser pour réfléchir à cela, à tête reposée. Si vous n’arrivez pas à bloquer ne serait-ce qu’une heure pour vous isoler et faire un état des lieux de vos semaines, cela devrait en soi déjà être une sonnette d’alarme : vous êtes complètement sous l’eau et votre semaine est en mode pilote automatique.

J’insiste sur ce point, car prendre du recul fait partie de votre mission. Dit autrement, avoir du temps dédié à l’introspection, cela devrait faire partie de votre cible de segmentation du temps. Vous devriez décider, et mettre en place, un certain volume horaire, chaque semaine, consacré à ce type d’activités.

Parmi les autres activités à prévoir, pensez à ménager du temps par exemple pour…

• Le management de votre équipe : suivis individuel avec un focus humain, carrière et objectifs, mais aussi coaching ce qui peut nécessiter d’être très disponible

• Le suivi opérationnel : à ne pas mélanger avec le management, sinon l’opérationnel bouffe le management qu’on négligera mécaniquement

• La réflexion stratégique sur les objectifs et sur l’organisation pour les atteindre

• Les recrutements : identification des besoins, sourcing de profils, mise en place et affinage du processus, entretiens…

• La gestion des budgets : prévision, revue, négociation…

• Votre propre management : carrière, revue et atteinte de vos objectifs…

• Le management de vos pairs : suivi de leurs agendas respectifs, prise en compte de leurs besoins, organisation et synchronisation transverse

• Votre veille et votre formation : trop souvent oublié, et pourtant vous ne pouvez surtout pas vous permettre de négliger ça !

Et peut-être d’autres choses. Tout ça doit tenir dans votre semaine… En plus des réunions diverses et variées.

Justement, ces réunions : idéalement, vous arriveriez à les rattacher à ces différentes catégories de temps.

⚠️ Si une réunion ne correspond à aucune catégorie, posez-vous des questions.

⏱️ Si le total du temps de réunion pour une catégorie donnée dépasse le quota que vous voulez fixez, voyez comment réduire ce temps de réunion. Pour pouvoir ménager du temps pour le reste !

Bloquer du temps

Certaines de vos activités ne seront pas avec un créneau fixe car ce ne sont pas des réunions ; cela peut être du travail individuel, ou du temps de disponibilité par exemple pour votre équipe.

Attention alors à bien sacraliser ce temps et à ne pas l’utiliser à la moindre occasion pour autre chose, ou même pour souffler un peu (ce qui suggèrerait que vous n’avez pas intégrer vos besoins de pause dans votre quotidien).
Attention à cette fameuse procrastination !

Une stratégie bien connue consiste alors à bloquer votre temps dans votre agenda, même si dans les faits vous êtes disponibles pendant cette plage horaire.

Bien sûr, le risque de cette approche, c’est que vu de l’extérieur, vous avez toujours un agenda de ministre ! Ce qui m’amène au conseil suivant…

Partager son agenda

Partagez le détail de vos agendas, au moins avec vos proches collaborateurs. En ayant de la visibilité sur le temps de travail personnel que vous essayez de sacraliser, ils pourront ainsi vous faire des suggestions de créneaux plus éclairées.

Ainsi ce temps bloqué sert de tampon pour les activités qui comptent, sans se faire grignoter de manière incontrôlée.

Bonus : ils comprendront peut-être aussi mieux pourquoi votre agenda est plein en voyant son contenu ! 😅

Et vous ?

Et vous ? Réussissez-vous à décider du volume de votre temps à consacrer à chaque catégorie de sujet, et à ensuite une faire une réalité ?

C’est difficile, alors discutons-en ! 🤗

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 :

1. Parce qu’il faut se remonter les manches, il faut travailler dur et au niveau du système

2. 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)

3. 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 !