Scrum guide 2020 : mon décryptage des changements

L’année 2020 aura été une année très spéciale à de nombreux titres. Ken Schwaber et Jeff Sutherland nous gratifient d’une nouvelle version du Scrum Guide. Décryptage des changements.

Encore moins normatif

Au fil du temps, le Guide Scrum a commencé à devenir un peu plus normatif. La version 2020 visait à ramener Scrum à un cadre minimalement suffisant en supprimant ou en adoucissant le langage prescriptif. Par exemple, la suppression des questions Daily Scrum, l’adoucissement du langage autour des attributs PBI (Product Backlog Items – les éléments du Backlog Produit), l’adoucissement du langage autour des éléments rétro dans un Sprint Backlog, le raccourcissement de la section d’annulation de Sprint, etc.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Le Scrum guide 2020 réajuste le tir. Scrum est bien un cadre de fonctionnement et pas une méthodologie. A l’intérieure de ce cadre, les pratiques sont libres. La suppression des trois questions du Daily Scrum en est un bon exemple. Peu importe comment l’équipe le mène, c’est son objectif et sa timebox qui comptent : inspecter et adapter le plan en vue de l’objectif du sprint.

Une seule équipe, focalisée sur un seul produit

L’objectif était d’éliminer le concept d’une équipe distincte au sein d’une équipe qui a conduit à un comportement « proxy » ou « nous et eux » entre le PO et l’équipe de développement. Il n’y a maintenant qu’une seule équipe Scrum concentrée sur le même objectif, avec trois différents ensembles de responsabilités : PO, SM et développeurs.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Là-aussi, on revient à l’essence même de Scrum. C’est carrément littéral. « Scrum » en anglais, c’est la mêlée. Un pack qui pousse comme un seul groupe. Donc tout le monde, PO, Scrum master et développeurs sont désormais dans une seule et même équipe.

Introduction de l’Objectif de Produit

Le Guide Scrum 2020 introduit le concept de l’Objectif de Produit pour permettre à la Scrum Team de se focaliser sur un objectif plus important. Chaque Sprint devrait rapprocher le produit de son objectif global.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Ça aussi c’est bien vu. En plus, c’est très facile à mettre en place. Chaque sprint est un sous-ensemble de travail visant à atteindre un objectif plus grand. Définir l’objectif du produit va renforcer et partager la vision produit qui manque parfois cruellement, surtout pour les développeurs.

Un sens pour l’Objectif de Sprint, la Definition of Done et l’Objectif de Produit

Les précédents guides Scrum décrivaient l’Objectif de Sprint et la Definition of Done sans vraiment les donner une identité. Ils n’étaient pas tout à fait des artefacts, mais étaient quelque peu attachés à des artefacts. Avec l’ajout du concept de l’Objectif de Produit, la version 2020 apporte plus de clarté à ce sujet. Chacun des trois artefacts contient désormais des «engagements» à leur égard. Pour le Product Backlog, il s’agit de l’Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l’Increment a une Definition of Done (maintenant sans les guillemets). Ils existent pour apporter de la transparence et se focaliser sur la progression de chaque artefact.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

C’est la suite logique du point précédent sur l’introduction de l’objectif de produit. Le Scrum guide 2020 réaffecte ces 3 notions (objectif de produit, objectif de sprint et definition of done) a trois artefacts de Scrum :

product backlog => objectif de produit
sprint backlog => objectif de sprint
incrément => definition of done

Personnellement, j’aime bien l’idée d’une definition of done associée directement à l’incrément plutôt qu’à chaque user story. Claude Aubry en parlait déjà dans son livre « Scrum » dès la 4è édition en 2015. Je trouve qu’une definition of done trop contraignante sur les stories allonge les temps de développement et j’ai souvent du mal à la faire respecter par les équipes. Alors qu’une definition of done sur l’incrément peut être inspectée en sprint review et permettra de déterminer les dernières actions à mener pour éventuellement sortir une release.

Auto-gérée plutôt qu’auto‐organisée

