Se spécialiser

Une carrière passe souvent par une forme de spécialisation. En tirant le trait, on trouve les meilleures opportunités en étant le ou la meilleure de son domaine — et plus son domaine est une niche, précise, spécialisée, plus il est facile de tirer son épingle du jeu. 1

Maintenant, quelle spécialisation ?

• Plutôt en termes d’expertise ? Viser à être le ou la meilleure avec telle compétence, tel rôle, etc.

• Plutôt en termes de secteur ? Continuer à travailler dans le même secteur d’activité jusqu’à en connaître tous les rouages et subtilités.

Bien sûr, le jackpot, c’est de combiner les deux : expertise pointue dans un secteur bien précis. Mais il faut bien commencer quelque part, et potentiellement choisir si l’on développe son expertise sans prendre garde au secteur, ou si l’on se spécialise dans un secteur donné avant d’y développer son expertise.

Bien sûr aussi, chaque sujet est toujours bourré de nuances, et on peut développer une spécialité plus ou moins pointue, autant côté expertise que côté expérience sectorielle. Et en soi, avoir une forme de pluridisciplinarité est aussi un atout et peut constituer son unfair advantage différenciant.

La réflexion de fond reste la même : trouver sa niche et en devenir maître.

Le métier avant tout

Très souvent, l’expérience sectorielle est plus valorisée que l’expertise.

C’est à dire que l’on sera plus à l’aise pour solliciter quelqu’un qui sait de quoi on parle, sans être le plus efficace pour faire le travail, plutôt que l’inverse.

C’est évidemment réducteur. Déjà parce que sans aucune expertise, il sera compliqué d’arriver à destination ; et également parce que le coût de la dette technique accidentelle est réelle et peut être vite catastrophique. 2

En pratique, on a des groupes pluridisciplinaires combinant autant des experts du secteur (qui comprennent donc de quoi il est question) que des experts de la compétence (qui savent donc mettre en œuvre) et on s’attend à ce que tout ce beau monde se parle, à ce qu’ils travaillent de concert pour faire un truc formidable en combinant leurs spécialités.

Mais on sait aussi que pareille collaboration a ses limites. Pour commencer, c’est difficile ! C’est toute l’histoire du développement logiciel, avec des solutions qui finissent inutilisées ou qui tapent à côté du besoin, malgré l’implication d’experts métiers. 3 C’est aussi une des raisons du succès du No Code (et aujourd’hui, du Vibe Coding) : celle de permettre aux experts métiers de donner vie à leur compréhension du secteur sans passer par la très difficile et très couteuse collaboration avec des experts du développement logiciel.

L’externalisation des fonctions support

Une autre manière de voir les choses, c’est qu’on préfère recruter les personnes en lien avec le cœur de l’entreprise, et externaliser ceux et celles qui en sont le plus loin.

D’un côté, c’est normal. Les fonctions “cœur du réacteur” semblent tout simplement plus importantes, ce sont celles qui font littéralement tourner la boîte.

De l’autre, cela dénote d’une vue simplificatrice, qui parfois oublie que si personne ne fait le travail des fonctions support, alors les fonctions cœur ne pourront plus travailler et potentiellement l’ensemble de l’entreprise peut s’arrêter.

Il s’ensuit qu’une meilleure démarche ne serait pas de choisir qui internaliser et externaliser entre fonctions cœur et fonctions support, mais plutôt d’internaliser et externaliser avec parcimonie des deux côtés.

Cela semble facile dit comme ça. 😅
La réalité c’est que, mécaniquement, la partie cœur est perçue comme plus importante et donc aura plus de poids dans les discussions. Quand on doit choisir où allouer les recrutements et les budgets, il faut être bien plus convaincant quand on est côté fonctions support car son apport est par définition moins visible, moins connu, moins compris — dans le contexte de cette organisation. 4

Sans même parler du fait que les fonctions cœur sont perçues comme faisant entrer de l’argent, quand les fonctions support n’en feraient qu’économiser ! Ce qui était probablement vrai lors de la genèse des dites fonctions support : on créait alors des postes pour soulager et libérer du temps aux fonctions cœur. Cette perception joue aussi dans ce réflexe de favoriser les fonctions cœur, car l’impact de l’efficacité opérationnelle que peuvent apporter les fonctions support est souvent négligé ou incompris, sans même parler de cette hiérarchie implicite entre fonctions cœur et fonctions support. (tout commence par un assistant qui soulage de menues tâches à plus faible valeur ajoutée…)

L’effet de réseau

Au-delà des dynamiques de perception d’une expérience sectorielle vs l’expertise, il se joue un effet de réseau. C’est bien connu, le meilleur moyen d’accéder à de belles opportunités c’est le bouche-à-oreille. Vous avez travaillé avec quelqu’un, ce quelqu’un est content de vous et en parle à d’autres personnes, ces autres personnes pensent à vous quand ils cherchent un profil.

Cet effet de réseau est d’autant plus fort dans la dimension sectorielle que dans la dimension expertise. Il y a plus ce côté “le monde est petit”.

Mode facile ou mode difficile ?

Pris à l’échelle d’une carrière, se focaliser sur le cœur de métier d’une entreprise, en pratique sur un secteur d’activité bien précis, semble être le mode facile pour faire son trou et avoir de belles opportunités. Il n’est pas question de mettre totalement de côté les expertises, qui sont nécessaires. Il est question d’être conscient de l’importance accordée à la maîtrise du domaine métier, de sa culture, à ses enjeux, et de s’y immerger pour aller au-delà de l’expertise.

Il est difficile d’être plus convaincant, notamment sur un CV, qu’en ayant des années d’expérience dans le domaine en question. 🤷

Il y a de la place pour des personnes focalisées sur leur expertise, mais il faut être capable de démontrer sa capacité à s’approprier divers domaines métiers, ce qui n’est pas donné à tout le monde. Ou faire une double spécialisation : expertise spécifique dans un secteur d’activité en particulier — difficile de faire plus sexy lorsque c’est ce qui est recherché.

Ma propre carrière

Je raconte tout cela en ayant moi-même construit un parcours focalisé sur l’expertise plus que sur l’expérience sectorielle.

Je ne m’en plains pas, car chacune des étapes de mon parcours m’a construit et je n’en ai pas à rougir.

Toujours est-il que si je voyageais 20 ans en arrière pour parler au JP junior dans le monde du travail, j’essayerais de lui expliquer à quel point choisir un secteur d’activité en particulier aurait été un smart move.

