Ca dépend à qui vous demandez.

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

Définition :

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

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

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

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

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

⭐ Alignement sur les priorités du moment

• Donner plus de sens

• Réduire le Rework

• Réduire les silos

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

• Améliorer la transparence

• Donner une vision claire et consolidée

• Fluidifier le pilotage

⭐ Gestion des dépendances

• Améliorer le Lead Time

⭐ Engagement collectif

• Améliorer la prédictibilité

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

Ca parle beaucoup à certains…

Les directeurs et directrices

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

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

Les équipes transverses

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

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

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

C’est l’horreur pour d’autres !

Les équipes orientées flux de valeur

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

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

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

Parce qu’y aller progressivement est contre-productif !

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

Le risque d’y aller progressivement

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

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

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

Sauf qu’ici, ça ne marche pas.

En y allant progressivement :

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

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

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

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

Echec total, donc. ❌

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

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

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

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

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

Remise en perspective du déploiement de SAFe

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

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

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

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

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

Niveau 0 : Scrum Master de service

“J’ai été Scrum Master”

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

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

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

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

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

Niveau 1 : Scrum Master “intuitif”

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

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

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

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

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

Variante freelance

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

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

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

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

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

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

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

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

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

Impact flou et peu durable

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

On entend souvent ce genre de chose :

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

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

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

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

Niveau 2 : Scrum Master “éclair”

“Voici comment j’accompagne une équipe”

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

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

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

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

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

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

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

Rapide mais pas pérenne ?

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

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

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

Niveau 3 : Scrum Master “Lean”

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

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

• Trop de métriques tuent les métriques

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

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

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

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

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

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

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

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

Quid de l’IA ?

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

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

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

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

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

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

Les DORA Metrics c’est bien...

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

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

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

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

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

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

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

Des métriques sacralisées

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

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

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

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

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

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

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

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

À chaque fois :

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

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

• Ou les deux en même temps 😬

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

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

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

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

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

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

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

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

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

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

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

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

Mais surtout, pour quoi faire ?

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

La réalité est la suivante :

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

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

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

“Get better at getting better”

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

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

Voici donc pourquoi mesurer les DORA Metrics 🎁

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

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

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

Pour se comparer aux autres

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

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

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

Pour utiliser le DORA Model comme framework de transformation

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

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

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

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

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

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

“Start with why”

Mais surtout... Demandez-vous POURQUOI.

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

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

📏 Partez de ce moyen

❓Demandez-vous POURQUOI dans votre contexte — POUR QUOI

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

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

1

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

Accelerate en résumé

Scrum Life Poster Accelerate En Résumé

2.61MB ∙ PDF file

Download

Download

Le DORA Core Model en français

Scrum Life Accelerate Vue D'ensemble

1010KB ∙ PDF file

Download

Download

Les DORA Metrics

Evolutions entre le livre Accelerate et le rapport DORA de 2024

Focus sur les Capabilities

2

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

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

Scrum Life Poster Accelerate Schwarzy

3.69MB ∙ PDF file

Download

Download

Résumé

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

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

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

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

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

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

Autres articles en lien

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

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

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

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

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

• Etc.

Sauf que :

Ça ne marche pas comme ça.

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

😭

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

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

Pour autant, les équipes sont demandeuses

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

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

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

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

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

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

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

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

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

Responsabilité vs charge cognitive

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

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

Justement, ces décisions…

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

Quelque chose de cet acabit :

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

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

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

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

Une fonction support qui réduit la charge cognitive

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

“Faites comme ceci ou comme cela”

❌ On en rajoute

“On s’en occupe à votre place”

✅ On réduit la charge cognitive…

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

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

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

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

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

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

Team Topologies

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

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

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

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

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

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

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

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

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

En mode ticket factory :

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

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

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

En mode self-service :

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

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

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

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

Observer, créer du lien, itérer

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

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

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

Scrum Master…

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

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

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

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

Coach agile…

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

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

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

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

Un changement radical de perspective

Cette distinction est importante.

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

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

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

Voici ma propre expérience

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

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

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

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

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

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

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

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

Quand un Coach Agile intervient comme un Scrum Master 😕

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

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

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

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

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

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

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

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

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

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

Pour conclure : une distinction à maîtriser

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

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

TL;DR

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

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

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

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

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

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

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

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

Je me contenterai de dire ceci :

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

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

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

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

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

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

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

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

Le vrai ennemi : faire n’importe quoi

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

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

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

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

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

Il n’y a aucune opposition 🤔

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

L’approche traditionnelle EST agile

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

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

La gestion de projet est agile par défaut

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

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

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

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

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

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

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

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

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

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

L’argument recevable : le coût du changement

Reste un argument que je veux bien entendre :

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

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

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

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

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

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

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

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

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

Pourquoi c’est pertinent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Croire qu’améliorer le relationnel suffit

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

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

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

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

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

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

La politique.

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

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

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

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

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

• Pourquoi il ne faut pas en avoir peur !

Propre à tout écosystème sociétal complexe

On trouve de la politique dans quasiment toutes les entreprises.

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

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

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

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

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

La similitude du marketing interne avec le marketing tout court

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La véracité d’un argument est secondaire

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

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

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

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

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

Ou voire même, tout simplement :

“je ne suis pas d’accord”

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

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

Les outputs convainquent plus que les outcomes

Pourquoi ce préambule ?

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

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

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

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

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

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

De la visibilité des outputs

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

• D’avoir fait cet atelier est un output.

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

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

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

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

Outputs + outcomes = 💖

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

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

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

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

Le risque du désalignement sur les outcomes

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

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

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

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

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

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

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

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

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

Court terme vs long terme

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

• Avoir des outputs bien visibles et convaincants à court terme

