Mes critiques sur le Guide Scrum 2020

Avec cette nouvelle mouture du Guide Scrum, Ken Schwaber et Jeff Sutherland nous font un cadeau avant les fêtes

Mes critiques sur le Guide Scrum 2020

Ils n’ont pas attendu Noël, ni même Thanksgiving. Le Guide Scrum 2020 a été publié hier, trois ans après la version précédente.

Merci à Ken et Jeff pour ce don. Voici mon contre-don, avec quelques commentaires et critiques (constructives).

Mes retours portent sur la version française publiée en même temps. Je n’ai pas lu la version originale ni assisté à la conférence de lancement.

L’expérience de lecture n’est pas bonne

J’apprécie beaucoup la volonté d’être plus accessible, au-delà du développement de logiciel. La réduction à l’essentiel, en 13 pages, y contribue. Par contre, mon ressenti à la lecture c’est que c’est raté pour la facilité de lecture. La version française est mal écrite (l’art de la traduction est difficile) et le jargon est toujours là.

Les traducteurs ont inséré cette mention à la fin :

Conformément aux directives de Scrum.org, les termes suivants (Scrum, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Scrum Team, Scrum Master, Product Owner, Developer, Product Backlog, Sprint Backlog et Increment) ne doivent pas être traduits dans le document final.

Je désapprouve ce choix : moins de barbarismes franglais, cela aurait été de nature à faciliter l’accès des nouveaux arrivants à l’agilité. En ce qui me concerne, dans mes livres, je le limite à Scrum (ça va de soi), Scrum Master, Product Owner et backlog. Je ne compte pas sprint, qui existe en français. Tout le reste est traduit.

La définition de Scrum revisitée

La définition de Scrum donnée tout au début a été revue. Elle met plus en avant les rôles et notamment celui du Scrum Master.

Dans la version française (non officielle) de 2017, c’était :

Cadre à l’intérieur duquel des personnes peuvent aborder des problèmes évolutifs complexes, tout en livrant d’une manière productive et créative des produits ayant la plus grande valeur possible.

Voici ce qui est proposé dans le guide de 2020 :

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

En restant dans le même esprit, je me suis amusé à la réécrire à ma façon, en cohérence avec les choix que j’ai faits pour mes livres :

Scrum est un cadre léger pour une équipe s’attaquant, avec un objectif, à un problème complexe.

Le Scrum Master encourage l’équipe à suivre ce cadre, basé sur des cycles successifs appelés sprints :

  1. Le Product Owner ordonne les travaux à faire dans le backlog.
  2. Pendant le sprint, l’équipe transforme une sélection de ce backlog en un résultat qui procure de la valeur aux parties prenantes.
  3. L’équipe et ses parties prenantes inspectent le résultat du sprint, afin de s’adapter pour atteindre l’objectif.
  4. On recommence dans le sprint suivant.

Je vous laisse comparer.

Objectif de produit

Un nouveau concept qu’on voit poindre dans la définition (où pourtant le mot produit n’apparait pas), c’est l’objectif de produit.

Dans son tweet, Steeve rapproche cela d’une notion que j’appelle objectif de saison (previously objectif de release) :

L’idée est d’avoir un objectif pour un temps plus long que le sprint.

Je trouve que le choix de rattacher un objectif à une notion non temporelle manque de cohérence, par rapport à l’objectif de sprint (qui est encore consolidé dans ce nouveau guide et c’est bien). C’est la raison pour laquelle j’ai ajouté la saison qui est une série de sprints.

Produit fait l’objet d’explications claires dans le guide. Il y est dit :

Un produit peut être un service, un produit physique ou quelque chose plus abstraite.

Et aussi que l’équipe suit un seul objectif avant de s’attaquer au suivant.

Il est moins clair à quel moment cet objectif de produit est susceptible de changer (produit fini, changement d’objectif ?). L’idée qu’une équipe puisse enchainer plusieurs produits est suggérée, mais pas énoncée.

Mon choix est de considérer qu’une équipe peut développer plusieurs produits (de préférence à la suite), de dire backlog simplement plutôt que Product Backlog (je reviendrai sur le cas du Sprint Backlog) et de définir un objectif selon un rythme défini à l’avance (le rythme des saisons, donc un objectif par saison).

Autogestion

Dans le récapitulatif des nouveautés on trouve aussi :

Les guides Scrum précédents appelaient les équipes de développement auto‐organisées, choisissant qui et comment travailler. En se focalisant davantage 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.

Intéressant. Si on lit bien, la différence entre autogérée et auto-organisée porte sur le sur quoi. Le sur quoi travailler, cela concerne l’ordre dans le backlog, qui respecte de la responsabilité du Product Owner. Celui-ci étant dans l’équipe, je ne vois pas trop le changement dans la pratique.

Peut-être pour prévenir des situations de faux-agile où le travail à faire est imposé de l’extérieur de l’équipe ?

Sur le vocabulaire (autogestion, auto-organisation, auto-gouvernance), je m’étais posé la question pour l’édition 5 de mon livre Scrum, avec Ken, Steeve et les autres.

Sur le niveau d’auto-organisation de l’équipe, on trouvera une page dédiée dans L’art de devenir une équipe agile. C’est la page 38, A comme Auto-organisation : le sur quoi et le comment du guide Scrum y sont traités, en particulier pour une équipe qui démarre.

Je n’ai pas fini mon contre-don. Il devrait y avoir un deuxième article sur ce nouveau guide Scrum.

Voir aussi