Les guides Scrum précédents appelaient les équipes de développement auto‐organisées, choisissant qui et comment travailler. En se focalisant d’avantage sur la Scrum Team, la version 2020 met l’accent sur une Scrum Team autogérée, en choisissant qui, comment et sur quoi travailler.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Auparavant, la Dev team s’auto-organisait pour définir qui allait réaliser le travail et comment il serait réalisé. Et c’était plutôt la Scrum team, sous l’impulsion du PO, qui définissait sur quoi la dev team allait travailler. Désormais, la seule et unique Scrum team décide quoi, qui et comment.

Simplification globale de la langue pour un public plus large

Le Guide Scrum 2020 a mis l’accent sur l’élimination des déclarations redondantes et complexes ainsi que la suppression de toute déduction éventuelle au travail informatique (par exemple, les tests, le système, la conception, les exigences, etc.). Le Guide Scrum compte désormais moins de 13 pages.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Encore une bonne chose. Scrum est très largement utilisé dans le monde informatique mais il n’a pas été créé en ce sens. On peut appliquer Scrum à n’importe quel secteur d’activité. Il était donc important de nettoyer le Scrum Guide de toutes notions connotées « informatique ».

Rôle du Scrum master

J’ai lu et entendu quelques analyses qui disaient que le Scrum Guide 2020 modifie le rôle du Scrum Master. Je ne suis pas tout à fait d’accord. La traduction française ne l’évoque pas d’ailleurs (liste des changements 2018-2020 en page 15 de la version française).

2017

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

2020

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

C’est le terme « accountable » (responsable qui rend des comptes) qui semble faire peur à certains. Personnellement, en tant que Scrum Master, je me suis toujours senti investi de cette responsabilité. Aujourd’hui, le Scrum guide 2020 a peut-être introduit ce changement pour rendre cette responsabilité visible et explicite. Et je pense que c’est une bonne chose pour la pénétration de Scrum dans certaines organisations où l’on craint la dilution des responsabilités.

Sources et références

https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Scrum et le « lâcher prise »

Lorsqu’on devient Scrum master et qu’on a, comme moi, un background technique de chef de projet classique, il est nécessaire de changer de « mindset » pour devenir réellement agile.

Le chef de projet : une contrainte dans le système

La gestion de projet classique positionne une personne en tête de file : le chef de projet.

Cette personne est l’unique point d’entrée pour les parties prenantes (les managers, les clients, l’équipe de développement). Il sait tout, il voit tout, il a réponse à tout, il peut tout, il doit tout (vous pouvez compléter la liste…). Il paraît alors assez évident que ce rôle pose problème :

qu’est-ce qui se passe si cette personne quitte l’organisation ? (départ, maladie, accident, mutation…)
qu’est-ce qui se passe pour le produit si cette personne est (ou devient) insuffisamment performante (fonctionnellement, techniquement, manque de dispo…) ?
qu’est-ce qui se passe si les relations avec les parties prenantes se dégradent ?

Là-aussi, on peut facilement compléter la liste.

Il est donc dangereux pour un projet ou un produit d’être confié à une seule personne. Les managers qui gèrent le staffing des équipes doivent veiller à ce que ça n’arrive pas. C’est de leur responsabilité.

Mon expérience personnelle m’a aussi fait entrevoir un autre problème avec le chef de projet. Il est un goulot d’étranglement qui ralentit les travaux et limite les solutions. Une demande métier ne doit pas être bloquée chez le chef de projet. Elle doit arriver directement à l’équipe qui connaît bien le produit, qui a les compétences techniques et la richesse créative pour imaginer une solution pertinente. Pour que ce soit efficace, l’équipe doit évoluer dans un cadre propice à la prise en charge rapide des demandes et à l’émergence de solutions concertées.

Scrum et Kanban offrent un tel cadre.

Confier les clés à l’équipe

Lâcher prise, c’est donner les clés à l’équipe Scrum.