• Avoir des outcomes compréhensibles à long terme

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

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

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

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

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

C’est un discours que j’ai pu porter moi-même, comme cela a pu être promu dans certains épisodes de Scrum Life. 1

Dans cet article, je viens remettre ce point de vue en question. A minima, le nuancer.

Voici la question à laquelle on va tenter de répondre :

Du custom pour la meilleure performance…

Là où je suis d’accord, c’est qu’en effet construire un mode de fonctionnement adapté au contexte d’une équipe ou d’une organisation c’est ce qui permettra d’en tirer le meilleur niveau de performance.

Voici les atouts d’une approche custom par rapport à une approche standardisée :

• Conduite du changement plus facile en partant de l’existant, en tenant compte au maximum de la réalité actuelle

• Développement plus efficace du mindset en impliquant les personnes dans la découverte de la bonne approche, menant ainsi à une meilleure pérennité du changement

• Eviter l’écueil de vouloir appliquer des pratiques qui ont généralement du sens sauf dans le cas précis de l’équipe

• Plus largement, ne pas tomber dans la bureaucratie, les vanity metrics ou encore le cargo cult

• Mise en place naturelle de pratiques atypiques ou innovantes, qui émergent du contexte et des besoins spécifiques de l’équipe ou de l’organisation

Bref, on construirait de meilleurs modes de fonctionnement, de manière plus fluide et plus pérenne, en évitant les pièges du faux agile.

Super, non ? Alors pourquoi envisager de faire autrement ? 😏

… mais à quel prix ?

Sauf que…

Admettons que ce custom soit mieux. La question qui se pose juste après, c’est : à quel prix ?

Là où le standardisé tire son épingle du jeu, c’est quand on passe à l’échelle, quand on est dans une grande organisation et que l’on doit adresser un ensemble de départements et d’équipes. On n’a alors jamais les moyens d’avoir, par exemple, un expert agile dédié à chaque équipe pendant plusieurs années.

En voulant faire du custom dans ce type de contexte, on serait alors obligé de choisir entre :

• Accompagner tout le monde en même temps… Mais on n’a pas la bande passante de le faire bien. Les experts se retrouvent alors à devoir accompagner chacun de nombreuses équipes en même temps. En s’y prenant ainsi, on n’arrivera pas à générer les gains promis par l’approche custom : pas assez sur le terrain pour en observer la réalité, pour être pertinent et pour former en faisant ensemble. ❌

• On peut alors se dire de se focaliser sur certaines équipes uniquement, en les accompagnant par contre au mieux. On est alors sensé générer les gains promis par l’approche custom, sauf que… Seulement sur certaines équipes. Quid des autres ? Au final, on a des gains mais que sur quelques équipes. Est-ce que l’on considèrera que le ROI est suffisant ? Sans même parler des équipes qui ne sont pas accompagnées, qui peuvent se considérer comme abandonnées sur le bord de la route, et qui deviendront certainement les premiers détracteurs de la démarche. ❌

• Bien sûr, l’option précédente était simpliste. On va donc faire tourner l’accompagnement : on se focalise sur certaines équipes pendant quelques mois, puis on s’attèle à d’autres, et ainsi de suite. Le risque ici est que tout s’effondre lorsque l’on s’en va : il faut donc réussir à ancrer les apprentissages et les nouvelles manières de faire avant de tourner. Pas évident du tout en l’espace de quelques mois. 😬

Dans tous les cas, on sent bien que l’approche custom coûte simplement trop cher pour être efficace.

Avoir des résultats visibles rapidement pour assurer le financement

D’un point de vue comptable, une initiative de transformation est comme n’importe quelle autre initiative, et un centre d’expertise est comme n’importe quel autre département :

1. On les finance initialement parce qu’on croit dans le business plan qui justifie que cela va apporter plus à l’organisation que cela ne va coûter.

2. Puis on continue de les financer parce que les faits le démontrent, ou du moins nous font le penser2

Voici donc l’injonction contradictoire de toute transformation : il faut du temps pour avoir des résultats profonds et pérennes, mais il faut des résultats rapides pour avoir l’opportunité de rentrer dans un temps long.

Faire du custom c’est prendre le risque de ne pas avoir suffisamment d’impact, suffisamment rapidement, pour pouvoir appliquer la démarche partout.

Et c’est pourquoi, en remettant les choses dans le contexte du financement des initiatives et de la gestion de budget des grandes organisations, le standardisé est en réalité on ne peut plus logique, du moins dans un premier temps.

Du standardisé pour des premiers gains à l’échelle

Prenons le contrepied de l’approche custom pour présenter l’approche du standardisé.

✅ Avec du standardisé, on peut assez facilement adresser un ensemble d’équipes ou de départements avec un nombre limité d’experts.

Bien sûr, tous les arguments évoqués plus haut en faveur de l’approche custom tiennent toujours. Ce sont autant de challenges que l’on va se prendre en pleine face.

Peut-être même que l’on créera un certain nombre d’environnements où il se passera exactement ce qui hérisse le poil des agilistes : du grand n’importe quoi où l’agilité est dévoyée et appliquée comme de la bureaucratie.

Mais forçons-nous à prendre un peu de recul, à réfléchir comme un gestionnaire ou comme un entrepreneur, plutôt que comme un contributeur individuel qui subit tout cela.

L’enjeu de l’approche custom est de générer des systèmes hautement performants. 💎

L’enjeu de l’approche standardisé est de pouvoir être appliquée à l’échelle, sur de nombreuses équipes ; on sait très bien qu’on fait de la 💩, sauf que comme on part de très loin, c’est déjà une amélioration. On ne vise pas la meilleure performance d’une équipe donnée, on vise un peu d’amélioration partout, ce qui est beaucoup plus significatif au global.

