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.

Jeff Sutherland et Ken Schwaber

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

Lancement de mon blog !

En ligne, enfin !

Cela fait plusieurs années que j’avais ce projet dans les cartons. Après plusieurs expérimentations infructueuses, dont une avec le très intéressant Symphony CMS (ne pas confondre avec le framework PHP Symfony), j’ai fait le choix de la raison : WordPress.

Je parlerai sur ce blog de mon métier (développement et design Web) mais aussi de mes centres d’intérêts, notamment la photographie. J’espère que vous y trouverez des infos intéressantes et utiles et que je pourrai vous compter parmi mes fidèles lecteurs.