Ses membres doivent « faire ». Ils doivent se confronter aux problématiques afin qu’il en résulte une émulation, une intelligence collective et un enrichissement des solutions proposées.

Scrum est un cadre prévu pour traiter des problématiques complexes. Les membres de l’équipe de développement sont des techniciens compétents, motivés et pluridisciplinaires qui vont embrasser cette complexité pour enrichir le produit. Si une personne fait des choix en amont pour réduire cette complexité, il court-circuite en quelque-sorte les bénéfices de Scrum. Pour éviter cet écueil, il suffit de respecter Scrum ! C’est le Product Owner qui transmet directement ses demandes à l’équipe sans intermédiaire à travers le backlog.

Le manque de confiance

Le principal frein à la mise en place de Scrum et à son succès est le manque de confiance.

On lâche prise lorsqu’on accepte le niveau de productivité et de qualité actuel de son équipe. Il est inutile de décréter unilatéralement un haut niveau de performances. L’équipe doit faire son cheminement pour progresser. L’amélioration doit être continue et recherchée en permanence. L’exigence de transparence prônée par Scrum permet cette inspection. Au final, avec la pratique et la répétition, l’équipe va améliorer ses capacités au fil du temps.

C’est aussi ce manque de confiance qui amène les managers à migrer leurs organisations vers du faux Scrum. Le symptôme le plus courant étant la conservation du rôle de chef de projet, souvent renommé et déguisé en Scrum Master.

Lâcher prise, c’est donc faire confiance !

Scrum : de l’usure des rituels

Le cadre Scrum est jalonné de rituels indispensables au bon fonctionnement d’une équipe. Le Scrum Master est responsable de leur bonne tenue mais aussi de leur efficacité. D’expérience, on remarque que lorsque l’équipe itère depuis plusieurs mois, l’efficacité des rituels diminue.

Le daily meeting

Quotidien, il est le plus fréquent des rituels Scrum. Il est aussi le plus normé car il doit être rapide (max 15min) et toujours se dérouler à la même heure et au même endroit pour réduire la complexité et faciliter sa tenue. Son importance est capitale et son efficacité doit être réelle.

Le Scrum master doit donc veiller à ce qu’il conserve son utilité en évitant les mauvaises habitudes des participants :

ponctualité
Le matin c’est bien ! C’est le top départ de la journée Scrum. Les participants doivent impérativement être à l’heure. Le Scrum master doit rappeler à l’ordre les retardataires.
écoute
Ce doit être un vrai moment d’échange. Il doit y avoir un dialogue réel entre les membres de l’équipe. J’ai remarqué que la proximité physique (attention Covid-19…) joue énormément sur les discussions. En obligeant les participants à se rapprocher physiquement, à resserrer le cercle, on améliore le dialogue.
implication et transparence
L’équipe doit faire preuve de transparence afin que l’inspection réalisée soit efficace. Pour cela, les participants ne doivent rien dissimuler. Le management visuel est d’une redoutable efficacité car il montre à tout le monde et à un seul et unique endroit l’état d’avancement des tâches de chacun. Le bâton de parole marche aussi plutôt bien pour impliquer chaque participant et leur attribuer un créneau de parole.
On doit aussi demander à chaque participant d’intervenir lui-même sur le management visuel pour déplacer ses tâches ou s’en attribuer une nouvelle. Cela l’impliquera d’avantage.
timebox
15 minutes max ! La timebox oblige les participants à aller à l’essentiel et surtout à envisager un autre cadre (réunion, discussion, pair-programming…) pour la résolution de leurs problèmes.

J’adapte aussi parfois sa fréquence. Ce n’est pas tout à fait conforme à la théorie Scrum et cela réduit les opportunités d’inspection et d’adaptation. Mais, lorsque les stories sont encore un peu grosses et que l’avancement du travail n’est pas significatif d’un jour à l’autre, la réduction de la fréquence permet d’éviter les meetings « creux ». C’est nécessaire lorsque les participants disent : « pour moi, comme hier… ».