Avec, encore une fois, cette nécessité de démontrer que la démarche sert à quelque chose pour lui permettre de continuer d’être financée.

Conclusion

Toutes choses prises en compte… Le succès des frameworks dans les grandes organisations n’est pas surprenant. 🤷

Et ce n’est pas parce que ces grandes organisations seraient remplies de gens feignants, incompétents ou carriéristes. Bien au contraire : parce que c’est en fait la seule voie qui a une chance de marcher, du moins dans un premier temps.

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

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

Les entreprises qui ne vendent pas de la tech

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

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

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

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

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

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

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

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

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

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

Un rappel de tous les jours…

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

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

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

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

Qualité numéro 1 : fiabilité.

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

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

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

Qualité numéro 2 : communication.

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

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

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

… Pour toutes les fonctions support

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

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

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

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

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

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

Ce qui fait la différence c’est :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La facilité de se laisser porter

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

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

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

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

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

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

Mea culpa

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

Alors, que faire ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bloquer du temps

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

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

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

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

Partager son agenda

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

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

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

Et vous ?

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

C’est difficile, alors discutons-en ! 🤗

Vous connaissez sûrement le célèbre exercice avec la pelote de laine rouge :

(Oui, rouge. Le folklore requiert d’utiliser du fil rouge 🤷
Par contre, la présence des chats n’est pas du tout habituelle 😂)

Ce travail autour des dépendances, c’est souvent ce qui est le plus apprécié par le management et les directeurs dans l’exercice du PI Planning.

Tout d’abord, il faut reconnaitre que c’est sacrément stylé, ce tableau avec des éléments dans tous les sens et tous ces bouts de ficelle qui se croisent. Si j’osais, je parlerais d’art.

Il y a aussi que cela permet de raccrocher les wagons avec une approche traditionnelle de la gestion de projet et le fameux Gantt, où l’on programme les différentes activités en tenant compte des dépendances.

Mais plus important encore : eh oui, dans un fonctionnement à l’échelle avec de nombreuses équipes, la gestion des dépendances c’est le nerf de la guerre. Car une mauvaise gestion des dépendances tue complètement le système, explosant le Lead Time pour accomplir les choses les plus triviales.

Les limites de la gestion des dépendances

Là où les dents grincent, notamment dans le monde des experts agiles, c’est que cet exercice du PI Planning avec son travail sur les dépendances est trop souvent pris avec cette vue abstraite du Gantt : comme s’il suffisait de décaler les choses et d’essayer de les faire dans un certain ordre pour que tout se passe bien.

Ou alors, on identifie que plusieurs groupes vont devoir travailler ensemble, alors on met en place des réunions récurrentes (souvent appelées “rituels”) et on se dit que ça va le faire sans chercher plus loin.

Tout ceci s’appelle gérer les dépendances, dans le sens de faire le nécessaire pour en réduire l’impact, pour réussir à vivre avec ces dépendances.

C’est bien sûr la chose à faire quand on ne peut pas faire autrement, par exemple lorsque deux équipes qui dépendent l’une de l’autre ne peuvent pas se passer de travail (souvent par manque d’expertise, chaque équipe étant l’experte de son domaine), et que des contraintes de temps forcent à trouver comment faire maintenant.

Mais cela devrait être la dernière chose à faire, l’option de dernier recours.

À la place, on devrait au maximum chercher à réduire les dépendances, soit donc non pas faire marcher la ficelle rouge mais bel et bien enlever la ficelle rouge.

Tantôt, il est question de changer la répartition du travail entre les équipes, pour limiter le ping-pong et faire en sorte que les équipes portent au maximum des sujets de bout en bout.

Souvent, ce n’est pas aussi simple. Par exemple il faut faire monter en compétences certaines équipes, recruter ou carrément réorganiser complètement les équipes.

Au-delà des compétences nécessaires pour mener à bien tel ou tel travail, il est également très possible qu’il faille restructurer le produit, aussi bien fonctionnellement que techniquement, afin de créer des Bounded Domains relativement indépendants et sur lesquels une équipe pourrait intervenir en autonomie.

Autant dire que ce type de travail ne se fait pas en claquant des doigts ! Et c’est sûrement là une autre raison pour laquelle ce travail de réduction des dépendances est si peu fait :

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

2. Parce que cela nécessite de s’inscrire dans la durée, les changements d’ampleur se faisant petit à petit (et nécessitent potentiellement une conduite du changement)

3. Parce que ce n’est pas à la portée de tous, cela nécessite des compétences et expertises pointues

(ceci étant dit, franchement, si vous êtes motivés et que les 2 premiers critères ne vous font pas peur, je ne peux que vous encourager d’essayer et de monter en compétence en faisant ! 🙌)

Avant toute chose, ne pas ignorer les dépendances

Trop souvent, les grosses boîtes ont l’habitude de travailler avec des dépendances entre équipes. Les grands groupes s’accommodent le plus naturellement du monde des dépendances !

Cette attitude semblera révoltante aux structures à leurs antipodes : en environnement start-up où l’efficacité de la simplicité prime, comme une évidence. En start-up, on se dit que les dépendances, c’est la galère, structurons-nous pour les limiter !

Pour autant, les grands groupes ne sont pas inconscients du problème. Lors d’un événement type PI Planning, j’ai entendu récemment un discours d’une lucidité frappante : “vous avez des dépendances, identifiez-les comme des tâches à part entière, vous allez devoir vous synchroniser et faire le suivi, tenez-en compte.”
Oui ! Car le premier et plus grand risque est bel et bien d’ignorer une dépendance, en la laissant prendre le contrôle.

Ce risque est réel et j’ai apprécié cette lucidité lors de cet atelier.