Mais bon, le voyage dans le temps n’existe pas, alors je partage ça au reste du monde, aujourd’hui !

En même temps, en écrivant cela, je me rends bien compte que j’énonce un lieu commun. Plein de gens l’ont dit avant moi ! Néanmoins, avec le recul, je réalise que justement on me l’avait dit, de diverses manières, et que pourtant je ne le comprends que maintenant. 😬

J’ai mené pas mal d’échanges récemment autour de la remise à plat d’espaces Jira. Quelque chose m’a frappé, et c’est ce que je voulais partager aujourd’hui :

Une fois que les équipes, leurs périmètres et leurs modes d’interactions sont clairement identifiés, une fois que l’organisation est définie, la configuration de l’outil coule de source et est assez directe.

En quoi est-ce inhabituel

J’imagine qu’une fois dit comme cela, ça doit sembler assez évident.

Pour autant, tout au long de ma carrière j’ai assez rarement participé à des échanges avec ce type de dynamique quand on parle de Jira.

En général, on discute avec des experts Jira qui parlent de l’outil, avec :

• Soit une posture ouverte, tournée vers les équipes, mais focalisée sur l’outil : les questions tournent alors autour de comment configurer l’outil. Ce qui ne marche pas trop mal quand le bénéficiaire sait ce qu’il veut, avec tout de même le risque de mettre en place un grand n’importe quoi.

• Soit une posture fermée, tournée vers la gouvernance et l’homogénéisation collective. Au mieux, les questions prennent plus de hauteur et essayent de comprendre le besoin profond… Généralement pour expliquer au bénéficiaire qu’il n’en a pas besoin, qu’il devra se contenter du standard et que ça lui suffira bien.

Dans les deux cas, on ne se pose qu’assez peu les questions organisationnelles. On est en plein dans le syndrome du “Quand on a un marteau dans la main, tout ressemble à un clou” : ce sont des experts Jira qui se concentrent par réflexe sur Jira. 1

La notion d’équipe

Or, la dimension organisationnelle n’a rien d’évident.

Il y a de nombreux implicites dans Jira.

Par exemple, la notion d’espace (anciennement projet) est très liée à celle d’équipe. La recommandation par défaut de Jira c’est de fournir à chaque équipe son propre espace. Ce n’est pas une règle absolue mais cela devrait être la structuration dans la majorité des cas. Et comme pour bien comprendre les mécanismes de Jira il faut s’approprier sa philosophie, il faut donc avoir ce type d’élément en tête.

Sauf qu’en général, on parle d’équipe sans vraiment dire ce que c’est, sans le définir. Se dire simplement “on va créer un espace Jira par équipe” n’aide pas vraiment tant que l’on n’a bien compris ce qu’est cette fameuse équipe, au sens de Jira.

Bien entendu, cette définition d’équipe, au sens de l’imaginaire Jira, ne colle probablement pas avec toutes les “équipes” d’une organisation donnée.

On doit donc aller plus loin que cette simplification qui parle d’équipes sans définir ce que c’est.

De mon expérience, on doit alors poser des critères qui aident à définir et délimiter ce qu’est une équipe. On y voit…

• Une notion de rythme, de cadencement. Si on a plusieurs rythmes en parallèle, cela pose la question d’est-ce une ou plusieurs équipes.

• Une notion de pluridisciplinarité, d’un groupe de personnes capable de se saisir d’un ensemble de tâches. Si on a d’un côté des personnes capables de prendre en charge certaines tâches seulement et pas les autres tâches, et inversement pour les autres personnes du groupe, il faut alors se demander si c’est quelque chose que l’on veut changer ou si on est justement en face d’équipes distinctes.

• Une notion de métriques et de reporting, comme un bon moyen d’identifier si on est en train de mélanger des choux et des carottes. Les rapports par défaut donneront des informations pertinentes si on a une forme d’homogénéité dans le travail qui est inspecté par les rapports. Pour des activités très différentes, on ne regarde pas les mêmes métriques, on ne fixe pas les mêmes types d’objectifs, on n’utilise pas les métriques de la même manière. Si ces éléments de travail différents sont portés par des personnes différentes alors il y a peu d’ambigüité sur le fait qu’il s’agit d’équipes différentes.

Il y a aussi la notion la plus intuitive : un groupe de personnes qui travaillent ensemble. Finalement, c’est cet aspect qui aide le moins :

• Tout d’abord car ces groupes de travail sont imbriqués : on appartient à une équipe mais également au pôle qui contient cette équipe, ainsi qu’au département qui contient ce pôle, mais également à la division, à l’entreprise au global… Parmi tous ces niveaux, quel est le niveau à prendre et à considérer comme équipe ?

• Ensuite parce que de nombreux rôles sont au moins partiellement transverses et c’est alors dans leur nature d’appartenir à plusieurs équipes, ou du moins d’y contribuer. Il est très important d’expliciter ce point, car cela éclaircit instantanément les réflexions autour de ces équipes.

Actuel vs cible

Dans ces réflexions, il faut bien sûr faire la part des choses entre l’actuel, l’existant, et la cible, là où on veut aller.

Un bon exemple classique serait une équipe de type Scrum composée de plusieurs pôles d’expertise : conception, développement Front-End, développement Back-End, test. On pourrait se dire que chacun de ces pôles d’expertise a ses propres tâches et travaille comme s’il était sa propre équipe. Ils ont aussi leurs propres rythmes, avec une conception qui travaille surtout en amont des sprints, un développement Front-End qui construit une release par sprint, un développement Back-End qui livre en continu chaque jour, et le test qui vit une période intense à chaque fin de sprint, quelques jours avant la release et la démo.

Bien sûr, ce que je viens de décrire, est simultanément criant de vérité, fidèle à la réalité de nombreux contextes, et très éloigné d’une mise en œuvre canonique de Scrum.

On doit donc se demander, en toute honnêteté — il n’y a pas de mauvaise réponse possible — si l’on veut garder ce mode de fonctionnement, ou si l’on veut justement casser cette séparation forte entre pôles d’expertise pour se rapprocher d’un Scrum canonique, où l’équipe ne ferait qu’un pour atteindre son objectif de sprint, où le déploiement continu serait la règle pour tous, et où le test comme la conception deviendraient eux aussi des activités continues. Bref, se demander si on vise à n’avoir qu’une seule équipe ou si l’on est satisfait d’en avoir plusieurs.