L’erreur la plus courante du Scrum master est de prendre le lead pendant les daily meetings. Cela empêche les participants de s’impliquer et d’échanger. Il faut rester en retrait et laisser l’équipe mener le meeting. Ce n’est pas une séance de rapport au Scrum Master ou au Product Owner (perso, je trouve bien qu’il soit présent), c’est un rituel qui doit permettre à l’équipe d’inspecter son avancement et d’adapter son plan vers l’objectif du sprint.

Sprint-review et sprint-planning

Ces deux rituels sont très normés. On inspecte le résultat du sprint, on fait une démo de ce qui est terminé et on envisage la suite pour le prochain sprint.

En review, pour éviter la routine, il faut faire tourner les personnes qui réalisent la démo. Cela permet d’impliquer tout le monde.

Pendant le sprint-planning, le Product Owner doit expliquer à l’équipe les stories qu’il a retenues pour le nouveau sprint. Là encore, le Scrum Master doit laisser le lead pour obtenir une implication de l’équipe. J’aime bien aussi donner la parole, sur chaque story, au membre de l’équipe qui connaît le périmètre technique impliqué. C’est une sorte d’essaimage (cf. « Scrum, Claude Aubry, Editions Dunod ») qui permet l’engagement de chacun.

Le sprint-planning est fastidieux et le plus long des rituels Scrum. Il est exigeant mentalement, demande beaucoup de concentration et de réflexion. Je crois que le plus important pendant ce rituel est de faire des pauses. Son importance est capitale pour la réussite du futur sprint, tout le monde doit donc être totalement concentré.

La rétrospective

C’est certainement le rituel qui nécessite le plus de variété. Il est nécessaire de changer fréquemment le support et la formule pour obtenir des retours francs et transparents des membres de l’équipe. Sans cette transparence, l’inspection ne sera pas bonne.
On doit chercher à libérer la parole. Sans langue de bois, les membres de l’équipe doivent se dire les choses. Le Scrum Master veillera à ce que les conditions soient réunies pour que cela se fasse dans une atmosphère bienveillante. Le bon point de départ est de se dire que tout le monde a fait de son mieux pendant le sprint écoulé.

D’expérience, j’ai l’habitude de faire en sorte que les retours ne soient jamais nominatifs afin que personne ne soit ciblé. Ma règle : on ne cite aucun nom en rétro !

Pas mal de gens ont expérimenté de nombreuses formules de rétrospective. Une sélection ici https://pablopernot.fr/2015/03/festival-de-retrospectives/ .

Si on veut creuser un peu plus du côté émotionnel, je vous conseille la rétro Dixit : https://blog.myagilepartner.fr/index.php/2019/11/08/retrospective-dixit/ . Elle favorise l’empathie et oriente les retours sur un support annexe au projet et au travail quotidien (les illustrations Dixit).

Scrum : pourquoi utiliser les points ?

Dans la méthodologie Scrum, il est de coutume d’estimer la charge de réalisation des tâches avec d’autres unités que le temps, notamment les points.

Le temps passe…

Pendant un sprint de 3 semaines (15 jours ouvrés), chaque membre de l’équipe travaillera 15 jours. Le temps ne fait que passer, il est incompressible et inextensible. Mesurer en temps n’est donc d’aucune utilité car si on prend cette mesure à la fin du sprint, on trouvera à nouveau 15 jours comme prévu au départ.

En plus, si on mesure le réalisé du sprint, on va se retrouver avec des choses incohérentes. Par exemple, si l’équipe a bien fonctionné, elle aura pu réaliser une tâche estimée à 20 jours en 15 jours de travail. A-t-elle ralenti le temps ?

Le temps n’est donc pas un indicateur de la performance de l’équipe Scrum.

L’abstraction

Estimer en temps paraît plus naturel pour tout le monde. Mais les membres de l’équipe n’ont pas tous la même expérience et les mêmes capacités donc pas la même productivité. Une unité abstraite va donc apporter un relativisme propre à l’équipe et, de fait, plus juste. Chaque équipe Scrum a son propre barème d’estimation qui découle directement de ses membres, de leur mentalité et de leur expérience commune. C’est un argument en faveur de la stabilité de l’équipe.