Car si j’apprécie au plus haut point l’approche d’une start-up qui n’hésite pas à s’adapter et se restructurer pour réduire les dépendances, ce type d’environnement peut aussi très vite sous-estimer l’impact des dépendances en les laissant vivre leur vie, en les laissant pourrir tout le monde… Dynamique potentiellement renforcée par une culture omniprésente du héro, où chacun fait quotidiennement des efforts sur-humains pour porter le système à bout de bras. Et en apparence, tout fonctionne… Jusqu’au moment où tout explose.

À l’inverse, en grand groupe, j’apprécie le fait que l’on soit bien conscient que les dépendances amènent un surcoût… Mais je suis par contre mal à l’aise vis-à-vis du fait que la réflexion s’arrête là : on se contente de dire qu’il faudra y consacrer du temps ou de l’argent, sans remettre en question cette dépense même.

Ce n’est pas parce que l’on gère un problème qu’il faut accepter le problème !

TL;DR

• Connaissez vos dépendances. Rien de pire que de laisser une dépendance sans contrôle.

• Par contre, soyez bien conscient qu’une dépendance, ça coûte. Mettez les moyens nécessaires pour la gérer… Et réfléchissez activement à comment la réduire !

Et un peu à toutes les sauces : pour qualifier la stratégie de l’entreprise, sa capacité à exécuter, ou encore ses valeurs. C’est devenu assez habituel d’entendre “agile” à répétition dans des discours d’entreprise bien corporate, que cela soit à destination des salariés, des actionnaires ou des investisseurs.

Bien sûr, la question que je veux poser avec cet article, c’est : est-ce que c’est bien ou mal ?

Car, cela va sans dire, cet “agile”-là, n’est pas vraiment le même que celui que l’on connait à tout va entre agilistes, et notamment dans le domaine informatique et que l’on rattache au Manifeste pour le développement agile de logiciels de 2001.

Ce n’est pas le même “agile” : est-ce que c’est un risque ? Ou bien au contraire est-ce une opportunité ?

Faisons une bonne vieille évaluation risque/opportunité 🙂

Le risque

Le 1er risque qu’on voit à cet usage du mot “agile” par le business, c’est que justement ce n’est pas la même définition. Résultat, ces directions parlent “d’agilité” sans savoir ce que c’est, notamment si on compare ça aux équipes types qui travaillent de près ou de loin dans le domaine du numérique. Dans ces équipes, cela fait des années, quand ce n’est pas des décennies, que l’on utilise Scrum, SAFe et bien d’autres choses… Où l’on retrouve un ensemble d’éléments que l’on raccroche à cette définition bien ancrée de “l’agilité”.

Parmi ces éléments qui forment un référentiel commun et partagé, on a par exemple :

• La notion de “sprint“ pour désigner une période de temps fixée en avance pour travailler sur un objectif donné

• La notion de “backlog” priorisé pour désigner un répertoire collectant des pistes à explorer sur le projet ou le produit

On peut bien sûr en citer d’autres, mais ce qu’il est intéressant de noter, c’est qu’au final cette définition “d’agilité” se rattache surtout à des pratiques et des outils.

L’opportunité

Prenons maintenant le contre-pied. Essayons de voir cette utilisation du mot “agile” par les directions non pas comme un risque mais comme une opportunité.
C’est assez intéressant si on prend la peine de creuser…

Très certainement ils n’ont pas la même définition, notamment quand on rentre dans le concret et qu’on rattache “l’agilité” à toutes ces pratiques que je viens d’évoquer.

Justement, regardons le sens que ces directions mettent derrière ce mot “agile“. Leur définition n’est pas si incohérente que cela…

👉 Ça veut dire mettre plus vite des choses sur le marché et être capable de pivoter rapidement

Et bah, j’ai envie de dire que ce n’est pas une mauvaise définition de l’agilité ! 😅

Franchement, je pense que cette utilisation du mot “agile” par les directions dans leurs grands discours, c’est une grande opportunité.

C’est une grande opportunité pour transformer et pour évangéliser, en s’appuyant sur des discours reconnus portés par la direction.

Bien sûr, cela peut être une pente glissante à cause du point précédent avec une possible divergence de définition, mais j’y vois surtout l’opportunité à saisir.

S’aligner

Cela m’amène cette autre réflexion : au lieu de se plaindre, de voir le risque d’une utilisation qui serait en quelque sorte erronée parce que le sens du mot “agile” ne serait pas le même... Est-ce qu’on ne devrait pas tout simplement se rattacher au même sens qu’eux ?

Je pense qu’il n’y a pas ici qu’un simple effet de mode.
Finalement, ce mot “agile” porte ici bel et bien le sens recherché.
Effectivement, une entreprise “agile”, c’est par exemple une entreprise qui réussit à passer au travers d’une crise sanitaire en réorientant son offre, ses ressources, ses manières de travailler, etc.
En étant agile, au niveau business !

Je trouve que dans ce contexte, c’est une bonne définition de l’agilité. À vrai dire, c’est une définition qui revient sur le fameux état d’esprit plutôt que sur les pratiques et les outils.

Conclusion

Je pense donc que c’est une bonne opportunité à saisir. Comment faire ?

De toutes façons il faut se caler sur le vocabulaire des métiers et de la direction. 🤷

Et cette définition me va très bien : être capable de mettre vite sur le marché quelque chose, et être capable de se réorganiser très rapidement pour réagir aux imprévus.

C’est top de se dire qu’aujourd’hui, on a un changement de discours et que les métiers ne demandent pas mieux. 🫶

En effet, bien souvent, la transformation n’a pas grand chose à voir avec la DSI. Ou plutôt, le gros de la transfo, la partie qui permettra de débloquer le plus de gains, c’était au contraire en transformant l’ensemble de l’entreprise et en particulier les métiers.

