Le bisou qui guérit tout et le scotch magique
Il était une fois l’histoire d’une petit fille prénommée Iris. Quand elle avait autour de 3 ou 4 ans, le monde était encore merveilleux pour elle.
Elle m’a vu soigner ses petits bobos avec des bisous magiques de papa qui guérissent tout.
Et elle m’a vu également réparer rapidement des petits jouets avec un bout de scotch pour qu’elle puisse repartir jouer immédiatement avec son jouet.
Le scotch est devenu un véritable artéfact magique aux yeux d’Iris ! Dès que quelque chose était cassé, il suffisait selon elle de mettre un morceau de scotch. Et voilà !
Malheureusement, heure après heure, sous le scotch, les pièces du jouet continuent à être en tension et la fêlure cachée s’agrandit ! Et un triste jour, le jouet favori se retrouve non plus abimé mais bel et bien cassé, sans plus d’options de réparation pérenne.
Finalement, le jouet n’a jamais été vraiment réparé. Le problème n’a fait que s’accroitre malgré la solution temporaire rapide et les conséquences à plus long terme sont lourdes.
Décryptage de l’archétype rencontré
D’un point de vue systémique, l’archétype mis en œuvre ici est fréquemment rencontré dans les systèmes qui nous entoure. Il est si fréquent qu’il porte son propre nom, à savoir « Shifting the Burden », que je propose ici de traduire par « Transfert de charge » dans la langue de Molière.
Son fonctionnement est le suivant :
- Un problème symptomatique est identifié
- Une solution symptomatique est mise en œuvre rapidement qui soulage temporairement et facilement le problème, mais à terme, cette solution aggrave la situation par des effets de bord indésirables
- Une solution fondamentale, plus exigeante existe et aurait pu atténuer durablement le problème symptomatique
- Malheureusement, plus on tarde à mettre en œuvre la solution fondamentale en se contentant de la solution symptomatique, plus les effets de bords de la solution symptomatiques se font ressentir, rendant l’application de la solution fondamentale de plus en plus exigeante et délicate
Illustration dans la réparation de Scrum
Cet archétype est souvent rencontré lorsqu’une Scrum Team dévie de la structure canonique, à savoir un seul et unique Product Owner, des Développeurs et un Scrum Master.
Par exemple, en cas de nombreuses dépendances entre plusieurs Scrum Team, une solution symptomatique est d’ajouter des rôles spécialisés dans la gestion de ces dépendances, lesquels vont s’accrocher à leur rôle plus que d’aller dans le sens de la mise en place de la solution fondamentale consistant à ce que les Développeurs forment des « Feature Teams ».
Dans le cas d’une jeune équipe, qui manque de maturité ou d’expertise technique, une solution symptomatique consiste à introduire un rôle spécialisé de « Leader » ou de « Technical Leader » ou d’expert sur une technologie très pointue qui risque de freiner la responsabilisation de l’ensemble des Développeurs et la montée en compétence nécessaire sur le long terme.
Attardons-nous sur un autre scénario fréquent qui est celui d’Oscar, Product Owner sur un Produit qui donne grande satisfaction.
La réussite du produit d’Oscar amène l’entreprise à mettre beaucoup plus de moyens dans l’équipe et de renforcer celle-ci en triplant le nombre de Développeurs.
Le système s’organise alors en plusieurs Scrum Team, Oscar restant dans un premier temps l’unique Product Owner de l’unique produit.
Les Développeurs sont consciencieux et expliquent à Oscar qu’il n’a qu’à continuer à exprimer clairement les fonctionnalités qu’il attend pour son produit, ils ont les compétences pour les réaliser rapidement et efficacement. Ils se comportent encore à ce stade comme des mercenaires au service du Product Owner qui clarifie sa commande.
Malheureusement Oscar se retrouve débordé par le stress lié au travail d’alimentation des multiples équipes.
Oscar demande conseil à deux consultants Tanguy et Imane, payés à transformer l’entreprise en un temps record. Les consultants lui conseillent d’introduire des rôles en intermédiaires entre lui et les Développeurs, et d’avoir des Product Backlog différents pour chaque équipe. Evidemment, il est important de donner à ces nouvelles personnes des symboles de leur nouveau pouvoir, en particulier via l’identification d’un nouveau titre qui leur est spécifique, différent des Développeurs et de notre Product Owner.
L’effet de bord négatif qui apparait rapidement est un transfert de responsabilité sur ces faux Product Owners, qui handicape l’appropriation et l’apprentissage des équipes sur le Product Management.
En outre, chaque nouvelle équipe de « mercenaires » focalisée sur la fabrication des fonctionnalités dans ce que l’on nomme trop souvent une « Digital Factory » ou une « Feature Factory » représente des dizaines de personne de plus à faire monter un jour en compétence sur les sujets de Product Management pour en faire des « missionnaires » du produit. Plus le nombre de Développeur croit, plus l’inertie du système devient importante et plus il est difficile de corriger la trajectoire.
Enfin, l’introduction des rôles intermédiaires va naturellement éloigner le Product Owner, qui est focalisé sur la stratégie du Produit, des Développeurs, qui sont focalisés sur la fabrication des fonctionnalités.
La solution fondamentale est bien d’avoir une équipe de missionnaires engagés sur le produit, et non une simple équipe de mercenaire au service du client représenté par le Product Owner.
Avec cette solution fondamentale, les équipes se voient encouragées à s’approprier le Produit avec le Product Owner qui se focalise sur la clarification du cap. Les Développeurs accroissent leur compétence en Product Management, en expertise UX, en expertise fonctionnelle et prennent leur responsabilité et leur autonomie pour aller spontanément clarifier les besoins et fonctionnalités eux-mêmes directement avec les utilisateurs, les clients voire les experts identifiés.
D’autres scénarios ?
Dans votre contexte, quelles solutions avez-vous vu mettre en place récemment qui ne feraient qu’atténuer temporairement le problème, et ainsi vous détourner d’une amélioration pérenne de votre système ?
Comment la simplicité de Scrum a-t-elle été mise à mal ?
Quelles responsabilités surnuméraires avez-vous vu être introduites, limitant l’autonomie, l’auto-gestion et autres bénéfices de Scrum ?
Quel modèle mental a guidé la prise de décision ?
Cet article est très largement inspiré du livre de Cesario Ramos et Ilia Pavlichenko : "Creating Agile Organizations".
images issues de https://unsplash.com/fr/