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ù : 

1. Un Product Owner ordonne le travail pour un problème complexe dans le Product Backlog. 
2. La Scrum Team transforme une sélection de travail en un Increment de valeur lors d’un Sprint. 
3. La Scrum Team et ses parties prenantes inspectent les résultats et s’adaptent pour le prochain Sprint. 
4. 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.

On m’a posé il y a quelques semaines la question suivante : comment mesurer le niveau d’agilité d’une équipe Scrum ?

Cette question m’a d’abord laissée perplexe. Il n’existe pas de « méthode officielle » concernant le Scrum qui ait pu être approuvée globalement par la communauté Agile. Mais je me suis vite questionnée sur la possibilité de mesurer correctement ce niveau d’agilité. 

On m’a donné quelques heures pour me renseigner auprès des managers, du Scrum master et de l’équipe dans son ensemble – tous pratiquent déjà l’agilité au quotidien : le «  Daily  » est fait tous les matins, ils maîtrisent l’utilisation de l’outil Jira et d’après mes observations, les User Stories étaient complètes. Néanmoins, je n’avais toujours pas de réponse à ma question  : comment mesurer leur niveau de «  maturité agile »  ?   

Une chose était sûre  : la perfection n’existe pas, ni dans la réalité, ni dans la méthode Agile. Il faut constamment s’améliorer, se motiver pour atteindre l’inaccessible et ce, TOUJOURS en équipe. C’est la seule chose que je suis sûre de pouvoir affirmer de par mes diverses expériences dans le monde de l’IT  : sans travail d’équipe, il n’y a pas de réussite.

En gardant cela à l’esprit, j’ai pu y voir plus clair et je me suis demandée  : quels sont pour moi les quatre piliers de l’Agile  ? Quels sont les quatre fondamentaux de cette nouvelle méthode de travail  ? Pour moi, il s’agit de  :  

• Communiquer  
• Être régulier  
• Documenter la démarche 
• Obtenir et analyser les résultats  

#1 Communiquer

C’est la plus difficile à obtenir ! Il faut que l’équipe soit bienveillante pour que tout le monde puisse communiquer sereinement, sans hésiter à poser des questions, en pouvant partager ses doutes, et en se connaissant un minimum.

Les résultats d’une étude Wisembly/IFOP concernant la communication dans une équipe pendant une réunion sont stupéfiants  :

• 20% des travailleurs pensent que leurs collègues monopolisent le temps de parole
• 17% n’osent pas participer pour éviter les conflits
• 16% ne se sentent pas assez libres de dire ce qu’ils veulent   
• 10% ont le sentiment que leur opinion ne sera pas prise en compte

Ces chiffres ont été publiés avant la pandémie et la mise en place massive du télétravail. Aujourd’hui et avec la généralisation des réunions en ligne, les chiffres sont probablement plus élevés…

Outre les interactions personnelles, peut-on considérer que l’environnement de travail au sens plus large est un facilitateur dans la méthode Agile  ? Nous sommes conscients qu’il est plus que jamais difficile de réunir physiquement l’ensemble d’une équipe. Il est quand même généralement demandé aux collaborateurs d’être présents une ou deux fois par semaine. Pour autant, ces mêmes collaborateurs s’assoient-ils dans les mêmes espaces  ? Leur est-il facile de discuter  ? Les Product Owners sont-ils aussi disponibles  ?

#2 Être régulier

La ponctualité des réunions et leur durée sont des facteurs clés de la réussite de la méthode Agile. Ses deux principaux avantages sont que toutes les réunions sont limitées dans le temps et se déroulent au même moment et au même endroit. Si les règles sont respectées, aucun doute quant à son efficacité pour l’entreprise.

Selon Altassian, 91 % des employés ont déjà rêvassé pendant une réunion, 39 % déclarent même s’être endormis tandis que 45 % d’entre eux se sont déjà sentis dépassés par le nombre de réunions auxquelles ils ont dû assister. Si 73 % ont déjà effectué d’autres tâches pendant une réunion, 47 % des employés se sont plaints que les réunions sont ce qui leur fait perdre le plus de temps au travail.

Pour éviter tout cela, il est important de :

• définir un ordre du jour clair pour chaque réunion
• n’inviter que les collaborateurs essentiels à la bonne tenue de la réunion
• définir clairement l’objectif pour que chacun accepte d’y participer