C’est un facteur récurrent de frustration dans la DSI, cette DSI qu’on a très souvent mise dans une posture subalterne des métiers.
Sauf que ce positionnement est généralement à raison, d’un point de vue historique ! Car c’est bien le métier qui rapporte des sous et qui a fait que l’entreprise en est là où elle est arrivée.
On aime bien parler de plafond de verre pour évoquer cette difficulté à bouger les lignes au-delà de la DSI.

Bien sûr, quand on parle de transformation digitale, cela amène une certaine légitimité à la démarche de localiser hiérarchiquement la transformation au sein de la DSI. Néanmoins, l’enjeu de ce type de transformation étant d’intégrer le numérique au cœur du métier de l’entreprise, là encore cela n’a finalement que peu de sens si on veut réellement impacter les métiers. 🤷

Digitalisation des processus métiers

Faut-il le rappeler, la digitalisation d’un processus métier, ce n’est pas juste prendre l’existant et le mettre dans un outil numérique, dans un ERP, dans un outil de ticketing ou dans un CRM.

En se contentant de suivre cette démarche naïve qui se contente de placarder un outil complexe par dessus l’existant, on arrive au stade où l’on cumule les défauts du numérique en plus des défauts de la version manuelle ou sur papier.
👉 On crée des usines à gaz qui obfusquent la réalité tout en confisquant la capacité des humains à improviser et à sortir du processus si nécessaire.

La digitalisation d’un processus métier commence par un travail de fond d’analyse, de formalisation et de redéfinition dudit processus. Et si j’osais, je préciserais que ce travail est sur papier ! Il n’est pas encore question d’outil ou d’industrialiser.

L’enjeu premier de cette démarche est de simplifier le processus métier ! Notamment en tirant partie des possibilités offertes par le numérique.

Petit exemple : avec le numérique on peut rentrer dans une logique de self-service où l’on demande à l’utilisateur d’entrer lui-même ses informations.
Cela n’a l’air de rien mais cela permet un véritable changement de paradigme. Plus besoin de mettre des personnes à disposition de l’utilisateur pour accepter ses demandes !
Par contre, ce genre de changement nécessite de revoir complètement le processus.

Mais comment faire ce travail ?

Voici une belle réflexion que j’ai entendue sur ce sujet :

“Les métiers ont le nez dans le guidon. Ils passent leur temps à faire tourner la boutique, à gérer le run, la production.

“Même s’ils sont conscients qu’ils doivent revoir comment ils travaillent, c’est extrêmement dur pour eux de libérer la bande passante nécessaire, autant en temps, en énergie, qu’en charge mentale. Ils ont déjà tellement à faire !

“Qui plus est, souvent, ils ne savent pas comment faire ce travail d’analyse et de remise à plat : ce n’est pas leur métier et leurs compétences.

“C’est pourquoi notre rôle, en tant que DSI, c’est aussi de tenir le crayon à la place des métiers dans la redéfinition de leurs processus. Nous apportons notre expertise mais également notre disponibilité pour nous pencher sur ces problèmes.”

D’entendre cela m’a fait comme un déclic. Oui, les métiers, à qui l’on doit le succès de l’entreprise, sont également sous l’eau et rarement capables de se réinventer. Pas par incompétence ou par orgueil. Simplement par manque de temps, par impossibilité de se libérer du quotidien pour prendre du recul.

D’un seul coup, cela a éclairé sous un jour nouveau la réflexion que je vous partageais au début de cet article.
C’est effectivement dans la DSI que l’on va trouver les compétences d’analyse et de formalisation nécessaires pour remettre à plat les processus métiers.
Et c’est souvent aussi dans la DSI que l’on va trouver des personnes qui arrivent à se dégager du temps pour améliorer le fonctionnement de l’entreprise.

Après tout, quand on a créé la DSI, c’était pour gagner du temps, pas vrai ? Pour rationnaliser les coûts, pour réduire les risques ou pour libérer du temps aux métiers. C’est, historiquement et structurellement, une entité en support des métiers, avec du temps à disposition pour faire gagner du temps aux métiers.

Donc, finalement, ça ne me choque plus que la dynamique de transformation émerge de la DSI 😊

On déplore souvent que dans des les grands groupes on a une organisation avec une DSI positionnée comme une pièce rapportée, avec un mode de fonctionnement digne d’une agence interne : les métiers sollicitent la DSI pour faire tel ou tel projet.

Ce n’est évidemment pas une généralité, mais cela reste encore assez courant, tout particulièrement dans les entreprises qui ne sont pas digital natives, dans ces entreprises qui existent depuis quelques temps déjà et dont le business ne prend pas son origine dans le numérique.

Mécaniquement, dans ce type de contexte, on demande donc à la DSI d’être un expert technique, et guère plus. À une époque, c’était à la mode de renommer en “Digital Factory” la DSI ou ses activités de développement applicatif.

Digital Factory : l’utilisation du concept d’usine passe assez bien cette vision d’une DSI qui ne serait là que pour produire, en boucle, sans déviation. (et même, pourquoi pas, de manière prédictible ! Ça, c’est une autre histoire...)

Clairement, on associe donc ce modèle à un focus strict sur le delivery, comme on aime bien dire.

Cet type de situation est souvent source de frustration au sein de la DSI, avec un sentiment d’impuissance face aux métiers, on aimerait “faire du produit” mais on reste contraint à exécuter des projets donnés par les métiers. On reste contraint à faire du delivery, et surtout rien d’autre.

La posture de facilité, c’est alors de critiquer le système dans la globalité, et de juste se plaindre de l’état de fait. C’est tellement facile de rattacher le moindre problème à ça :

“On ne nous a pas impliqué dès le début”

“Ils ont conçu cela sans nous consulter”

“On ne voit jamais les utilisateurs”

