Mise à jour de Scrum

Damned, trop tard pour changer mon livre

J’ai appris la mise à jour du guide Scrum de Ken Schwaber et Jeff Sutherland quelques jours après avoir envoyé le bon à tirer pour la deuxième édition de Scrum, le guide pratique etc…

Damned, me suis-je dit, plus moyen de prendre en compte des changements, s’il y en avait d’importants.

J’avais lu la première version du guide lorsque j’écrivais la première édition de mon livre. Lecture rapide, le nombre de pages n’est pas important.

La mise à jour se lit encore plus vite : pour l’instant c’est annoncé sur une page, traduite par Fabrice.

Bon, je suis rassuré, ça ne remet pas en question le contenu de ma deuxième édition. Les changements sont présentés en 6 points. Le principal écart avec ma présentation de Scrum concerne la planification de release. Le chapitre que j’y consacre dans mon livre est classé dans les pratiques de base de Scrum, alors que dans la mise à jour du Scrum Guide, cette pratique n’est plus considérée comme faisant partie de Scrum, elle devient optionnelle.

On devine dans cette évolution comme dans les autres, le désir de contrecarrer l’influence grandissante de Kanban, par une (légère) simplification et un cadre moins strict. En gros, il est maintenant “autorisé officiellement” de :

  • appeler développeurs les membres de l’équipe,
  • gérer des urgences dans un sprint[1],
  • de se passer du burndown chart de sprint[2],
  • de ne plus parler d’éléments du backlog de sprint.

Bref, pas beaucoup de changements, des précisions de vocabulaire et un glissement vers du ScrumBan.

Le dernier point évoqué de la mise à jour concerne le backlog de produit, qui doit être ordonné et non priorisé. Cette “évolution” est expliquée dans un article de Jim Coplien, aussi traduit par Fabrice. En gros, il est déconseillé d’associer un attribut explicite de priorité à un élément du backlog. Bon, ça je le disais déjà dans la première édition de mon livre et c’est comme ça dans iceScrum depuis toujours.

Notes

[1] par exemple avec des tâches urgentes explicites et limitées

[2] une variante est le burnup

Lire aussi