Cela va sans dire, il ne suffit pas de se fixer une cible et de configurer Jira sur cette cible pour que magiquement cela prenne forme. Le minimum sera de partager la volonté d’aller vers cette cible, de la verbaliser, de s’aligner et de rentrer dans une démarche de changement. L’outil apportant alors un support critique aux nouvelles manières de faire — mais ne serait qu’un fardeau de plus si l’on n’a pas compris le changement qui était entrepris.

Réduire l’écart entre l’outil et la réalité

Pourquoi s’embêter avec toutes ces questions ?

Questions qui, pour l’œil néophyte, peuvent presque plus ressembler à de la philosophie ou à de la masturbation intellectuelle qu’à un vrai sujet à adresser ?

Tout d’abord, c’est en ne se posant pas ces questions et en se jetant aveuglément dans la configuration Jira qu’on construit des monstres. C’est comme cela que l’on finit avec un Jira qui frustre tout le monde et qui ressemble à une bureaucratie poussée à son paroxysme, plutôt qu’à un outil qui aide le collectif à être plus efficace, plus transparent, plus redondant — et avec des métriques pour effectuer un véritable travail d’amélioration continue, réflexif, basé sur des données concrètes sur comment on fonctionne.

Il se joue un enjeu de transparence et de congruence : l’outil doit refléter la réalité pour l’outiller avec succès, pour fluidifier le travail, et pour apporter de la donnée pour l’améliorer.

On se doit de suivre la philosophie de Kanban : tout d’abord représenter la réalité telle qu’elle est, puis ensuite voir comment l’améliorer, étape par étape. L’outil permettant d’avoir les données permettant de décider quelle est la prochaine étape, et de vérifier l’amélioration.

Manœuvre de Conway inversée

J’oserais même faire un lien avec la loi de Conway. Un outil qui ne reflète pas la structure de communication, et par extension l’organisation et ses manières de travailler, c’est la recette pour l’échec.

De même, en appliquant une manœuvre de Conway inversée2, on devrait passer par ces questions et les réponses devraient se voir directement dans la structure mise en place du coté des espaces Jira. On structure l’organisation cible, et les outils reflètent cette structure.

C’est l’idée de fixer le prix que ça coûtera avant de faire le travail, plutôt que de le découvrir après avoir fait le travail.

Le contraire de l’agilité ?

Ca peut sembler à contrepied de l’agilité, qui s’implémente souvent sous la forme de sprints ou autres itérations et une facturation au dit sprint. Dit autrement : on fait avec ce qu’on a, et on verra combien ça coûtera à la fin.

Je vous l’accorde, bien faite, cette approche non prédictive a le mérite d’être équitable, notamment en suivant cette maxime qui m’est chère :

“Tout travail mérite salaire.”

Bon… Après, cette approche peut aussi être mal mise en œuvre, avec une équipe qui travaille sur ce qui lui chante, et à la fin on a une facture salée et rien d’exploitable 🤷
#TrueStory

Travailler à budget contraint

Le contrepied de cette démarche, ce serait justement de fixer d’office le montant de la facture. On travaille directement à budget contraint.

Bien sûr, là aussi on peut mal mettre en œuvre cette démarche, et se retrouver avec un bon vieux forfait des familles, qui impose un périmètre fixe pour un coût fixe. (et tant qu’on y est — un délai fixe aussi !)

Bien mis en œuvre, par contre, c’est une approche redoutable.

Pour commencer, le premier bénéfice c’est la facilité de s’engager pour le client : il sait déjà combien il paiera !!! C’est bien plus facile à accepter que de ne pas savoir ce qu’on aura à la fin et de ne pas savoir non plus combien ça coûtera… 😕

Mais ce n’est pas tout. C’est un excellent moyen d’embarquer le client dans l’aventure agile de l’équipe. Le budget étant limité d’emblée, on se retrouve tôt ou tard dans la situation de devoir décider, arbitrer, prioriser, découper — le nerf de la guerre si je puis dire !

Attention au cahier des charges

Le danger réside dans le périmètre fixe qui prend la forme d’une spécification détaillée. C’est ce qui qualifie le traditionnel “forfait” qui est pour le moins casse-gueule si vous me permettez.

Pour les meilleurs résultats, mieux vaut partir d’un objectif. Quelque chose qui a du sens, qui a de la valeur. Surtout pas un cahier des charges.

Et là, tu comprends sûrement en quoi cette approche est complètement agile : Design To Cost, ça veut dire fixer le prix en avance, mais pour un périmètre qui n’est pas fixe.

Ca ne veut pas dire que seul le client prend des risques : si on ne lui garantit pas ce qu’il aura à la fin dans le détail (on ne s’engage pas sur le quoi ni sur le comment), on lui garantit par contre que son problème sera résolu (on s’engage sur le pourquoi, sur le besoin, sur l’objectif).

Les vrais critères d’acceptation

Ce qui tire la question de comment définir l’objectif et comment valider son atteinte !

Pour un objectif, cela peut prendre la forme de KPI et de cibles à atteindre sur ces derniers. On sait qu’on y est quand les compteurs indiquent tels niveaux.

Cette approche permet même d’envisager une logique d’intéressement au résultat : plus on explose la cible, plus on a une grosse prime.

Pour un problème à résoudre, on va plutôt se tourner vers des critères d’acceptation. Mais attention : de vrais critères d’acceptation. C’est à dire des scénarios, mais qui décrivent le problème de l’utilisateur, et non pas la solution.

Quelque chose qui soit lié au problème et à sa résolution, tout en laissant le plus de marge de manœuvre possible pour définir et mettre en œuvre la résolution du problème.

Bien sûr, à nouveau, l’enjeu est de ne surtout pas fixer le périmètre du travail à faire, et d’ainsi pouvoir tirer les bénéfices de l’agilité.

Avoir les bonnes discussions, prendre les bonnes décisions

Dans le modèle traditionnel, on suit cette boucle infernale qui ne fait que des perdants :

J’ai un problème à résoudre

→ Je demande combien ça coûterait pour le résoudre

→ La personne ou l’équipe ne veut pas se retrouver à s’engager sur un montant trop faible pour bien faire le travail, donc elle essaie d’envisager tous les cas de figure, tous les pires scénarios, bref elle gonfle son estimation (en toute bonne foi)

