Scrum Guide 2020
2021-03-10
Elle était attendue : en novembre 2020, une nouvelle version du Scrum Guide a été présentée. Cette version qui induit un changement de position important a fait réagir de nombreux experts et a secoué le monde de l’agilité. Les premières réactions étant passées, la Comet’ Agile d’Extia a posé une question : « Pensez-vous que ces évolutions ont changé votre contexte de travail ? ».
Pour tenter d’y répondre, les Comet’ ont proposé un atelier participatif animé par des Scrum Master et Coach Agile afin de revenir en détail sur ces modifications et comprendre les changements induits.
Après avoir présenté les évolutions de cette nouvelle version, ils nous ont partagé leur expérience et leur ressenti sur ces nouveautés. Pour mesurer l’utilisation concrète de Scrum, les participant(e)s ont décrit leurs pratiques sur des éléments clés. Ces pratiques ont ensuite été mises en perspective afin de qualifier les impacts. La majorité a déjà eu l’occasion de pratiquer Scrum, cependant certains ont profité de cette séance pour venir découvrir l’agilité.
Sur la plus grande partie des points, la majorité des participant(e)s semble appliquer le Scrum Guide tel qu’il est décrit dans sa version 2017. En revanche, pour la planification de Sprint, les usages sont plus variés. La séance a permis de revenir sur l’ensemble des pratiques, pour les recontextualiser selon les versions du Scrum Guide. Découvrez ci-dessous les principaux changements qui ont été présentés.
La création d’une vision centrée produit
La notion d’Objectif de Produit (Product Goal) a été ajoutée, demandant au PO (Product Owner) d’avoir une vision à long terme du produit. L’ensemble des pratiques décrites par le Scrum Guide vise ensuite à faire un nouveau pas vers l’atteinte de cet Objectif Produit. Le Product Backlog contient donc les fonctionnalités nécessaires pour répondre à l’Objectif de Produit, la planification de Sprint vise à construire un Objectif de Sprint qui contribue au produit, et les Daily sont uniquement tournées vers l’Objectif de Sprint.
Des responsabilités revues
Là où son prédécesseur décrivait des rôles, le Scrum Guide expose à présent des responsabilités. Ainsi, la nouvelle version fait tomber la barrière qu’il y avait au sein de la Scrum Team entre PO, SM et Dev Team pour ne décrire qu’une seule équipe. Le Product Owner gagne la responsabilité de décrire l’Objectif de Produit et doit s’assurer qu’il soit compris par tous. Ainsi, la planification de Sprint a une étape supplémentaire « Pourquoi ce Sprint est-il important ? » visant à vérifier que l'objectif de Sprint qui en ressortira soit raccord avec l’Objectif de Produit.
Le Scrum Master devient redevable de l’efficacité de l’équipe. Il était vu comme un « servent-leader », il devient un « true-leader ». Si le Scrum Guide ne le décrit pas pour autant en chef de projet, il devra mettre en œuvre les méthodes qui lui semblent nécessaires pour atteindre les objectifs fixés par l’équipe.
La Definition of Done (DoD), pratique agile souvent recommandée au même titre que la Definition of Ready (DoR), prend place dans cette version du Scrum Guide. La DoD devient l’engagement qualité de l’équipe et doit être respectée pour créer de l’incrément. Si l’adage tiré d’un célèbre comic « De grands pouvoirs impliquent de grandes responsabilités » est souvent vérifié, nous pouvons penser que sa réciproque est vraie. Le Scrum Guide semble aller dans ce sens en décrivant des équipes autogérées là où elles n’étaient qu’auto-organisées.
L’amélioration continue
La notion d’amélioration continue n’est pas décrite en tant que telle, mais transparaît à travers des éléments instaurés pour y contribuer. La DoD, l’Objectif de Sprint et l’Objectif de Produit deviennent des métriques permettant de clarifier les objectifs pour l’ensemble des parties. Les livraisons sont désormais à faire dès que nécessaire et non plus seulement en fin d’itération. Les équipes sont donc encouragées à mettre en place une philosophie DevOps afin de réduire le poids de ces livraisons, pour augmenter leurs fréquences et favoriser les retours sur le nouvel incrément.
La rétrospective a pour optique de prendre des décisions allant dans le sens de cette amélioration continue. L’équipe mettra en œuvre les moyens appropriés pour identifier les éléments pouvant être améliorés, et devra les suivre dans le Sprint. En recentrant le Guide sur ses piliers que sont la transparence, l’inspection et l’adaptation, Scrum favorise la qualité des livrables et de la communication. On retrouve Le Cercle d’Or de Simon Sinek en mettant au cœur des échanges le « WHY » sur lequel l’équipe travaille. Cela favorise la relation avec les parties prenantes, la sécurité psychologique et le bien-être de l’équipe.
Un guide moins prescriptif
Cet élément est le premier annoncé et le premier visible lorsque l’on compare les versions. Le nombre de pages est réduit de plus d’un tiers et le vocable propre au monde de l’informatique est écarté. C’est un virage complet par rapport aux précédentes versions, le paragraphe décrivant l’application de Scrum dans l’informatique était précisément un ajout de la version 2017 à 2016. Il existe une volonté de rendre Scrum plus accessible et de l’ouvrir à d’autres domaines d’application. Le Scrum Guide ne délivre pas une liste d’ateliers à pratiquer, mais demande à l’équipe de veiller à l’atteinte de ces objectifs. Il faut garder en mémoire que Scrum n’est pas une boîte à outils, mais fixe un cadre dans lequel l’équipe peut s’épanouir. Scrum n’a pas toutes les réponses, mais donne le moyen de les trouver.
N’hésitez pas à suivre les Comet' sur Twitter @CometByExtia