Avis aux adeptes de Scrum : la version du Scrum Guide 2020 vient de paraître. Notre experte Roxane Meyer se penche ici sur les impacts opérationnels et stratégiques de ces modifications – et vous partage ses convictions.
Pour rappel, Scrum est un est un des cadres de travail Agile des plus utilisés au sein des organisations. Sa promesse : organiser les projets de façon simple, transparente et pragmatique.
Il offre à ce titre de nombreux avantages en permettant une gestion, plus intelligente du travail, en améliorant l’efficacité des équipes et en garantissant une meilleure visibilité du projet et de son évolution.
En définitive, si votre projet est :
Innovant : Une conception laissant place à la créativité
Porteur de paramètres inconnus : Besoins, technologie ou délais
Complexe : Articulation de plusieurs équipes, métiers, domaines
Alors le cadre de travail Scrum est fait pour vous.
Initialement utilisé pour le développement Software, Scrum abandonne dans sa nouvelle version les termes dédiés à l’informatique pour laisser place à un vocabulaire à destination de toutes les équipes adressant des problématiques complexes (développer une application, développer un nouvel objet connecté, porter un projet de réorganisation, redéfinir son offre de service, mener la campagne d’adoption d’un outil…)
Cette simplification promet une approche plus inclusive et de nouvelles opportunités quels que soient les secteurs ou industries et ouvre la porte à de nouveaux métiers : équipes RH, équipes Innovation, équipes de soins….
Nouvelle version 2020 : qu’est ce qui change ?
La définition du Framework Scrum
Si les valeurs et les piliers de du Framework n’ont pas changé, la définition a néanmoins été mise à jour. Elle se veut plus opérationnelle, concrète, en plaçant le Scrum Master et ses objectifs au centre du cadre de travail :
« Scrum est un Framework léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. En bref, Scrum a besoin d’un Scrum Master pour favoriser un environnement où :
Un Product Owner ordonne le travail pour un problème complexe dans le Product Backlog.
La Scrum Team transforme une sélection de travail en un Increment de valeur lors d’un Sprint.
La Scrum Team et ses parties prenantes inspectent les résultats et s’adaptent pour le prochain Sprint.
Répéter
Le langage est également simplifié, pour faciliter la prise en main du cadre de travail et permettre à des équipes non spécialisées dans le développement Software de se lancer dans l’aventure.
Au fur et à mesure des versions, le Scrum Guide se veut de moins en moins prescriptif et élimine certaines pratiques qui ne sont pas considérées comme toujours efficaces ; par exemple, les trois questions à poser pendant le Daily sont supprimées, et l’intégration de solutions d’améliorations dans le Sprint Backlog suite à la Sprint Retrospective n’est plus imposé.
L’allègement des pratiques renforce l’ouverture du Framework ; ce qui pourrait marcher pour une équipe de développement en logiciel peut ne pas être adapté pour une équipe de recherche scientifique ou de ré-organisation.
Point de vue de l’expert – Dans quelle mesure cette nouvelle version du Scrum Guide rend-t-il le cadre de travail plus accessible ?
C’est l’évolution observée depuis quelques années : cette mise à jour vient appuyer les tendances de fond de simplification du cadre de travail. Dès la définition, les rôles sont introduits, les objectifs de chacun définis et on s’aperçoit qu’elle s’adresse à une population plus large que précédemment. Cette mise à niveau s’aligne parfaitement avec les souhaits de Jeff Sutherland et Ken Schwaber de simplifier leur Framework et le rendre accessible à tous. Roxane Meyer, experte Scrum chez Saegus
Une simplification et clarification des rôles
Les arcanes de la méthode Scrum repartissent les membres de l’équipe dans des rôles précis. Chaque rôle porte des prérogatives et des responsabilités particulières qui se connectent mais ne s’échangent pas. Cette organisation se veut bénéfique pour la conservation des objectifs du projet face aux impératifs su projet, qu’ils soient techniques, fonctionnels ou clients. Les membres de l’équipe, jouant leur rôle, maintiennent un équilibre des forces.
La création du Product Goal comme engagement majeur renforce la place de la vision produit dans le processus du projet, et est placé au centre.
Les fondateurs ont également choisi d’accentuer la cohésion dans la Scrum Team en supprimant la notion de « sous-équipe ». Par conséquent, l’équipe de développement fait peau neuve et devient Developers.
L’ensemble des membres du projet appartient donc à la Scrum Team, concentrée sur un seul objectif : celui du Produit. On entend par produit – tout service, objet, concept, ou éléments organisationnels créé par la Scrum Team.
Ils ne sont plus auto-organisés mais auto-managés ; ils décident en autonomie de qui fait quoi, quand, et comment.
Le Scrum Master, expert du cadre de travail Scrum, veille à sa bonne application, anime l’équipe, et facilite le quotidien de l’équipe en éliminant les obstacles. Cependant, la responsabilité de ce rôle manquait de clarté pour certaines organisations. Il est maintenant clairement énoncé que le Scrum Master est imputable d’une part de la méthodologie, mais également de l’efficacité de l’équipe. La valeur livrée est donc sa responsabilité – et l’indicateur de performance du rôle devient plus concrète.
Point de vue de l’expert – ces nouveaux éléments n’induisent-ils pas un nouveau niveau de complexité ?
Au contraire, cette modification permet vraiment de supprimer la séparation entre la gestion du produit et sa réalisation. Finalement c’est toute l’équipe qui est responsable du produit et de l’ensemble des activités pour le réaliser. De plus, aucune relation hiérarchique n’existe entre le Product Owner et les Developers (anciennement Équipe de développement), la suppression de cette sous équipe accentue cette notion. Cela permet de se concentrer sur ce qui est important – la création de valeur par la Scrum Team. La nouvelle version de Scrum porte une différence majeure dans la désignation des « rôles », qui deviennent des « responsabilités ». Ce changement vient en réaction à la démocratisation des rôles de Product Owner et de Scrum Master, qui apparaissent aujourd’hui partout sur LinkedIn et les fiches de postes. La responsabilité réelle de chaque rôle est ainsi revalorisée. Un élément dont ils ne parlent que brièvement et qui a son importance est que les Developers sont composés de tout spécialiste qui réalise le travail : développeurs, chercheurs, analystes, scientifiques, etc. Cette notion est en phase avec la démocratisation du cadre de travail au-delà du développement Software. Pour démocratiser, le nom aurait d’ailleurs pu être réellement revu pour se détacher de développeurs, qui restent encore très connoté IT… peut être une évolution prévue pour la prochaine version ? Roxane Meyer, experte Scrum chez Saegus
Une revue des évènements agiles
Bien qu’induit lors de sa version précédente, dans sa nouvelle version le Scrum Guide affiche clairement que le sprint contient l’ensemble du travail nécessaire pour atteindre le Product Goal tels que le Sprint Planning, Daily Scrums, Sprint Review, ou encore la Sprint Retrospective. Cette formulation induit donc que les réalisations du Sprint Backlog ne sont plus les seules activités servant à l’atteinte du Product Goal, bien que représentant l’activité principale des Developpers.
Le Sprint Planning, qui est l’évènement de planification du Sprint, se voit légèrement restructuré et son déroulé affiné en 3 sujets :
Sujet 1 : Pourquoi ce Sprint a-t-il de la valeur ?
Sujet 2 : Que peut-on faire pour ce sprint ?
Sujet 3 : Comment le travail choisi sera-t-il effectué ?
En plus du « Quoi » et « Comment » connu dans la version 2017, le sujet 1 vient ajouter une notion de « Pourquoi ». Ce « Pourquoi » fait directement référence au Sprint Goal, et vient formaliser ce sujet qui était uniquement induit dans les versions précédentes.
Là où le Sprint Planning s’est vu restructuré, le Daily est devenu un évènement libre et ses 3 questions historiques ne sont plus proposées. Les Developpers choisissent maintenant
Comment dérouler cet évènement tant qu’il reste concentré sur l’avancement vers le Sprint Goal.
Dans la version 2020, si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que Developers.
Le Sprint Review ne voit aucun changement lui être attribué mais une précision importante : cet évènement n’est pas une simple présentation mais une réelle session de travail. Cet évènement doit être l’occasion de collaborer et identifier de nouvelles opportunités autour du produit.
Le Sprint Retrospective, quant à lui, ne voit aucune modification majeure lui être attribuée mise à part une simplification de sa description.
Point de vue de l’expert – quels sont les risques induits par les modifications des événements ?
Il est vrai que lorsqu’on parlait de Sprint on avait tendance à penser uniquement aux US à réaliser. Or, en le pratiquant, on se rend bien compte qu’un sprint est composé de toute activité autour du produit peu importe sa nature (alignement des process métiers pour alimenter le backlog, tests utilisateurs, réalisation des items du backlog…) La participation potentielle du Product Owner et Scrum Master montre bien l’ouverture du Framework à d’autres domaines que le domaine IT. Attention tout de même à ne pas perdre de vue que c’est la réalisation des items du Sprint Backlog qui reste la principale activité autour du Produit. Bien que ravi de l’ajout de la notion « Pourquoi » dans le Sprint Planning, la suppression des questions du Daily dans le Guide peut laisser place à l’incertitude pour les jeunes équipes Scrum, qui pourraient ne pas dérouler correctement cet évènement et en perdre les bénéfices. Globalement, bien qu’en phase avec les modifications apportées qui recentrent sur l’essentiel de chaque évènement, la simplification du contenu et du déroulé de chaque instance – c’est-à-dire moins de détails pour les utilisateurs de Scrum – peut rendre son bénéfice et adoption complexe pour les équipes non-rompues à l’exercice. Le Scrum Master prend alors tout son sens. Roxane Meyer, experte Scrum chez Saegus
Trois engagements supplémentaires pour renforcer l’empirisme de l’approche
Le risque principal du Framework Scrum réside dans le manque d’engagements de la part de la Scrum Team. Ne pas se focaliser sur un objectif précis, tout en suivant à la lettre les processus – les rôles, les artéfacts, les évènements – c’est passer à côté de la raison d’être même de Scrum : créer de la valeur ajoutée pour sa cible.
Les artéfacts représentent la valeur ou le travail livré. Ils ont pour but d’assurer la transparence autour du produit.
A partir de 2020, chaque artéfact contient un engagement (commitment) pour veiller à ce qu’il fournisse des informations qui renforcent la transparence et aide dans la mesure du progrès :
Pour le Product Backlog, c’est le Product Goal :
Le Product Owner porte le Product Goalet le partage avec la Scrum Team (et toute autre personne intéressée par le résultat du produit) qui guidera le travail et les décisions pendant toute la durée du développement produit. Cette nouvelle vision implique des changements dans l’appréhension des projets par les différents membres de l’équipe : le Product Owner est désormais plus orienté succès du produit que succès du projet. L’objectif final est bien de livrer un excellent produit, et non plus d’exécuter le processus projet avec excellence. Chaque Sprint doit dont se rapprocher de l’objectif Produit final (Product Goal) – et le Product Backlog répond aux attentes du Product Goal.
Pour le Sprint Backlog, c’est le Sprint Goal:
La Scrum Team s’accorde sur un Sprint Goal, associé à chaque Sprint Backlog: ce Sprint Goal permet désormais, au début de chaque Sprint, de guider les décisions qui seront prises tout au long de ce Sprint, et également de donner du sens aux tâches à réaliser, et d’améliorer la compréhension des objectifs par l’équipe. Les Developers s’engagent ensemble à respecter cet objectif. Le Sprint Backlog est ainsi adapté au fur et à mesure pour répondre au Sprint Goal.
Pour l’Increment, c’est la Definition of Done :
La Scrum Team s’accorde sur une Definition of Done, qui pour chaque incrément livré décrit la qualité attendue par les parties prenantes du projet. Les Developers s’engagent à respecter cette qualité de livrable adaptée au fur et à mesure pour répondre au Sprint Goal.
Ces engagements existent pour renforcer l’empirisme et les valeurs Scrum pour la Scrum Team et ses parties prenantes.
Le point de vue de l’expert – Quel est l’impact concret de l’introduction de ces nouveaux engagements ?
Finalement si on pratique le Scrum avant sa version 2020, la Definition de Done et le Sprint Goal ne nous sont pas inconnus. Ces deux éléments étaient déjà présents dans les versions précédentes sans pour autant être un évènement, un rôle ou encore un artéfact. En les définissant à présent comme engagement de leurs artéfacts respectifs, l’importance de ces éléments est redéfinie pour les placer au centre de la gestion du produit. Le Product Goal est un nouvel ajout au Framework, qui a pris le pas sur la vision produit (Product Vision). Je reçois cette évolution de façon positive car l’objectif permet réellement de concrétiser la vision produit. Là où la vision était finalement plutôt utopique, le Product Goal permet de concrétiser en se donnant des objectifs mesurables, tangibles, déclinables dans le temps et surtout compréhensibles de tous. Nous le savons, lorsque nous comprenons pourquoi nous effectuons un travail, nous sommes plus engagés, et ce Product Goal vient servir la compréhension du produit sur lequel on travaille. Ce qui pourrait encore manquer au cadre de travail, pour le rendre encore plus généraliste, est finalement la définition d’un produit. Nombreuses sont les personnes qui vont identifier un produit comme un livrable software, là où dans la définition même du mot, un produit est tout objet, bien ou encore service proposé par une entreprise sur le marché. Pour conclure, l’engagement étant l’une des valeurs du Scrum et un gage de réussite d’un projet, cette nouvelle notion d’engagement (commitment) est une évolution nécessaire du Framework. Roxane Meyer, experte Scrum chez Saegus
Conclusion
Ces modifications résultent finalement en un Scrum Guide beaucoup plus simple à lire et à comprendre. L’ambition affichée des deux fondateurs était bien d’ouvrir le Framework à tous les domaines et équipes au sein d’une organisation – et cette nouvelle version avance clairement dans ce sens.
Cependant, ces modifications laissent plus de place à l’interprétation. En étant moins prescriptif, le guide laisse potentiellement la place à des implémentations plus ou moins cadrées du Framework.
Ce que l’on peut retenir en priorité, c’est l’attachement de plus en plus fort à l’objectif produit, et aux objectifs communs qui servent la valeur ajoutée créée pour l’utilisateur final.
Le Scrum Guide 2020 introduit également la responsabilité du Scrum Master – ou du moins rend cette responsabilité plus visible et explicite. Cette nouvelle notion peut avoir un impact bénéfique au sein des organisations qui craignent parfois la dilution des responsabilités.
Il est maintenant temps de tester ces nouveautés au sein de vos équipes Agile – et de mesurer l’impact opérationnel de ce nouveau Scrum Guide 2020.
N’hésitez pas à nous partager vos avis en commentaires !
Rédigé par Sara del Rio avec l’expertise de Roxane Meyer, Consultantes Acceleration Tactics chez Saegus.