→ Je trouve que c’est trop cher par rapport au bénéfice potentiel donc je refuse
… Et je ne comprends pas pourquoi ce partenaire (potentiellement interne, potentiellement la DSI) est incapable de livrer quoi que ce soit en un délai convenable

→ La personne ou l’équipe a déjà investi du temps pour répondre à la requête initiale ; ce temps est purement et simplement perdu, sans bénéfice
… Et ils ne comprennent pas pourquoi on leur fait perdre leur temps

→ D’un côté comme de l’autre, la défiance se développe

En mode Design To Cost, on inverse tout, et cela génère énormément de dynamiques positives. Cela ressemble plutôt à ça :

J’ai un problème à résoudre

→ Je demande combien ça coûterait pour le résoudre

→ On me demande plutôt combien je serais prêt à investir pour le résoudre

→ Je fais des projections de bénéfices potentiels et j’identifie un budget cohérent avec le problème à résoudre

→ La personne ou l’équipe se positionne directement avec ce budget en tête et propose des solutions cohérentes avec le budget en termes de complexité, de robustesse et de complétude fonctionnelle

→ Nous travaillons ensemble pour affiner la solution, en gardant en tête les enjeux à résoudre et les bénéfices potentiels

Rien de plus agile, pas vrai ? 😊

Ce mode de fonctionnement favorise directement les discussions et la collaboration vers l’atteinte de l’objectif qui devient commun.

Plus facile à dire qu’à faire… Comme le Sprint Goal

J’ose espérer t’avoir convaincu du bien fondé de la démarche.

Maintenant, bien entendu, la difficulté reste dans la conduite du changement. Et là, ce n’est pas si évident !

Ce changement de penser objectif plutôt que périmètre n’est pas nouveau. La majorité des Scrum Masters s’y sont confrontés lors de la mise en place du Sprint Goal de Scrum : faire en sorte que l’équipe possède un objectif pour guider la construction et le déroulé du Sprint, plutôt qu’une liste de choses à faire.

Et c’est là qu’on touche du doigt tout ce qui rend difficile ce changement : quand on n’a pas une équipe pluridisciplinaire qui peut se positionner au niveau de la résolution du problème, mais un ensemble de personnes, spécialisées, qui ne peuvent s’engager que sur leur domaine. Dans ce cas de figure, cette notion d’objectif n’a aucun sens ; au mieux, elle est superficielle.

Si on sort du contexte de Scrum, le parallèle fonctionne toujours. Pour pouvoir s’engager sur la résolution d’un problème ou l’atteinte d’un objectif plutôt que sur un périmètre, il faut un dispositif qui soit au même niveau, à un niveau qui permet de résoudre le problème ou atteindre l’objectif.

Tout cela afin de pouvoir avoir une véritable discussion sur l’objectif.

La philosophie de Jira

Note : dans cet article, quand je vais parler de “Jira”, c’est un raccourci pour parler de “Jira delivery”, c’est à dire le Jira historique, qui permet de gérer le quotidien d’une équipe avec son backlog, ses work-items, ses workflows, ses sprints, ses releases (versions), ses tableaux, ses rapports et métriques.

Dans Jira, si vous voulez faire évoluer l’espace Jira de votre équipe, vous devez soit trouver un administrateur, soit être administrateur vous-même.

Pourquoi ?

La plupart des espaces Jira delivery sont dits “company managed” ce qui veut dire que les work-items et workflows sont partagés avec l’ensemble de l’instance Jira, et donc, pour les faire évoluer, il faut être administrateur au niveau global de l’instance Jira.

En théorie, il y a une solution à cela : faire des espaces Jira dits “team managed” dans lesquels un administrateur de l’espace peut modifier directement, en toute autonomie, les éléments de son espace. Sauf que ça ne marche pas en pratique, à moins que le travail à gérer soit quelque chose de simple — oserais-je même dire plutôt : quelque chose de simpliste ! 1

Les limitations des espaces “team managed”

❌ Pas d’hybridation possible, c’est tout ou rien. On ne peut pas avoir, par exemple, un modèle standard d’Epic ou d’Initiative pour l’ensemble des espaces Jira (dans une perspective de pilotage à l’échelle, même très léger) tout en gardant l’autonomie des équipes sur le reste de leur espace. Dès lors qu’on a un minimum d’enjeux d’harmonisation, d’agrégation ou de pilotage à l’échelle, le modèle “team managed” ne marche pas.

❌ Les outils mis à disposition des espaces “team managed” sont simplifiés au point de les rendre inefficaces. Voici par exemple le genre de choses que l’on peut faire en “company managed” et que l’on ne peut pas faire en “team managed” :

• On ne peut pas appliquer les pratiques Kanban en complément de Scrum. En “team managed” on doit choisir de manière exclusive entre “Scrum” et “Kanban”. Par exemple si on choisit “Scrum”, on a des sprints mais on n’a pas accès aux éléments du mode “Kanban”. Ces éléments sont pourtant cruciaux pour une bonne animation du quotidien de l’équipe, y compris une équipe Scrum, comme la visualisation du Work Item Age. (dans Jira, ce sont les petits points gris puis rouges qui sont ajoutés à côté de chaque carte)

• En “team managed”, la majorité des rapports Jira sont absents et ceux qui restent sont simplifiés : pas de CFD si vous avez choisi l’option “Scrum”, impossible d’avoir une vélocité basée sur le nombre d’éléments terminés…

• En “team managed” toujours on ne peut pas appliquer des filtres JQL arbitraires pour colorier des cartes du tableau ; une fonctionnalité un peu obscure mais extrêmement puissante pour implémenter du management visuel

Bref, les espaces “team managed” sont nerfés par rapport aux espaces “company managed”, tant et si bien qu’en “team managed” on est obligé de rester à de la gestion d’équipe pour bébé.

Une équipe a besoin de :

• Management visuel puissant

• Métriques et indicateurs pour piloter son quotidien

• Métriques et indicateurs pour piloter son amélioration continue

Choisir l’option “team managed” c’est s’interdire tout cela et donc rester dans la pataugeoire de la gestion d’équipe.

Seule issue : le “company managed”

… et donc, dépendre de l’administration centrale pour les changements les plus structurants aux espaces d’équipe Jira. 😭

Pourquoi ne pas distribuer le rôle d’administrateur ?

Justement parce qu’on parle ici d’administration de l’ensemble de l’instance Jira !

Ce modèle peut marcher mais devient une posture de plus en plus difficile à tenir à mesure que l’organisation est grande :