Sans m’étendre sur les techniques d’estimation, les abstractions utilisées habituellement dans Scrum offrent un autre avantage. Leurs échelles ne sont pas linéaires et permettent d’éviter les débats stériles sur une unité (ex. 2j, 2,5j ou 3j). La suite de Fibonacci est l’abstraction la plus connue. En général, j’utilise cet échantillon avec mes équipes : 0 – 1/2 – 1 – 3 – 5 – 8 – 13 – 20

La mesure

En fin de sprint, on additionne les points des stories terminées par l’équipe pour mesurer sa performance : c’est la vélocité.

Dans la théorie, cela paraît très simple. Dans la pratique, c’est un peu plus complexe surtout si votre workflow a été enrichi et comporte des états intermédiaires autres que TODO, IN PROGRESS et DONE. C’est là que le DOD prend toute son importance.

On remarque aussi des variations dans la vélocité en fonction du type de tâches réalisées d’un sprint à l’autre. De petites tâches simples en grand nombre, faciles à terminer, auront tendance à gonfler la vélocité. A l’inverse, des tâches plus complexes, difficiles à terminer, auront tendance à la faire chuter. Le niveau d’avancement des tâches joue aussi beaucoup sur ces variations. Durant un sprint, si l’équipe a avancé beaucoup de tâches mais terminé peu, sa vélocité sera faible. Dans le sprint suivant, si les tâches commencées sont poursuivies et terminées, la vélocité gonflera grâce au travail réalisé pendant le sprint précédent.

A cause de ces variations, la vélocité ne reflète pas toujours le vrai niveau de performance de l’équipe. Ainsi, j’ai pris l’habitude de relever d’autres indicateurs à mes équipes :

« nombre de stories et total de story-points » embarqué au début du sprint (l’engagement)
« nombre de stories et total de story-points » non-commencé laissé en TODO
« nombre de stories et total de story-points » quasi-terminé (en test par exemple)

Cela permet de détailler le résultat du sprint et de relativiser la vélocité.

Relativiser les estimations

L’estimation de tâches est un exercice difficile et très incertain. Le mouvement « NoEstimate » le considère d’ailleurs comme un gaspillage de temps. De mon expérience, le travail d’estimation des tâches, réalisé lors du sprint-planning, a deux intérêts (dans l’ordre d’utilité) :

permettre à l’équipe d’étudier les tâches, d’élaborer un plan pour les réaliser et d’obtenir un consensus sur ce plan
améliorer la prédictibilité en se basant sur la performance connue de l’équipe mesurée par sa vélocité

A mon sens, la définition du plan et l’obtention du consensus de l’équipe sur ce plan justifient à eux-seuls le temps passé en estimations malgré leur faible fiabilité.

Agile : comment bien terminer les sprints ?

L’un des grands concepts des méthodes Agile est le découpage d’un gros travail en petits lots. En Scrum, on parle de sprints, en français, des itérations. Ce mode de fonctionnement présente de nombreux avantages mais demande une grande rigueur.

Terminer les stories !

Un sprint délimite un cadre dans lequel l’équipe va s’engager sur la réalisation d’un périmètre fonctionnel défini par le product owner. Ce périmètre est délimité en fonction de la capacité de production de l’équipe de développement afin que l’objectif de l’itération soit atteignable. Il est donc primordial de figer ce périmètre lorsque le sprint à commencé !

Mais ce n’est pas chose simple. Si les livraisons et la recette se font en continu, vous verrez les testeurs et le métier vous renvoyer vos stories. On peut alors très vite perdre le contrôle et passer beaucoup plus de temps sur une story que prévu initialement. Il en va de la réussite du sprint et de l’appréciation de la qualité du travail réalisé.