Nous avons parfois tendance à oublier que les réunions doivent être préparées à l’avance  : «  plus la préparation est difficile, plus l’exécution est simple et à l’inverse, plus la préparation est simple, plus l’exécution est compliquée  » ! Dans la méthode Agile, les réunions sont limitées dans le temps, préparées en avance et l’équipe sait toujours pourquoi elle se doit d’être présente et quel sera l’ordre du jour. Comme ces réunions sont périodiques, elles se répètent lors de chaque sprint permettant ainsi de clarifier l’objectif.

#3 Documenter la démarche

Même si le travail en Agile privilégie les logiciels opérationnels par rapport à des documents physiques, il n’en reste pas moins qu’un dossier complet avec toutes les données nécessaires, les explications, les rapports et les conseils sont plus utiles que vous ne pouvez l’imaginer. Non seulement pour les nouveaux employés mais aussi pour l’équipe dans sa globalité puisque beaucoup de tâches se répètent. Si dans ces dossiers tout est clair, bien expliqué et facilement accessible (il est essentiel que chacun puisse les trouver), ces documents représentent le meilleur moyen pour partager les connaissances acquises par l’ensemble des collaborateurs. Confluence, Teams ou Sharepoint sont de bons outils qui permettent de partager non seulement des documents mais aussi des compte-rendu de réunions, afin de toujours garder à l’esprit les décisions clés prises dans le passé.

Un point fondamental est d’utiliser correctement les outils Agiles qui sont mis à disposition, quel que soit le cadre utilisé par l’équipe (Scrum, Kanban, Safe…) et que toutes les informations y soient réunies.

Une autre erreur courante qu’il faut éviter dans le Scrum est la création d’User Stories incomplètes. Si décrire les tâches prend beaucoup de temps, il faut toujours garder à l’esprit que c’est un réel investissement pour l’avenir. Pour pallier à ce problème, il est bon de proposer des «  Backlog refinement meeting » avant la planification du sprint. Pendant cette réunion, les développeurs et Product Owners ont l’occasion de décrire en détails toutes les tâches à effectuer lors du sprint suivant.

Petit conseil  : si le Scrum master crée des graphiques personnalisés pour montrer la progression du sprint, c’est encore plus motivant ! JIRA, ou peu importe l’outil choisi, doit en plus être mis à jour quotidiennement, par tous les membres de l’équipe.

#4 Obtenir et analyser les résultats

Ainsi, la meilleure façon de mesurer l’Agilité est par les résultats obtenus. C’est le seul point “mesurable” des quatre piliers puisqu’il est le seul qui est quantitatif.  L’équipe a-t-elle terminé le sprint à temps ? Les tests sont-ils validés ? Le temps estimé était-il égal, inférieur ou supérieur au temps réel ? La définition de “done” (DoD) est-elle atteinte ? Selon KMPG, seulement 19% des entreprises livrent des projets réussis – du moins la plupart du temps. En tant que Scrum Master, j’ai vécu la frustration des équipes lorsque personne ne valide le test. Assurez-vous donc de trouver quelqu’un qui sera capable de le faire, même si cette personne fait partie de l’équipe, cela permettra de maintenir la motivation générale !

Pour conclure, je recommande – et ce dans un environnement de travail Agile ou non – de garder à l’esprit ce que j’ai évoqué plus haut  : sans travail d’équipe, il ne peut y avoir de réussite  ! Nous apprenons constamment des autres et tout se construit en équipe.

Enfin, je tiens à préciser que la méthode d’Agile n’est pas faite pour toutes les équipes. De nombreuses entreprises essayent de la mettre en place – en forçant – sans raison valable et simplement parce qu’elle apparaît comme un remède miracle. Ces entreprises tendent à oublier que la méthode Agile est conçue pour être personnalisable. Elle se doit d’être adaptée à chaque équipe, à chaque projet et à la culture de chaque entreprise. Par contre, la méthode Agile est destinée à beaucoup plus de secteurs d’activité que vous ne le pensez  : elle peut avoir de l’impact dans des départements non-IT comme les RH, le marketing, les finances et pour beaucoup d’autres projets…

N’hésitez pas à me faire savoir ce que vous pensez de cet article  ! Et si vous êtes curieux et voulez découvrir la méthode Agile, son organisation ou ses outils, n’hésitez pas à contacter l’équipe Saegus ou moi-même en me rejoignant sur LinkedIn.

Rédigé par Blanca Espinós Ayuela, Consultante Acceleration Tactics chez Saegus.