• Enjeu de ne rien casser : être administrateur de l’instance, cela veut dire pouvoir toucher à tout. Il faudrait donc former tous ces administrateurs ainsi que mettre en place les mécanismes de contrôle ou vérifications pour s’assurer qu’ils ne cassent rien. En soi, ce n’est pas impossible, mais on voit bien que ce n’est pas anodin de prendre cette posture.
  Surtout, rien n’est fait dans Jira pour faciliter la mise en place de ce type de gouvernance : ce n’est pas l’état d’esprit de Jira.

• Segmentation de l’information et des périmètres de responsabilité : un administrateur d’instance a accès à tout. Dans de nombreuses organisations on va vouloir éviter de donner accès à tout à tout le monde. On préfère plutôt segmenter l’accès à l’information ainsi que les périmètres de responsabilité.
  Parfois, c’est même une obligation par rapport à des contraintes d’audit et de traçabilité, sans même parler des projets confidentiels.
  Ce n’est pas juste une question de philosophie ou de culture d’entreprise, c’est une réalité.

Et les administrateurs d’espace ? Une autre voie sans issue

Techniquement, il existe aussi le rôle d’administrateur d’espace. On peut envisager donner ainsi une forme de liberté à une personne sur son propre espace sans lui donner les accès d’administration sur l’ensemble de l’instance.

Cette option vient avec son lot de contraintes. On reste sur du “company managed”, tant et si bien que ces droits d’administration d’espace apportent un bénéfice très limité et on se retrouve vite à devoir en référer aux administrateurs de l’instance Jira.

Voici un exemple de ces limites : on peut donner les droits à un administrateur d’espace de rajouter des champs à l’espace qu’il administre… À la condition que le champ existe déjà au global dans l’instance. Impossible de créer un champ complètement nouveau. 🤷

Pourquoi ce modèle a du sens (et ça me fait mal de l’admettre)

À date, je n’ai pas la recette magique pour permettre aux équipes d’expérimenter librement avec leurs processus dans Jira. Cela me fait mal au cœur et je sais à quel point cela peut rajouter de la friction à l’amélioration continue d’une équipe.

Je pourrais en conclure que Jira est le diable. 2

💡 Au contraire, j’ai découvert de la vertu à ce modèle !

Ce modèle vise à répondre aux enjeux suivants :

• Harmonisation et standardisation du delivery

• Pilotage collectif à l’échelle, nécessitant d’agréger des données et d’avoir des artefacts collectifs

À l’échelle on veut remonter des informations, certaines pas si évidentes que cela à calculer comme les DORA Metrics. Sans un minimum de standardisation, on se retrouve à devoir calculer ce genre de métriques de manière différente pour chaque équipe, projet ou solution… C’est coûteux, peu fiable, et surtout la mise en place est une charge supplémentaire qu’on impose aux équipes plutôt que leur donner les bénéfices de manière transparente, pour ainsi dire gratuitement. 3

Un compromis entre deux dimensions

On voudrait avoir :

• Un cadre qui permet l’autonomie des équipes pour expérimenter avec leurs processus et les adapter à leur contexte et enjeux

• Mais aussi un cadre qui permet le pilotage à l’échelle, une visualisation transverse, une standardisation d’un certain nombre de métriques, une capitalisation sur les intégrations avec d’autres outils, etc.

Idéalement, on voudrait avoir les deux.

En pratique, on voit bien la difficulté à les concilier. Et c’est là que se joue tout le parti pris des outils. Focus plutôt sur l’autonomie des équipes ou sur la capitalisation à l’échelle ?

Au-delà du focus, la question est plutôt : lequel favoriser en cas de conflit entre les deux ?

Le parti pris de Jira

Jira a pris le parti d’assurer sur la dimension capitalisation à l’échelle. Et honnêtement, difficile de les blâmer :

• Le pilotage à l’échelle est un enjeu qui touche le top management. En pratique, si on se retrouve dans une situation où l’on doit faire pencher la balance d’un côté ou de l’autre, les personnes qui ont le plus d’influence dans l’organisation iront toujours du côté du pilotage à l’échelle plutôt que du côté de l’autonomie des équipes.

• Au-delà de qui influencerait la décision, j’ai ce sentiment qu’il y a effectivement plus d’enjeux collectifs dans le pilotage à l’échelle que dans l’autonomie des équipes. Par exemple, un bon pilotage à l’échelle va éviter de construire la mauvaise chose ou d’accumuler des retards et des délais pendant des mois et de continuer sans s’en rendre compte.

• Pour tirer les bénéfices, l’outil ne suffit pas. Il faut aussi des personnes compétentes derrière. Plus facile de s’assurer qu’on a quelques personnes clés compétentes pour tirer les bénéfices du pilotage à l’échelle, que de se dire qu’on a des personnes compétentes dans toutes les équipes pour qu’elles tirent les bénéfices de l’autonomie. Je me rends bien compte en écrivant cela comment ce constat à l’échelle doit être frustrant pour les équipes très matures et compétentes à leur niveau.

• Plus globalement, l’autonomie des équipes est négociable, il existe de nombreux contournements et modes dégradés, alors que mal piloter à l’échelle n’est pas une option.

Une fois que j’ai dit tout cela, j’ai du mal à ne pas me ranger du côté de la philosophie de Jira.

L’élément clé : qui a été mis aux commandes

On va pouvoir reboucler avec le titre de cet article et la notion de dictature bienveillante.

Si le concept de dictature est généralement considéré comme négatif, notamment en l’opposant à la démocratie, sensée en théorie donner le pouvoir aux citoyens, le concept de dictature bienveillante nuance cette interprétation. 4

Dans une dictature, il y a un chef qui a tous les pouvoirs et qui décide de tout.

En effet, c’est souvent synonyme de tous les excès, et notamment l’oubli de la population, de l’économie, et globalement de tout le pays au profit du dictateur ou de la dictatrice et de sa famille. Les exemples de ce genre sont malheureusement légion.

C’est dans ce type de contexte qu’on oppose la dictature à la démocratie, qui en particulier consiste à mettre en place et soutenir des contre-pouvoirs. Pour autant, la démocratie est loin d’être parfaite, avec trop souvent des intérêts personnels qui viennent s’entre-mêler dans la politique, apportant des dynamiques d’immobilisme face à des changements essentiels à mener, en se focalisant sur le court terme des individus au détriment du long terme du collectif.

