Une nouvelle version du Scrum Guide a été dévoilée en novembre 2020. Un évènement ? Tout est relatif, mais voyons déjà ce qui change, pourquoi et quels impacts sur nous.
Eh bien… ça n’est pas important ! Par contre, cette nouvelle version, je la trouve intéressante.
Intéressante car, comme nous allons le voir, les modifications sont une véritable réponse aux pratiques que nous pouvons voir dans les implémentations de Scrum depuis des années. Les bonnes et surtout les mauvaises.
Autant le dire, la version 2020 est une réécriture du Scrum Guide. Elle n’a plus grand-chose à voir avec la version 2017 dans sa forme.
Comme je vous le disais, rien que cette suppression (agile) et cet ajout (lean) sont intéressants. Si vous n’êtes pas sûr de la signification de “lean”, je vous invite à aller voir la page wikipedia sur le sujet.
Rien. Juste quelques éclaircissements.
Vraiment… Scrum, ne change pas. Par contre pour beaucoup, la compréhension de Scrum peut changer. Et c’est justement, à mon avis, la raison de ces changements sur la forme. Comme écrit plus haut, le Scrum Guide a été réécrit, alors c’est forcément pour une bonne raison, non ?
Je vais vous donner mon avis sur les raisons de ces changements :
Nous allons voir en détail les points les plus impactant pour les équipes (nous verrons dans un autre article ce qui change pour les parties prenantes et toutes les personnes en dehors de l’équipe), mais avant, au cas où, voici comment trouver les documents :
Personnellement je vous conseille la version originale (anglaise) si vous le pouvez.
Essayez‐le tel qu’il est et, déterminez si sa philosophie, sa théorie et sa structure aident à atteindre les objectifs et à créer de la valeur. (page 4)
Déjà c’est quelque chose qu’on dit souvent chez Talan Labs depuis des années et ça fait plaisir de le voir écrit dans les premières pages : ESSAYEZ-LE. Avant de dire que telle ou telle partie de Scrum ne va pas dans votre contexte : essayez et voyez si c’est vraiment le cas et pourquoi. Comme toujours, le plus important est de comprendre pourquoi vous prenez une décision.
Si Scrum ou certaines de ses contraintes ne vous aident pas à atteindre vos objectifs, alors Scrum n’est pas adapté. Si c’est votre système ou votre fonctionnement qui vous empêche d’utiliser Scrum pour atteindre votre objectif… alors c’est peut-être à vous de changer, qui sait ?
Le cadre de travail Scrum est volontairement incomplet […] Divers processus, techniques et méthodes peuvent être employés dans ce cadre de travail. (page 4)
Scrum ne suffit pas. Il faut d’autres choses, qui ne sont pas dites dans Scrum car elles dépendent entièrement de votre context et de votre domaine.
Un Product Owner ordonne le travail à faire pour résoudre un problème complexe dans le Product Backlog. La Scrum Team transforme une sélection de ce travail en un Incrément de valeur lors d’un Sprint. La Scrum Team et ses parties prenantes inspectent les résultats et s’adaptent pour le prochain Sprint. (page 4)
J’ai aussi apprécié dans cette version que les piliers de Scrum forment un tout. Nous comprenons alors mieux qu’il faut impérativement les 3 piliers pour ne pas avoir une équipe et un produit bancal.
La transparence permet l’inspection […] L’inspection permet l’adaptation. Une inspection sans transparence est trompeuse et source de gaspillage. Une inspection sans adaptation est considérée comme infructueuse. L’adaptation devient plus difficile lorsque les personnes impliquées ne sont pas en possession de tous leurs moyens ou autogérées. (page 4 et 5)
Un détail, Scrum change la taille maximale recommandée pour une équipe en la fixant à 10 personnes maximum.
Elles sont structurées et habilitées par l’organisation à gérer leur propre travail. Toute la Scrum Team est responsable de la création d’un incrément qui ait de la valeur et qui soit utile, à chaque Sprint. (page 6)
Mais aussi, Scrum définit la Scrum Team comme une équipe auto-gérée là où dans les versions précédentes nous parlions d’auto-organisation. Le sens d’auto-gestion est à mon avis bien plus fort et devrait être le signal que l’équipe doit pouvoir prendre ses propres décisions sur son produit et la façon de le réaliser.
Elles sont également autogérées, elles décident en interne qui fait quoi, quand et comment. (page 6)
Attention néanmoins, comme j’aime bien à le dire, auto-organisée ou auto-gérée ne veut pas dire que l’équipe vit en autarcie. Elle existe dans un monde, dans un environnement et doit prendre en compte les règles et les contraintes de cet environnement, tout comme elle doit s’auto-gérer pour lui permettre de travailler avec les autres équipes de l’entreprise, les clients, les utilisateurs, etc. La gestion se faisant par rapport à tout cela, dans l’équipe.
Scrum définit trois responsabilités spécifiques au sein de la Scrum Team : les Developers, le Product Owner et le Scrum Master. (page 6)
“L’équipe de développement” a disparu pour “éliminer le concept d’équipe dans l’équipe, qui conduit à un comportement « proxy », du « nous et eux » entre le PO et l’équipe de développement.”
Les Developers* sont les membres de la Scrum Team qui s’engagent à traiter tout ou partie utile d’un Increment à chaque Sprint. (page 6)
Responsabilités des “dev” :
Créer un plan de Sprint, un Sprint Backlog Adapter leur plan chaque jour par rapport à l’Objectif de Sprint Se tenir mutuellement responsables en tant que professionnels Inculquer (Instilling) la notion de qualité en adhérant à une Definition of Done
Ici, je ne trouve pas que la traduction française au jour où j’écris ces lignes ait traduit correctement instilling. En effet il existe un mot bien plus proche qu’inculquer en français : instiller dont la définition me parait plus juste par rapport à la version originale :
Faire ressentir peu à peu un sentiment chez quelqu’un.
Pas grand-chose ne change dans les responsabilités de la ou du Product Owner, sauf bien sûr, l’ajout de l’Objectif de Produit :
Formuler et communiquer explicitement l’Objectif de Produit ; (page 6)
Le Scrum Master a subi pas mal d’éclaircissements.
Faire en sorte qu’il n’y ait pas d’obstacles pouvant entraver la progression de la Scrum Team
Il est bien explicite ici que la ou le Scrum Master n’est pas la personne qui s’occupe des problèmes mais bien, qui fait en sorte qu’il n’y en ait pas. Cela peut passer par des actions d’elle-même, ou d’autres.
S’assurer que tous les événements Scrum ont bien lieu et sont efficients, productifs et respectent bien les [timebox]
J’espère que cette formulation montrera bien que non, la ou le Scrum Master n’est pas un animateur de réunion.
Encourager l’application de la planification produit empirique
Ici, nous pouvons montrer que oui, l’équipe et ses parties prenantes doivent écouter l’avis du Scrum Master dans la planification. Non pas sur la pertinence de prioriser une chose, ou d’en retirer une autre. Mais bien de la manière de planifier une construction empirique. Et oui, ce n’est PAS en faisant un backlog de 50, 100 ou 200 éléments avant même de commencer à construire le produit. #empirisme
La ou le Scrum Master est redevable (accountable) de l’efficacité de la Scrum Team
Sûrement la phrase ayant fait couler le plus d’encre numérique depuis sa sortie. Non cette phrase ne change rien à l’approche d’un bon Scrum Master par rapport à la version 2017. Oui, le Scrum Master fait partie de l’équipe, elle ou il mouille sa chemise avec les autres et elle ou il est responsable de l’efficacité de l’équipe. Faire en sorte que l’équipe soit efficace est le but de sa présence, donc pas de dédouanement quand ça ne marche pas, c’est qu’on ne fait pas notre travail correctement. Être accountable, c’est aussi le moyen de se rendre compte qu’on n’est pas là où nous sommes attendu et donc de corriger notre façon de faire. Par contre, avec cette responsabilité, doit venir les pouvoirs qui vont avec.
Le Sprint Planning est maintenant clairement découpé en 3 phases (ou “topic”) : “Pourquoi ?”, “Quoi ?” et “Comment ?” (page 9)
Pourquoi ce Sprint est‐il important ? Le Product Owner explique comment augmenter la valeur du produit et son utilité pour le Sprint en cours. L’ensemble de la Scrum Team collabore ensuite à définir un Objectif de Sprint qui énonce clairement aux parties prenantes l’utilité du Sprint. L’Objectif de Sprint doit être finalisé avant la fin du Sprint Planning.
Que peut‐on faire durant ce Sprint ? En discutant avec le PO, les Developers [personnes réalisant l’incrément] sélectionnent les éléments du Product Backlog à inclure dans le Sprint en cours. Au fur et à mesure de la discussion, la Scrum Team affine ces éléments, améliorant ainsi leur compréhension et leur confiance dans leur capacité à les développer.
Comment le travail choisi sera‐t‐il réalisé ? Pour chaque élément sélectionné du Product Backlog, les Developers [personnes réalisant l’incrément] planifient le travail nécessaire pour créer un Increment qui réponde à la Definition of Done. Cela se fait souvent en décomposant les éléments du Product Backlog en éléments de travail d’une journée ou moins.
Concernant le daily, beaucoup ont remarqué que l’exemple des “3 questions” a disparu. Tant mieux. Trop d’équipes déroulaient ces questions bêtement, sans les comprendre et très souvent même en oubliant les 3/4 de ces questions qui portaient toutes sur l’atteinte de l’objectif de sprint.
Moi ce que j’ai remarqué aussi, c’est la précision du fait que ce n’est pas le seul moment de discussion et de planification :
Le Daily Scrum n’est pas le seul moment où les Developers [personnes réalisant l’incrément] sont autorisés à ajuster leur plan. Ils se réunissent souvent tout au long de la journée pour des discussions plus détaillées sur l’adaptation ou la re‐planification du reste du travail du Sprint. (page 10)
La revue de sprint (Sprint Review) a subi, à mon sens, les plus gros éclaircissements et simplifications. Et elle en avait besoin !
Voici la nouvelle première phrase :
L’objectif de la Sprint Review est d’inspecter le résultat du Sprint et de déterminer les adaptations futures. (page 10)
Il y a moins la notion de “on a fait un truc, on passe à un autre truc”.
Un Incrément peut être livré aux parties prenantes avant la fin du Sprint. La Sprint Review ne doit jamais être considérée comme le seul moment pour délivrer de la valeur. Afin de fournir une valeur, l’Incrément doit être utilisable. La Sprint Review est une session de travail et la Scrum Team doit éviter de la limiter à une session de présentation.
Clairement ici, Scrum veut casser le rythme des équipes faisant juste une démo en lieu de la revue.
J’aime.
Ils sont maintenant plus clairs et servent un objectif à chaque échelle (page 11) :
Chaque artefact contient un engagement qui apporte l’information nécessaire à la transparence et au focus rendant possible la mesure de la progression : Pour le Product Backlog, il s’agit de l’Objectif de Produit Pour le Sprint Backlog, c’est l’Objectif de Sprint Pour l’Incrément, c’est la Definition of Done
L’Objectif de Produit décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier. L’Objectif de Produit est dans le Product Backlog. Le reste du Product Backlog émerge pour définir « ce qui » permettra d’atteindre l’Objectif de Produit.
L’Objectif de Produit est l’objectif à long terme de la Scrum Team. Ils doivent atteindre (ou abandonner) un objectif avant de s’attaquer au suivant (page 12)
Tout ça pour quoi ?
Pour les équipes qui faisaient preuve de bon sens, de recul, de transparence et d’inspection, c’est un non-évènement. Elles devraient même plus se retrouver dans cette version de Scrum.
Pour les autres… Eh bien le rôle “d’exécutant” des codeuses/codeurs, designer et autres experts devrait être plus flagrant. Dans Scrum, plus que jamais, celles et ceux qui réalisent le produit sont des créateurs, plutôt que des exécutants. Une équipe Scrum conçoit, réalise un produit, en tant qu’équipe. Codeuses/codeurs, designer et autres experts aident le produit à émerger, à se développer. Le rôle de “PO-Passe-Plat” devraient donc être aussi plus visible, comme étant peu efficace ou valorisant.
Pour ces équipes, le Scrum Guide peut être utilisé comme une carte d’un chemin à prendre pour être plus efficace et pour construire le bon produit, plutôt que le produit que vous voulez faire.
Répétons-le encore une fois : Scrum n’est pas un but. Les clients et les utilisateurs s’en fichent de ce que vous voulez faire, ce qui leur importe, c’est ce qu’ils veulent faire eux.