J’ai pris l’habitude de demander au product owner de saisir de nouveaux tickets pour ses remarques et retours sur une story livrée. On peut alors réintroduire ces demandes dans le backlog et les traiter comme les autres stories en les priorisant et en les embarquant dans un futur sprint. A l’inverse, si les retours sont faits sur la story initiale, vous aurez beaucoup de mal à la terminer et vous avez de grandes chances de la retrouver dans le prochain sprint alors que la demande initiale a été traitée. Cela fausse tous les indicateurs. La vélocité en prend un coup et l’équipe se décourage sur ces stories qui reviennent comme des boomerangs.

Pour réussir à terminer les stories, il faut définir ce qu’on entend par « terminé ». Et Scrum a des outils pour ça : le DOD et les critères d’acceptation.

Definition Of Done (DOD)

Ce concept Agile est méconnu et trop souvent inutilisé. Il prend généralement la forme d’une checklist. Exemple :

toutes les sous-tâches de la story sont réalisées
le développeur a mené des tests sur son environnement de travail
le nouveau code ne génère pas d’erreurs ou de warnings dans les logs
le code a passé les tests de qualité
le code a passé les tests unitaires
le code a été mergé sur la branche de développement
le code a été livré sur l’environnement de recette
…

Il parle plus à l’équipe de développement qu’au product owner. Il faut évidemment l’adapter au contexte du projet. Le DOD peut être global, c’est à dire valable pour chaque story. On peut aussi le redéfinir pour l’adapter à une story.

Les critères d’acceptation

Les critères d’acceptation d’une story sont fonctionnels et exprimés par le product owner. Ils servent à formaliser dans quelles conditions il estimera que la fonctionnalité livrée correspond à la fonctionnalité demandée. Par exemple, pour une notation « 5 étoiles » :

Sur un article pas encore noté, je vois le message « Soyez le premier à évaluer cet article ».
Sur un article déjà noté, je vois la note moyenne attribuée à l’article, arrondie à la décimale 0.5.
Sur un article que je n’ai pas encore noté, je peux attribuer à l’article une note de 1 à 5.
Sur un article que j’ai déjà noté, je ne peux pas attribuer une note.
…

On peut aussi définir des critères d’acceptation plus techniques, notamment par rapport aux performances :

La fonctionnalité de notation « 5 étoiles » ne doit pas augmenter le temps de chargement de la page de plus de 3%.

Il est possible de travailler d’avantage sur la formalisation des critères d’acceptation afin d’en faire des tests automatisés grâce à des solutions comme Behat.

Et les tickets de retours ? On en fait quoi ?

Il est naturellement difficile de satisfaire tous les critères d’acceptation dès la première livraison. Donc le product owner va créer des tickets pour vous transmettre ses retours sur les fonctionnalités livrées. Vous allez retrouver ces demandes dans le backlog où elles doivent être traitées comme les stories initiales : priorisées, estimées et embarquées (ou pas) dans les futurs sprints.

Si vous utilisez Jira, vous avez la possibilité de créer des sous-tâches de la story pour formaliser les retours. C’est cohérent et pratique mais cela présente une contrainte : vous ne pouvez pas terminer la story tant que toutes ses sous-tâches ne sont pas terminées. Et comme on essaie de terminer les stories pour maîtriser nos sprints, c’est contre-productif…

Si ces tickets de recette sont en trop grand nombre et qu’il est trop fastidieux de les estimer, on peut réserver un « effort » à leur consacrer pendant les futurs sprints. C’est une bonne façon d’améliorer en continu la qualité du produit. On peut aussi ajouter un sprint final de recette pendant lequel on ne réalisera rien de nouveau et qu’on consacrera uniquement au traitement des retours du métier.

Terminer les sprints !

Avec un peu de rigueur et beaucoup de communication, vous parviendrez à terminer la réalisation des stories et donc à clôturer vos sprints. C’est bon pour votre équipe qui voit le projet avancer et pour le product owner qui voit son application s’enrichir. Vous aurez alors des indicateurs fiables et vous pourrez réellement mesurer la vélocité.