Le concept de dictature bienveillante, c’est une dictature où on aurait la bonne personne aux commandes, une personnes qui se focaliserait sur le développement du pays et l’intérêt de son peuple.

En théorie, en suivant cette logique, une telle dictature bienveillante apporterait de meilleurs résultats que la démocratie — plus efficace, avec moins de barrières à la mise en place de la vision bienveillante.

L’administration Jira entre les mauvaises mains

Le risque principal d’une dictature bienveillante, c’est bien sûr que si on a mis la mauvaise personne au pouvoir, si elle n’est justement pas bienveillante, auquel cas on subit le pire :

• Une administration Jira qui se focalise sur ses propres objectifs plutôt que sur les bénéfices pour l’ensemble de l’organisation et des équipes

• Une administration Jira qui veut tout uniformiser et ne laisser aucune marge de manœuvre aux équipes dans le but de se simplifier la vie

• Une administration Jira qui ne va pas voir sur le terrain la réalité des équipes

• Une administration Jira qui verrouille l’outil et suit des choix de conception qui rendent l’équipe d’administration indispensable pour la suite des événements

Il n’y a pas vraiment d’alternative à ces conséquences : les contraintes structurelles de Jira forcent une centralisation, et on est à la merci de la personne ou de l’entité au contrôle.

L’administration Jira en mode dictature bienveillante

Justement, ça donnerait quoi si, cette fois, on est dans une dictature bienveillante, avec la bonne personne au pouvoir ?

• Une administration Jira qui propose un standard pour accélérer le lancement de nouvelles initiatives et avec des partis-pris forts pour éviter les débats stériles avec les personnes non expertes qui veulent juste avoir un truc qui marche — tout en acceptant les spécificités des initiatives existantes

• Une administration Jira qui donne de l’autonomie aux équipes en s’appuyant au maximum sur du standard de Jira, plutôt qu’en mettant en place des modèles maison

• Une administration Jira qui va sur le terrain pour sentir les douleurs des équipes vis-à-vis de l’utilisation de Jira, qui fait preuve d’empathie avec ses utilisateurs, qui met un point d’honneur à les aider et à résoudre leurs problèmes

• Une administration Jira qui n’aborde pas les enjeux autour de Jira comme l’administration d’un outil mais avant comme des enjeux méthodologiques, Jira venant en soutien pour refléter et outiller la méthodologie mise en place

Evidemment, on trouve l’élément clé d’être user-centric, tourné vers ses utilisateurs et à leur service.

C’est une posture difficile car on demande d’être expert tout en gardant l’utilisateur en tête !

Qu’est-ce que cela implique côté choix du dictateur bienveillant ?

Réussir à suivre ce chemin de crête, cela n’est pas donné à tout le monde.

Pris dans l’autre sens, cela veut dire qu’il nous faut un de ces fameux moutons à cinq pattes pour structurer cette équipe d’administration, qui cumulerait de nombreux traits. Je pense par exemple à :

• Maîtrise de Jira — a minima ses concepts, et bien entouré par des experts pertinents

• Capacité à accepter les feedbacks et les remises en question : Jira permet tellement de choses qu’il faut pouvoir accepter les suggestions des experts

• Maîtrise de la gestion de projet, et des différentes approches, waterfall comme agile : comme dit plus haut, l’enjeu n’est pas directement au niveau de l’outil, mais au niveau de la méthodologie et de comment l’outil l’accompagne et la facilite

• Maîtrise de la gestion de portefeuille : même histoire, cette fois pour la dimension pilotage à l’échelle

• Véritable maîtrise de Scrum et de Kanban : pour aller au-delà de “un sprint c’est un ensemble de trucs à faire” et “Kanban c’est un tableau de suivi”

• Expérience du management visuel en contextes variés : pour réussir à se projeter sur comment en mettre en place dans le cadre très contraint de Jira

• Orientation métriques : un bénéfice essentiel d’un outil comme Jira est d’apporter des métriques à ses utilisateurs, il faut donc connaître les métriques principales, comprendre leur intérêt, comment les utiliser, et savoir former à leur utilisation

• Connaître la réalité des équipes, certainement en ayant travaillé soi-même dans ce genre d’équipe

• Avoir une bonne compréhension de ce qui fait la performance d’une équipe, de sorte à pouvoir avoir des discussions d’outillage qui tournent plus autour de la structuration organisationnelle qu’on veut accompagner que de Jira lui-même ; la structure dans Jira reflétant simplement et directement la cible organisationnelle

• Comprendre les dynamiques humaines autour des processus : comment les personnes reçoivent le changement, le jugent, se l’approprient — la conduite du changement !

• Être user-centric, savoir se projeter sur l’utilisation d’une application ou d’un système mais également oser aller voir les utilisateurs et accepter leurs retours

• . . .

Bien sûr, comme dans une offre d’emploi, il n’est pas nécessaire de tout maîtriser et à 100%. Néanmoins, on va quand même vouloir un panel significatif, ainsi que la capacité à acquérir ceux qui manquent.

C’est peut-être là où le bat blesse, et la raison pour laquelle on voit si souvent des implémentation de Jira qui traumatisent leurs utilisateurs :

Sans dire que c’est impossible, cela va sans aucun doute être rare, trop rare. 🫣

Connectons-nous !

En ce qui me concerne, je n’ai pas la prétention d’avoir toutes ces qualités, mais j’essaie.

Si tu es ou a été dans une position en capacité de mener une initiative Jira de grande envergure, j’aimerais échanger avec toi.

Pour savoir comment tu t’y es pris, ce que tu as mis en place et quels résultats tu as eu !

Les individus et leurs interactions plus que les processus et les outils

Vous avez la référence : il s’agit du premier des 4 piliers du Manifeste pour le développement Agile de logiciel, écrit en 2001 et qui sert de fondation à toute la communauté. 1

Cela nous dit que si les processus et les outils sont utiles, ils sont moins importants que les personnes et leurs interactions humaines.

Bien sûr, cette phrase résonne lourdement auprès d’une communauté presque traumatisée par l’hégémonie de Jira, un outil dont le modèle centralise et impose des processus aux équipes. 2

Et bien, de mon côté… 🤔

Le passage à l’échelle

Bien sûr, on va me rappeler que le Manifeste Agile ne dit pas que seule la partie gauche de la phrase importe, la partie de droite aussi ! Mais moins que celle de gauche.