“On se contente d’implémenter une spec”

“Je ne sais pas vraiment à quoi ça sert”

Etc.

Je vois une première nuance à apporter : bien sûr, dans une organisation dite “produit”, on organise les équipes d’une telle manière que ce type de situation n’arrive pas, avec une réelle proximité (et connivence !) entre les différents acteurs qui conçoivent, construisent, livrent et maintiennent le produit.

Pour autant, même en étant loin de ce type d’organisation, on peut tout de même faire plein de choses pour aller dans le bon sens. La phrase “Je ne sais pas vraiment à quoi ça sert” est un bon exemple :

• Certes, l’équipe est loin des enjeux business et des utilisateurs. Certes, les métiers ne communiquent peut-être pas assez ou pas assez bien les enjeux derrière, qui sont critiques pour le business et les utilisateurs.

• Mais pour autant... On pourrait challenger plus les métiers. On pourrait aller au fond des choses. On pourrait s’assurer qu’on les comprend. Puis on pourrait utiliser cette connaissance au quotidien pour toujours se rappeler pourquoi c’est critique, pourquoi ce qu’on fait doit être fait et en quoi ça change le monde ! (le monde des métiers, il s’entend)

Pour faire ça, ça requiert de réellement s’intéresser au quotidien des métiers et d’apprendre ainsi leur langue.

Si, si, ça se fait. Les métiers ne mordent pas ! 😅

(Par contre… Ils ont souvent des impératifs qui vont limiter leur patience -- aussi focalisez-vous bien sur leurs douleurs, et assurez-vous bien que ce que vous faites va effectivement les aider.)

Attaquons maintenant un second point. Quand l’organisation vous assigne un rôle uniquement focalisé sur le delivery, il reste pourtant de l’espoir pour faire bouger les lignes... Justement en se focalisant sur le delivery.

Plus précisément, en faisant en sorte d’être exemplaire dans le delivery.

Ce point est un peu contre-intuitif.

Une bonne manière de l’expliquer, c’est de partir de cette maxime attribuée au Lean :

Les relations s’améliorent parce que l’opérationnel se passe mieux. Ce n’est pas l’inverse.

Dans un monde où la DSI mettrait tout sur le dos des métiers, la DSI aura tendance à penser qu’il faut d’abord améliorer la relation avec les métiers pour que ça se passe mieux. Mais c’est en réalité l’inverse : c’est bien parce que cela se passera mieux côté DSI que la relation avec les métiers s’améliorera. 🤷

Alors attention, améliorer le delivery, ça ne veut pas dire “bosser mieux” ou “faire ce qu’on nous demande sans le questionner”.

Bien au contraire, c’est commencer par dire non aux demandes des métiers quand il y en a trop (spoiler : il y en a toujours trop) ce qui permettra d’avoir un bon focus côté DSI… Et ainsi pouvoir tenir ses engagements.

Rester dans le périmètre qu’on nous a confié, ça ne veut pas dire exécuter sans imposer de contraintes aux autres.

C’est bien justement parce qu’on est sur son domaine que l’on peut se permettre, et qu’on a même le devoir, d’en prendre la pleine responsabilité.

Et quand cela porte ses fruits, que le delivery est là et que la relation s’améliore avec les métiers... On peut alors envisager de faire bouger la dynamique au global et sortir du carcan dans lequel la DSI était initialement enfermée. 💪

J’ai eu droit récemment à ma piqûre de rappel.

Je travaillais sur la transformation du mode de fonctionnement d’une entreprise. Enjeux : arrêter d’imaginer de multiples initiatives qui seront ensuite spécifiées, estimées, priorisées... Et commencer à partir des objectifs business pour décider ensuite de ce qu’il faut faire pour les atteindre.

Si vous me connaissez, vous aurez peut-être reconnu des vibes d’OKR ou encore de #NoEstimates. Mais là n’est pas le sujet du jour !

Non, le sujet, c’est que je travaillais donc sur tout cela. Pas seul bien entendu. J’avais notamment embarqué le CTPO et le Product Manager (PM) de l’équipe en charge du développement du produit logiciel. On s’aligne, on est motivés, on dessine l’avenir, on fonce ensemble. 💪

Et donc, on programme un atelier avec les autres C-level pour définir l’objectif qui doit concerner toute l’entreprise pendant ce trimestre. Bref, initier une démarche de définition d’OKR.

Et là, c’est le drame.

J’avais préparé l’atelier, pourtant. J’avais même fait une session en amont avec le PM pour bien s’aligner et pour qu’il puisse se positionner en facilitateur de la démarche après mon départ imminent.

Dès les premières secondes du démarrage de l’atelier, une fois face aux CEO et COO, je tilte : mais au fait, pourquoi est-on là ?!? 😱

Instantanément, je me sens très bête.

J’improvise donc, sans déroulé clair ni support pour appuyer mes propos, une remise dans le contexte de la démarche générale et de pourquoi on est là. Bref, je sauve les meubles.

Mais le mal est fait : le groupe jouera le jeu mais on me confiera après coup un certain malaise face à cet exercice, qui est par ailleurs très difficile et même déstabilisant.

Plus tard encore, je réaliserai que ma déconvenue va bien au-delà de juste redonner du contexte. En réalité, cette définition des objectifs de l’entreprise ne sert à rien tout seul.

👉 Admettons qu’on l’ait fait : so what?
On en fait quoi après ?
En quoi ça nous aide ?
Qu’est-ce que ça change ? Etc.

Mille questions, totalement légitimes, qui font que le risque est grand de juste réembrayer sur refaire comme avant.

