La suite de mes critiques sur le nouveau Guide Scrum

J'ai lu la version française du Guide Scrum, publiée le 18 novembre. Plutôt que garder mon ressenti pour moi, je vous le partage.

La suite de mes critiques sur le nouveau Guide Scrum
Sommaire

La parution d’une nouvelle version du Guide Scrum suscite toujours beaucoup de réactions. C’est le signe d’un intérêt qui ne se dément pas pour Scrum. Pourtant, et bien qu’il soit et reste une référence, c’est mal écrit, mal traduit et sans la moindre illustration. L’effort de simplification de cette nouvelle version est louable, mais de mon point de vue c’est raté.

Malgré tout, je remercie Ken et Jeff de leur don, dont je reprends des extraits ci-dessous (sans en corriger le mauvais français), pour les commenter, comme j’avais fait pour les deux articles précédents. Je dois cela à celles et ceux qui ont lu mes livres sur Scrum et l’agilité et qui pourraient se demander pourquoi ce que j’y présente diffère du Guide Scrum.

Inspiration du Lean Thinking

Sur les origines de Scrum, on voit du changement :

Scrum est fondé sur l’empirisme et le Lean Thinking. L’empirisme affirme que la connaissance vient de l’expérience et de la prise de décisions est basée sur des faits observés. Le Lean Thinking réduit le gaspillage et se focalise sur l’essentiel.

À la lecture je ne suis pas en mesure de dire si le Lean Thinking était une source d’inspiration dès le début de Scrum (1995) ou bien s’il l’est seulement dans cette nouvelle version.

Le problème, c’est que les sources (et c’est vrai aussi pour l’empirisme) ne sont pas citées. On peut supposer que la référence vient du livre Lean Thinking (1996) de Daniel T. Jones et James P. Womack. Cela irait dans le sens que Scrum a été créé en s’en inspirant. Mais pourquoi ne le dire que maintenant ? Parce que cette nouvelle version est réduite et se consacre sur l’essentiel ?

Sprint backlog

Ça fait 10 ans que j’ai arrêté d’employer Sprint Backlog ou backlog de sprint. Dans le guide Scrum, c’est toujours utilisé et avec cette nouvelle version, c’est encore plus bancal.

Voici pourquoi avec ce qui est écrit page 12 :

Le Sprint Backlog est composé de l’Objectif de Sprint (pourquoi), de l’ensemble des éléments du Product Backlog choisis pour le Sprint (quoi), ainsi que d’un plan…

et juste en dessous :

Le Sprint Backlog est un plan…

Faudrait savoir, il est composé d’un plan ou il est un plan ?

Les auteurs ont essayé d’en faire un objet composite mais ils ont bien du mal. De mon point de vue, l’objectif est attaché au sprint, les éléments du backlog choisis pour le sprint sont repris pour élaborer le plan, qui est lui-même associé au sprint.

Je conseille donc d’oublier cette notion bancale de sprint backlog en associant simplement au sprint un Objectif et un Plan. En ajoutant — en premier — boite de Temps, je définis le sprint avec l’acronyme TOP dans L’art de devenir une équipe agile.

Définition de fini

La définition de fini a changé de statut : elle est passée d’artefact à engagement. Ah.

Page 12, il est écrit :

La Definition of Done (Définition de Fini) est une description formelle de l’état de l’Increment lorsqu’il satisfait aux mesures de qualité requises pour le produit.

Si vous avez lu mon article précédent, vous savez qu’incrément et produit c’est la même chose ; donc on aurait pu énoncer plus simplement :

la définition de fini est la description de la qualité requise pour le résultat du sprint.

La phrase suivante, c’est de la poésie :

Dès qu’un élément du Product Backlog satisfait à la Definition of Done, un Increment est né.

La définition de fini est présentée comme un engagement au même titre que les objectifs de produit et de sprint, mais à un autre niveau. Or l’engagement qu’une équipe prend sur un objectif de sprint dépend de la qualité requise, donc de la définition de fini.

Dans le livre Scrum édition 5, je définis l’objectif de sprint comme l’expression du contenu attendu et de la qualité de ce contenu. La phrase qui exprime l’objectif porte sur le contenu et la définition de fini sur la qualité.

De plus, la définition de fini est évoquée de façon à laisser penser à un truc unique, statique et monolithique.

Scrum Master imputable

Certains ont noté cette phrase :

Scrum définit trois responsabilités spécifiques au sein de la Scrum Team : les Developers (développeurs), le Product Owner et le Scrum Master.

Faut-il en conclure que Scrum Master et Product Owner ne seraient plus des rôles ? Je ne crois pas, ce serait une régression sémantique. Ce sont bien des rôles, et comme pour tout rôle, ils ont des responsabilités. D’ailleurs, pour Scrum Master, le mot rôle est bien employé.

À propos du Scrum Master, une autre phrase fait jaser :

Le Scrum Master est responsable de l’efficacité de l’équipe Scrum.

J’ai vérifié sur la version anglaise. C’est pire ! Le mot employé est accountable qui a été traduit par responsable, alors que c’est plutôt imputable.

Je plaide là aussi la maladresse des auteurs. Peut-être confondent-ils autorité instituée et autorité effective (pour reprendre la distinction d’Alain Caillé dans Extensions du domaine du don) ? En affirmant que le Scrum Master est imputable de l’efficacité de l’équipe, ils laissent entendre qu’il aurait le droit de donner des ordres pour arriver à ses fins.

Mais ce serait totalement incohérent avec l’idée d’autogestion de l’équipe, idée pourtant poussée dans cette version par les auteurs ; c’est pourquoi je pense à une étourderie. Le Scrum Master est bien un leader, au sens où il entraîne, mais sans imposer des ordres, même au nom d’une éventuelle efficacité.


En principe, si le rythme de publication ne change pas, on est tranquille pour 3 ans sans nouveau Guide Scrum à déconstruire.

Voir aussi