Je vais me faire volontairement plus bête que je ne le suis : mais alors s’il faut la partie gauche et la partie droite, comment ajuster le curseur entre les deux ? De quel % faut-il de chaque ? 😏

J’ai l’impression que la réponse a cette question dépend notamment du niveau de mise à l’échelle.

Concrètement, plus on est nombreux et plus on a besoin de processus et d’outils. Dit autrement, plus on a besoin de formel. 3

Attention à trop d’autonomie : ce n’est pas le propos

J’ai entendu plus d’une fois cette phrase dans la bouche des équipes accompagnées, une phrase qui prenait à contre-pied l’anarchiste agile que j’ai pu être :

“Juste : dites-nous comment faire !”

Faudrait-il comprendre que les personnes veulent qu’on leur impose les processus et outils, sans les prendre en considération ? 🤯

L’explication derrière cette phrase est assez simple : on est face à des personnes ou des équipes qui ont déjà tellement à gérer sur leur cœur de métier, qu’elles préfèrent qu’on leur donne directement des solutions, clé en main, pour tout le reste.

Dit autrement : elles ont mieux à faire que de chipoter sur des processus et des outils, au contraire elles veulent qu’on leur libère de la charge mentale.

Il faut comprendre ça. Si vous leur libérez de la charge mentale, si vous leur simplifiez la vie, ce n’est pas intrinsèquement un problème de leur imposer des processus et des outils… Mais si à l’inverse vous leur compliquez la vie ou leur rajoutez plus de choses à penser, soyez persuadés que l’adoption va droit dans le mur !!! 4

La joie de la conduite du changement

Une mise en garde tout de même sur ce constat :

⚠️ Attention, cette phrase “donnez-nous directement la solution et on s’exécutera pour la mettre en place” est un discours qu’on entend avant qu’on leur donne des processus et des outils… Une fois dedans ça va sûrement chipoter quand même 😉

Il reste donc essentiel de mener une démarche de conduite du changement.
Et surtout, ce qui est mis en place, ça doit les aider !!! J’élabore cet élément plus bas. 👇

Ce n’est pas “plus que” mais “au cœur des”

Plutôt que de lire :

Les individus et leurs interactions plus que les processus et les outils

Je vous suggère de comprendre :

Les individus et leurs interactions au cœur des processus et des outils

Cette reformulation vise à appuyer que les processus et outils sont fondamentaux, que l’on ne peut pas s’en passer et que tout part toujours de là… Mais pour que ces derniers atteignent bien leurs objectifs, pour que les bénéfices se matérialisent, les individus et leurs interactions doivent avoir été pris fondamentalement en compte dans ces outils et processus.

Ainsi, en se permettant de changer plus la formulation, on pourrait même comprendre…

Pas de processus et outils utiles sans prendre en compte les individus et leurs interactions

Ou encore appuyer sur la dimension bureaucratique et en étant un peu plus acerbe :

Des processus et outils qui n’intègrent pas les individus et leurs interactions ne sont que de la bureaucratie

Bref, contrairement à ce que la formulation originale dans le Manifeste Agile pourrait laisser penser, les processus et outils sont essentiels, ils ne peuvent pas être remplacés par les individus et leurs interactions, mais il faut prendre en compte et intégrer les individus et leurs interactions dans les processus et outils pour que ces derniers soient pertinents et utiles.

Ou encore “facilités par”

Plutôt que de lire :

Les individus et leurs interactions plus que les processus et les outils

On pourrait comprendre :

Les individus et leurs interactions facilités par les processus et les outils

Cette fois, on part bien des individus et interactions. Mais on intègre les processus et les outils comme le media ou le terrain de jeu permettant de faire vivre, d’amplifier, de cadrer, de faciliter les individus et leurs interactions.

Ou même, de manière plus forte encore :

Les processus et les outils doivent faciliter les individus et leurs interactions

En particulier, les processus et les outils ne doivent pas remplacer des individus et leurs interactions qui apportent de la valeur. Au-delà de ne pas les remplacer, ils doivent les amplifier ou les rendre plus faciles à actionner ou à se matérialiser.

Trop de collaboration tue la collaboration

On peut avoir tendance à ostraciser les processus et les outils parce qu’ils tueraient la collaboration, la rendant plus difficile, moins naturelle, moins directe.

Sauf que cela repose sur l’hypothèse que plus de collaboration serait nécessairement bénéfique, forcément mieux.

Cette hypothèse est fausse. Loin de moi l’idée de renier l’importance de la collaboration… Mais point trop n’en faut.

La collaboration est un mode de fonctionnement extrêmement coûteux, et c’est pourquoi il est si difficile, pourquoi le réflexe est de travailler en solo.

Je ne suis pas en train de prêcher l’anti-collaboration : comme tous les sujets importants, c’est un chemin de crête, il faut réussir à avoir le bon niveau. Ni trop, ni trop peu.

User-centric et approche produit dans les processus et outils

Finalement, on est en train de philosopher autour de la différence entre les bons processus et outils, et les mauvais processus et outils. 😅 5

Plutôt que de discuter de la place des processus et des outils — les processus et les outils sont tout simplement fondamentaux — il est question de comment faut-il les concevoir, les mettre en place et les faire vivre : toujours en rebouclant avec les individus et leurs interactions.

Plusieurs concepts bien connus décrivent cela :

• Être user-centric, toujours se poser la question du point de vue de l’utilisateur, de ses enjeux, de ses bénéfices, de ses douleurs, de son usage, de ses habitudes… Plus encore, au-delà de prendre le point de vue de l’utilisateur, on vise à directement intégrer les utilisateurs dans tous ces aspects.
  Travailler avec les utilisateurs, les regarder travailler, mesurer leur usage, etc.
  Ne pas se contenter d’imaginer !

• On peut aussi parler d’approche produit pour bien articuler cette idée où l’on n’est ni en train de faire ce que demandent les utilisateurs sans le challenger, ni leur imposer de solution sans les consulter.
  On décide à la place des utilisateurs mais c’est leur usage réel et effectif qui permet de juger si on a pris les bonnes décisions ou pas et d’ajuster la suite.

Ces concepts sont utilisés dans le cadre du développement d’un produit, d’un service ou d’une solution. Ils s’appliquent tout autant à des outils et processus internes.

Quand on veut impulser un changement d’envergure, on envisage les différentes pistes, on réfléchit au chemin à faire prendre collectivement. Et on pourrait se demander :