Car dans ma remise dans le contexte un peu abrupte et improvisée, on n’est pas parti du début du cheminement intellectuel qui débouche sur l’atelier.
Je n’ai pas explicité le changement fondamental de fonctionnement que l’on veut insuffler, pourquoi on veut l’insuffler, quelles sont les hypothèses sous-jacentes que l’on pose, et en quoi ça va nous aider.

J’avais également omis la suite des événements, le “après” : comment incarnera-t-on ces objectifs, comment les équipes vont transformer cela en quelque chose d’actionnable et de pertinent, comment allons-nous faire vivre toute cette dynamique ?

Il manquait donc :

• Une remise dans le contexte, réelle et profonde, dans laquelle on ne se contente pas de juste donner des éléments, mais où l’on refait ensemble tout le cheminement intellectuel qui aboutit à l’atelier ;

• Et il manquait aussi le mode opératoire pour la suite des événements, ce qui permet de montrer l’atelier, et les livrables visés, vont effectivement nous aider.

Bref. Cette erreur, elle est classique. On tombe très facilement dedans. Soi-même, on réfléchit longuement à une situation ou à un problème, on analyse, on fait tout un parcours intellectuel, et on arrive à une conclusion qui finit par nous sembler évidente. Peut-être même que, comme moi, vous avez en plus fait ce chemin à plusieurs, ce qui renforce ce sentiment d’évidence, car vous êtes aligné avec ces compagnons de route.

Et... Lorsque vous embarquez de nouveaux intervenants, vous oubliez qu’il y a une réelle dissonance entre le niveau de maturité de votre perception de la situation, et celles des nouveaux intervenants.

Ils se retrouvent sans vraiment savoir pourquoi ils sont là, ni comment sera utilisé leur travail. 🤷

Pensez-y la prochaine fois.
Vous êtes certainement la personne qui a retourné le plus de fois dans tous les sens le problème que vous essayez de résoudre.
Vous ne pouvez pas embarquer de nouvelles personnes sans leur faire faire le cheminement à eux aussi.

Ce n’est pas au business d’apprendre l’agile. C’est à nous d’apprendre le business.

Cet article — que je vous recommande plus qu’urgemment de lire — m’a fait penser à autre chose.

Il m’a fait penser au rôle des chefs de projets et autres PMO.

La méprise sur les chefs de projet

Historiquement il y a comme une sorte de bashing des chefs de projet dans le milieu agile. Avec souvent en retour un bashing bien mérité de l’agilité, en clamant que le cycle en V n’était pas mort.

Sauf qu’aujourd’hui, la situation a bien changé. La frontière entre agilité et chefferie de projet n’existe plus vraiment.

Qu’est-ce qu’on voit ?

• Le PMBOK, livre de référence sur la gestion de projet, parle d’agilité comme pratique normale et nominale, à laquelle les chefs de projets sont tous formés depuis pas mal de temps déjà

• Le PMI, institut promouvant la gestion de projet, a racheté et intégré DAD, un meta-framework agile et un superbe référentiel de pratiques et approches agiles

• Des conférences agiles (moins en France, certes) dispensent des points PMI en cadeau avec le ticket d’entrée à la conférence

La réalité, c’est qu’aujourd’hui, on ne fait plus cette chefferie de projet à la papa que dénonçait le manifeste agile.

Aujourd’hui, être PMO ou chef de projet ça rime avec transformation, gouvernance collaborative, amélioration du focus des équipes et pilotage par la valeur.

Le reporting n’est plus le sujet, et quand il l’est c’est dans les deux sens — et au final ce n’est plus tant du reporting que le développement d’une culture de la mesure.

Finalement… Je trouve que ça ressemble beaucoup aux discours et constats que faisaient et continuent de faire les coachs agiles, le refrain gnan-gnan “il n’y a que l’humain qui compte” en moins.1

Les chefs de projet parlent business par défaut

Je reviens sur l’article de Rachel.

Ce n’est pas au business d’apprendre l’agile. C’est à nous d’apprendre le business.

Une différence que je vois entre les coachs agiles d’un côté, et les chefs de projet et PMO de l’autre, c’est qu’historiquement ces derniers sont plus proches du business.

• Par exemple, il est habituel qu’un chef de projet tienne un budget, le budget du projet.

• Ils animent des CODIR... Ils fréquentent quotidiennement des directeurs, ils vivent dans leurs mondes et leurs contraintes.

• Et oui, c’est souvent ce qui déplait aux agilistes, mais oui par défaut ils sont avant tout du côté du business, du côté de ceux qui paient, plus que du côté de l’équipe, du côté de ceux qui triment et galèrent pour réussir tant bien que mal le projet.

En tous cas, les coach agiles ont beaucoup à apprendre d’eux.

Je ne vais pas dire que tout est rose au pays des chefs de projet, mais je trouvais ça cocasse de me dire qu’après l’âge d’or du consulting agile, d’une certaine manière on assistait à une sorte de revanche des chefs de projet sur les coach agiles.

Product Owner VS. Product Manager : Scrum se concentre-t-il sur la réalisation et la livraison ?

J’aimerais partager avec vous une discussion que j’ai eu il y a peu via les commentaires de la chaîne YouTube Scrum Life.

Plus précisément, il s’agissait de la vidéo “Scrum Master VS. Product Owner” qui vise à aider les agilistes à se décider entre les deux carrières.

“[Scrum] est un framework qui se concentre sur la réalisation/livraison”

En particulier, il est question du commentaire suivant de Vincent Pavero :

Je réagis à chaud ici, mais je suis effaré par cette vidéo qui je pense vend des illusions aux gens. On ne peut pas choisir entre les deux. Ce sont deux carrières différentes qui demandent des compétences et soft-skills qui ne se recoupent pas. On ne peut pas être vraiment compétent dans les deux. Il y autant de différence entre PM/PO et SM qu’il y a entre un comptable et un maçon. On ne fera pas croire à un comptable qu’il pourrait commencer un boulot de maçon la semaine prochaine. Et il est probable que le maçon qui aurait besoin de travailler à l’extérieur par exemple ne sera jamais épanoui dans un boulot de comptable derrière un écran d’ordinateur.

