Dans Scrum, on tient à une utilisation précise du langage, d’autant que tout ce qui n’est pas précis concourt à un manque de transparence. Or, quand on essaie d’implémenter Scrum, on peut faire l’expérience d’une certaine pression à adapter les terminologies et leurs significations, pour que les changements soient adaptés à l’organisation qui les accueille. Les termes de référence de Scrum peuvent alors être tournés et détournés pour coller aux contours existants. La conséquence ne se fait pas attendre : la façon même dont nous pouvons penser le changement agile se retrouve vrillée et contrainte par le poids de l’organisation.
Quoi qu’il en soit, nous sommes toujours sujets au poids organisationnel, et aussi rigoureux ou prudent que l’on soit, on ne peut pas entièrement se protéger de son effet. Un effort de discipline que nous pouvons toutefois mener peut consister à exercer des petites corrections, très vite et très souvent, avant que ne s’installent définitivement des mauvaises pratiques. Voici 20 de ces « petites choses » que nous pouvons être tentés de dire ou bien auxquelles on peut acquiescer silencieusement et qu’il serait peut-être préférable d’éviter…
1 - "Sprint Backlog"
Évitez de décrire le « Sprint Backlog » comme un « engagement ». C’est un « plan » ou une « estimation » du travail à accomplir en vue d’atteindre l’objectif du sprint. Il vaut mieux utiliser ces mots. Et il faut se souvenir que les membres de l’équipe s’engagent sur des buts et non sur des prévisions.
2 - "Story Points"
Evitez des éléments de langage qui pourraient suggérer que les Story Points sont « livrés » , ou d’une certaine manière constituent une valeur ou bien une façon d’estimer la valeur. L’objectif des Story Points est d’aider une équipe à prévoir quelle quantité de travail elle pense pouvoir embarquer. Dans une pratique agile, la valeur ne se trouve que dans l’incrément de travail qui est livré.
3 - "Vélocité idéale"
Évitez de parler d’une « vélocité idéale » quand vous faites des prévisions. À la place, parlez d’une valeur idéale qui peut être livrée dans le Sprint courant et les Sprints à venir. Il faut se souvenir qu’une équipe agile n’est pas constituée de « comptables des Story Points », mais de développeurs.
4 - "Objectifs de Sprint"
Évitez de parler d’ « Objectifs de Sprint » quand ces objectifs supposés n’ont pas été planifiés et acceptés par l’équipe. Si ce sont des tentatives d’objectifs de sprint, alors appelez-les comme ça.
5 - "Sprint et sprints spéciaux"
Évitez de parler des différentes étapes de la production d’un travail en tant que « Sprint » si elles ne sont pas comprises dans un time box et qu’elles ne produisent pas un incrément de fonctionnalités. Des sprints « spéciaux » comme le « sprint zéro », le « sprint d’intégration », le « sprint de test », sont en réalité des étapes ou des phases. S’il est nécessaire qu’il y en ait, ce n’est pas grave, mais ayons l’honnêteté de les appeler par leur nom et de ne pas dévaluer des termes de référence dans l’agile.
6 - "Démonstration"
Évitez de décrire une revue de sprint par le terme « démonstration ». Une démonstration du travail effectué peut tout à fait faire partie d’une revue de sprint. En revanche, l’objectif principal d’une revue de sprint est de considérer le travail effectué et le travail qui reste à faire est d’inspecter et d’adapter le Product Backlog.
7 - "Kanban"
Éviter de parler d’un « Kanban » à moins que le tableau dont vous parlez ne soit lié explicitement à la description d’un système de flux. Si votre tableau fonctionne en définitive plus comme une « to do list », donnez-lui ce nom-là.
8 - "Definition of Done"
Évitez d’appeler des critères d’acceptance la «Definition of Done ». Les critères d’acceptance font partie de la « DOD » pour certains produits du Backlog, mais la Définition of Done, qui atteste de la qualité globale du produit livré dépasse ce cadre.
9 - "Équipe"
Évitez de parler d’ « équipe » à moins qu’il n’y ait qu’une claire évidence que l’assemblage de personnes auquel vous faites référence pratique au quotidien une collaboration directe et continue. Si les personnes travaillent dans des silos qui sont indépendants les uns des autres, et de temps à autres se réunissent sur un projet, il vaut mieux alors parler d’un « groupe de travail » qui est engagé autour d’une production commune.
10 - "Outils-support VS pratique"
Évitez de faire référence à une initiative agile en parlant de ses outils-support. Se tourner vers une pratique agile n’est pas du même niveau qu’« avoir Jira » ou bien « utiliser TFS » et ce, quelle que soit la technologie employée.
11 - "DevOps"
Évitez de parler de « DevOps » comme si cela était distinct d’une pratique agile ou d’un changement dans la culture de travail. Si vous faites référence à des pratiques techniques comme l’automatisation ou l’intégration continue ou le déploiement, préférez utiliser ces termes.
12 - "Dette technique"
Évitez d’utiliser le terme « dette technique » si vous n’avez pas défini de stratégie pour la résorber ou même que le risque qu’elle peut représenter n’est ni contrôlé, ni même correctement défini. Il vaut mieux dans ce cas-là parler d’une « boîte noire ».
13 - "Plan de Release"
Évitez le terme « Plan de Release » quand certains sprints ne sont pas destinés à figurer dans une Release. Ce dont vous disposez est, en fait, un plan de non-release. Dans Scrum, chaque sprint doit produire un incrément de valeur, aussi petit soit-il. La décision de procéder ou non à une Release doit être faite en fonction du respect du Just-In-Time. Un vrai plan de Release devrait mettre en avant ce qu’il est vraisemblable de délivrer, pas si une Release va se produire ou non.
14 - "Bogues et défauts"
Évitez de parler des « bogues » ou « défauts » comme s’ils étaient séparés du reste du travail à faire. Ils doivent être inclus dans le travail qui reste à faire et donc planifiés et budgétés en conséquence. L’urgence de la réparation et/ou la vitesse à laquelle elle doit être effectuée ne doit pas être un frein à la transparence.
15 - "Périmètre fixe"
Évitez de parler de « Périmètre fixe » quand un Product Backlog est sans arrêt en cours de raffinage et que des options nouvelles peuvent être amenées à surgir. Il vaut mieux considérer que chaque sprint est une opportunité de livrer des éléments contenant de la valeur pour le client, susceptibles de leur apprendre des choses importantes.
16 - "Envoyer en test"
Évitez l’effet de langage qui consiste à parler de « envoyer en test » qui suggère qu’on peut attendre autre chose que du flux tiré. Les pratiques agiles et Lean sont basées sur le flux tiré, qui porte avec lui les notions d’une gestion du travail efficace répondant à des signaux clairs.
17 - "Équipes distribuées"
Évitez de faire référence à des équipes « distribuées ». Une équipe qui n’est pas co-localisée est une équipe « non regroupée » ou « délocalisée ». Donnez-lui ce nom là et soyez transparent et ouvert à propos des difficultés et des inefficacités du travail en équipe qui peuvent vraisemblablement surgir d’un tel modèle.
18 - "Sens de l'expression "être agile""
Éviter d’utiliser l’expression « être agile » comme un euphémisme d’ « être réactif » ou encore faire le travail « plus vite et moins cher ». Une équipe agile est une équipe qui a le contrôle total de son travail en cours et des tâches qu’elle décide d’embarquer. Les économies qui seront faites viendront de la capacité de l’équipe à pratiquer l’amélioration continue, à grandir dans sa capacité à évaluer sa vélocité de manière empirique, et à réduire le gâchis.
19 - "Agile à l'échelle"
Évitez de parler de « agile à l’échelle » alors que la transformation de l’organisation de l’entreprise doit encore être menée pour que, même une seule équipe puisse, dans les faits, arriver à une manière agile de travailler.
20 - "Collaborateurs = ressources"
Et, enfin, évitez cette tendance à la déshumanisation des collaborateurs en parlant d’eux comme de « ressources » ou même « jour/homme ». Si vous conceptualisez les personnes comme des objets inanimés, vous obtiendrez des mêmes personnes moins que ce qu’elles ont à donner. Les collaborateurs sont des personnes humaines dotées d’un potentiel de créativité et d’innovation ; traitez-les comme tel.
Je remercie l’auteur Ian Mitchell de m’avoir permis de traduire et d’adapter son article en langue française, également consultable dans sa version originale.
Maintenant que vous en savez un peu plus sur "Comment parler agile ?", n'hésitez pas à aller consulter nos articles précédents pour comprendre notre conception de l'agilité chez ANEO et vérifier que vous n'êtes pas tombés dans le piège des absurdités les plus souvent rencontrées !
