Dans le contexte de Scrum et en matière d’Agilité en général, on fait fréquemment référence à la notion de transparence. Je la qualifierais même de valeur fondamentale de ces approches qui cherchent à faire des individus et de leurs interactions des éléments essentiels de la réalisation d’un projet.
La transparence est à la fois une façon d’être et une caractéristique qui peut s’appliquer à certains processus de travail inhérents à la méthode Scrum. Dans toutes ses manifestations, elle demande du courage et de la discipline. En effet, il n’est pas toujours facile d’affronter tous les sujets sensibles et d’avoir certaines conversations difficiles. Tout comme il est souvent ardu d’effectuer les tâches nécessaires à une transparence pleine et entière des processus. Par contre, lorsque l’on prend la peine de le faire, on obtient généralement d’excellents résultats en matière de relations de travail harmonieuses et d’efficacité globale.
Ce courage et cette discipline viennent souvent avec l’expérience. Ainsi, la maturité acquise au fil des ans permet de faire la part des choses et d’établir une distinction claire entre les sphères personnelle et professionnelle. Cette distinction est importante, car elle permet de ne pas transposer inutilement le côté négatif de certaines problématiques de travail dans la vie privée. L’expérience met également en relief l’importance de la transparence au sein des processus. Tant de temps est perdu en raison d’une communication déficiente…
Scrum
La méthode Scrum s’appuie sur un contrôle empirique des processus au sein duquel les connaissances sont acquises par l’expérience et les décisions basées sur des faits observés. Son approche itérative et incrémentale permet de contrôler les risques et d’améliorer le caractère prévisible du processus. Selon Scrum, les trois piliers qui soutiennent la mise en place d’un contrôle empirique des processus sont la transparence, l’inspection et l’adaptation. Nous nous intéressons donc ici à la transparence.
Pour que tous comprennent de la même façon ce qu’ils observent (empirisme), il est nécessaire que l’on définisse un standard commun et que tous les aspects importants du processus soient visibles et bien communiqués. Par exemple, l’équipe chargée de la réalisation doit partager la même« définition de terminé » que celle en charge de valider la livraison. De plus, les différents éléments du processus et des définitions doivent évidemment être élaborés en utilisant une sémantique partagée par tous.
La définition de terminé
Quand une tâche du Product Backlog ou un incrément est considéré comme terminé, tous doivent comprendre ce que cela signifie et implique. Le sens peut varier significativement d’une équipe Scrum à l’autre, mais pour assurer la transparence, les membres doivent avoir une compréhension commune de ce que signifie un travail terminé. C’est ce dont il s’agit lorsque l’on parle de « définition de terminé ». Elle est utilisée pour évaluer si le travail est complété lors de la livraison d’une fonctionnalité ou d’un incrément et est directement dépendante de la transparence à tous les niveaux.
Les cérémonies
Les cérémonies de Scrum offrent la chance d’inspecter et de s’adapter. Elles ont pour but de permettre la transparence et l’adaptation, et c’est une des raisons pour lesquelles il ne faut pas les négliger. La transparence des tâches du Product Backlog peut varier en raison de leur degré de précision et de clarté qui est lui-même fonction d’activités menées par l’équipe durant les cérémonies pour atteindre ce niveau de détail.
Les artéfacts
Les choix effectués dans le but d’optimiser la valeur et de contrôler les risques sont faits à la lumière de l’état des artéfacts. Plus leur transparence est entière, plus ces choix seront judicieux. Les différents intervenants (l’équipe, le Scrum Master et le Product Owner) doivent s’assurer de cette transparence. Pour ce faire, ils peuvent notamment examiner la différence entre le résultat souhaité et le résultat obtenu.
Le Scrum Master doit travailler avec l’équipe afin d’accroître la transparence au fur et à mesure de la progression. Il peut avoir recours à de la formation continue et du coaching pour faire cheminer les gens vers une plus grande transparence. Il pourrait devoir faire preuve de patience, car c’est généralement beaucoup plus facile à dire qu’à faire.
Le client
Plus on décèle rapidement les problèmes et plus on communique rapidement et honnêtement à propos de ceux-ci, moins ils affecteront la productivité, l’efficacité et surtout le résultat final. Il faut inclure le client dans ces discussions afin de ne pas traîner de « dette de transparence » auprès de lui.
Une transparence soutenue et durable génère plus de confiance dans la relation entre le client et son fournisseur et permet de part et d’autre de mieux gérer les risques. L’utilisateur final peut fournir un feedback très précieux pour s’assurer que la solution reste alignée sur le besoin.
Mensonge blanc
En terminant, j’aimerais souligner que l’honnêteté ou la franchise ne sont pas nécessairement synonymes de transparence. On peut dire la vérité mais omettre de révéler certaines choses. Ma compréhension de la transparence implique que l’on rende accessible la totalité de l’information disponible. Tous les intervenants ont alors accès à la même base commune pour se forger une opinion éclairée.
On dit que toute vérité n’est pas bonne à dire. Même si dans la vie de tous les jours, on peut recommander d’avoir du tact et de taire certaines vérités qui pourraient choquer ou faire de la peine à nos interlocuteurs, j’ai souvent été surpris de constater que la plupart du temps les gens préfèrent entendre la dure vérité que de se leurrer parce leur vis-à-vis a du mal à assumer sa position.
2 Commentaires
Ultimement, le Product Backlog doit s’avérer la source de vérité centrale d’un projet. Toute dérogation au sujet des critères d’acceptation, des Definition of Ready/Done et du statut des tâches crée une interférence qui empêche la collecte de métriques essentielles à l’évolution d’une équipe Agile.
Dans cette optique, j’éprouve une réticence en ce qui a trait de la transparence des Story Points tels qu’utilisés en Scrum. Pour la majorité des clients et autres parties prenantes, cette pondération arbitraire et spécifique à une équipe est obtuse et ne répond pas directement à la question fondamentale “Dans combien de temps cette tâche sera complétée?” (et sa corollaire “Combien cette tâche me coûtera-t-elle?”).
Cette inquiétude est un des facteurs pour lesquels mon équipe de développement s’est dirigée vers une approche Scrumban, dans laquelle nous effectuons des prédictions de temps cyclique plutôt que des estimations en Story Points : “Généralement complété en 15 jours ou moins à partir du début de l’analyse technique” est bien plus intuitif que “5 Story Points dans le prochain sprint”!
Merci pour ces considérations très pertinentes. En effet les questions de temps et donc de coût sont souvent au premier plan.