Bref la question ne se pose pas vraiment, il y a normalement un des deux emplois pour lequel vous ne pourriez pas passer un processus de recrutement.

Ensuite la gestion de produit n’a rien à voir avec le Marketing. Je vais m’appuyer sur les anglicismes mais Product Management et Product Marketing sont deux activités différentes, opérées par des gens/équipes/départements différents avec des missions/objectives/tâches différents.

Enfin, j’aimerais vous encourager à faire une meilleure distinction entre le PM et le PO. J’ai vu ça dans plusieurs de vos vidéos. Le PM est une personne et un métier et le PO est un rôle Scrum. un chapeau qui va être pris par quelqu’un, typiquement le gestionnaire produit. PO n’est pas un métier, mais un ensemble de taches/responsabilités/activités pour appliquer Scrum. Ces activités sont un sous-ensemble des activités d’un gestionnaire produit. Quand le chef produit fait de la recherche utilisateur, cherche à comprendre et valider les problèmes à résoudre, ça rentre dans le périmètre de la gestion produit, Scrum ne détaillant absolument pas comment effectuer tout le travail en amont du remplissage du backlog, ce qui est normal puisque c’est un framework qui se concentre sur la réalisation/livraison.

Voilà une voix un peu différente, (vous l’aurez compris, je suis coté produit hehe) qui j’espère pourra aider les gens à prendre de meilleures décisions ! :-)

“L’agilité c’est […] un changement de mindset fondamental vers une approche produit”

Je vous partage ma réponse :

Salut Vincent et merci beaucoup pour ton commentaire très intéressant.

Sans remettre en question ton expérience — qui me semble saine et pertinente — de notre côté on a souvent vu, notamment en boîte de conseil/prestation, des coach agiles ou Scrum Masters qui endossaient le rôle de Product Owner le temps d’une mission ou des Product Owners qui endossaient le rôle de coach agile ou Scrum Master le temps d’une mission.

Je pense qu’il y a aussi un lien très fort entre la pratique du métier moderne de Product Manager et l’agilité en général (et donc le coaching agile). Spontanément je pense à John Cutler, dont on est très fans à Scrum Life et qui a maintenant une belle renommée dans la communauté agile en général, qui est Product Manager et qui pourtant parle surtout d’organisation et d’agilité… Sans renier son orientation produit pour autant.

D’une certaine manière c’est assez logique : l’agilité c’est aussi un changement de mindset fondamental vers une approche produit. Sans ce dernier, on est plutôt dans le développement incrémental et itératif (IID), ce qui apporte déjà beaucoup de valeur mais cela reste néanmoins une fraction de ce que peut apporter l’agilité.

Concernant Scrum qui serait un framework qui se concentre sur la réalisation et la livraison, je pense qu’on peut en débattre. Ainsi, les bonnes pratiques techniques ne sont pas abordées (contrairement à XP, Extreme Programming, dans lequel les pratiques techniques sont fondamentales) mais Scrum précise clairement que la qualité n’est pas négociable. De la même manière, Scrum ne donne a priori pas beaucoup d’éléments pratiques pour mettre en place une véritable approche produit, mais on retrouve par contre au coeur de Scrum l’objectif de sprint : Constantin et moi avons découvert que la “bonne” manière d’utiliser l’objectif de sprint implique une approche véritablement produit — sinon, on est souvent mieux avec un framework orienté visualisation et optimisation du flux de travail type Kanban.

Enfin pour la différence entre Product Manager et Product Owner, je vois en quoi notre discours peut être ambigu. Nous alternons entre la réalité du terrain où les deux rôles sont distincts (parfois pour de bonnes raisons, souvent pour de mauvaises) et notre propre vision dans laquelle les activités de Product Management devraient faire partie intégrante de l’équipe agile. À chaque contexte sa solution, évidemment, mais nous en avons assez de voir ces équipes “orientées delivery” qui perdent de vue le sens profond de leur travail et qui auraient tellement à gagner à mettre en place une intelligence collective impliquant toute l’équipe.

Encore merci pour le partage de ton avis, complémentaire à la vidéo !

— JP

Scrum pense-t-il produit ou réalisation ?

Selon moi…

• Un bon objectif de sprint est une déclinaison de la vision produit à l’échelle d’une à quatre semaines

• Utiliser Scrum pour encadrer une activité de réalisation est un non-sens : comment adapter en cours de sprint le plan du sprint (le backlog de sprint) pour réussir à atteindre l’objectif de sprint si on ne prend pas de la hauteur à un niveau produit pour bien répondre à des problèmes et non implémenter des solutions ?

• La bonne organisation est l’organisation adaptée au produit lui-même : comment le définir, le concevoir, le réaliser, le livrer, en tirer et exploiter du feedback

Qu’en pensez-vous ?

J’aimerais avoir votre avis sur cette question. Qu’en pensez-vous ? Répondez-moi en commentaire ici-même ou sur la discussion d’origine sur YouTube.

Si vous avez aimé cet article, merci de le liker ainsi que de le partager !

À bientôt 😊

Pour aller plus loin

La vidéo commentée : “Scrum Master VS. Product Owner”

Scrum donne son maximum pour la construction de produit

Devez-vous utiliser Scrum ? (les prérequis de Scrum)

Product Owner VS. Product Manager : Scrum se concentre-t-il sur la réalisation et la livraison ? was originally published in Jean-Pierre Lambert's blog on Medium, where people are continuing the conversation by highlighting and responding to this story.