Pourquoi ne pas implémenter directement la cible plutôt que de passer par des étapes intermédiaires ?

En soi, ce raisonnement tient la route : d’un point de vue apprentissage, travailler autrement nécessite de désapprendre la manière actuelle de faire puis apprendre la nouvelle manière de faire. Avoir des étapes intermédiaires, c’est autant de cycles désapprendre / apprendre qui rallongent la démarche.

Bien sûr, les étapes intermédiaires semblent naturelles lorsqu’elles ont un caractère progressif, lorsqu’elles s’appuient les unes sur les autres. Dans ce cas, il y a peu de désapprentissage, on apprend par dessus les apprentissages précédents.

Par contre, quand le changement est plus disruptif, quand il s’agit d’un changement de paradigme, on peut rarement avoir de telles étapes intermédiaires sans devoir désapprendre.

Voici un exemple concret pour illustrer le type de changement en question : les estimations.

JH ➡️ #NoEstimates : faut-il passer par les Story Points ?

Partons d’une équipe qui estime son travail “à l’ancienne”, c’est à dire en jours-hommes absolus.

Imaginons qu’on veuille les faire passer au #NoEstimates, c’est-à-dire un découpage en continu permettant de se baser sur le nombre d’éléments plutôt que de les estimer. 1

Faut-il considérer que le passage direct de l’un à l’autre est un changement trop grand ? Faudrait-il conseiller de passer par les estimations relatives en Story Points en étape intermédiaire ?

D’expérience, non. En réalité, passer au #NoEstimates est un changement de paradigme, que l’on vienne des estimations en J.H absolus ou que l’on vienne des estimations relatives en Story Points. Autant former et accompagner l’équipe directement au #NoEstimates.

Mais ça… C’est pour une équipe.

Conduire le changement à l’échelle

Conduire un changement à l’échelle est long, même un petit changement… Parce qu’on est nombreux !

Comme il y a beaucoup de monde, on se retrouve à passer par des étapes intermédiaires. Elles peuvent sembler contre-productives, car elles ne sont pas la cible. Mais elles sont plus facile d’accès d’un point de vue culture, intellectuel, charge mentale…

Un exemple concret : les plans de charge

Le contexte :

• Tout le monde fait des plans de charge

• Estimations micro en Jours-Hommes

• Calcul de capacité au jour près

• Construction d’agendas en conséquence et suivi au quotidien…

• (et forcément on a des chefs de projet dont une bonne part de leur temps est de simplement gérer ça !)

Comment la situation est vécue

Voici la douleur ressentie par les acteurs de ce système :

• On n’a pas le bon outillage

• C’est la galère sans nom pour faire et suivre les estimations, pour récolter les capacités, pour construire les plans de charge, pour détecter les alertes au quotidien et pour ajuster en continu les charges

• La demande aux équipes transverses sensées les aider :

« Donnez-nous un outil qui nous facilitera la vie !!! »

Comment la situation est analysée par les équipes transverses en question

Cette équipe est composée d’agilistes aguerris. Voici leur perception :

• Le problème est lié à la structure même de comment on s’organise et de comment on gère le travail :

« Faisons des équipes dédiées et plus besoin de gérer ce plan de charge ! On pourra alors passer à des engagements d’équipe et enclencher tout un tas de dynamiques saines. »

En suivant ce raisonnement, qui oublie peut-être cette nuance d’échelle autour de la conduite du changement, voici leurs actions :

• On ne les aide pas avec leur problématique à court terme d’outil.

• On s’épuise à les convaincre, ainsi que la direction, à changer tout le modèle d’équipe pour passer à des équipes dédiées.

Résultat, rien ne se passe :

• On est venu avec une solution pour un problème qui, dans la tête du système, n’existe pas.

• Dans leur référentiel de pensée, cette idée d’équipes dédiées n’a aucun sens, alors qu’on a beaucoup d’arguments pour continuer comme on fait actuellement.

• De fait, cette proposition de réorganisation fondamentale et profonde est perçue comme “une transformation de plus” (sous-entendu : “qui ne sert à rien et qu’on nous impose en plus du reste”). Zéro adhésion, zéro changement.

• Et rien ne se passe, également parce qu’on a refusé de travailler sur le problème concret qui était identifié.

Cela me fait donc très mal de le dire, mais dans cette situation, oui, probablement faut-il aider à outiller la construction et le suivi des plans de charge plutôt que de changer directement de modèle organisationnel.

De l’intérêt des étapes intermédiaires

Attention, je ne dis pas qu’il faut abandonner l’idée de passer à des équipes dédiées, au financement continu : il faut garder cela mais comme un changement à plus long terme, et construire un chemin pour y arriver. Ce chemin sera long et sinueux, il passera par des étapes qui pourraient sembler contre-productives. Mais ces étapes sont nécessaires d’un point de vue changement progressif de manières de penser à l’échelle.

Pour revenir sur l’exemple donné, en outillant cette problématique de plan de charge, on a de nombreuses opportunités de faire évoluer les choses dans la bonne direction :

• Une fois qu’on gère des plans de charge à la perfection, on peut faire prendre conscience qu’il y a quelque chose de fondamentalement cassé dans ce modèle, puisque les problèmes de fond sont toujours là.
  Le plan est carré, et pourtant, il y a toujours des imprévus et des ajustements en cours de route : faudrait-il sortir du modèle prédictif ? 😏

• On rentre dans une démarche avec de la donnée et des mesures. On aura des éléments concrets pour pointer du doigt que même avec une phase développement efficace, les sujets mettent de 6 à 18 mois de bout en bout entre le cadrage, la conception, la validation, le déploiement et la mise en service.
  Entre nous… On le savait déjà. Mais d’avoir des chiffres concrets, ça change tout : cela permet de s’aligner sur le constat, de ne pas pouvoir l’ignorer, et de convaincre le top management si nécessaire.

• Et aussi… Tout simplement… On fait quelque chose d’utile dans leur perception. On les aide. On sert donc à quelque chose. On mérite d’être écouté.
  On construit une relation qui sera essentielle pour accomplir les changements futurs !

La route sur le changement est tout en zig-zag.

Comme les anciennes routes, on ne gravit pas une côte raide en ligne droite mais par paliers progressifs, perpendiculaires à la côte.

Et comme les anciennes routes toujours, quand on tombe sur des obstacles, on les contourne, même si ça rallonge.

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