Scrum, popularisé dans les années 2010, connaît un engouement certain dans le monde de l’informatique. C’est pourquoi Ken Schwaber et Jeff Sutherland ont écrit le « Guide Scrum ». En Novembre 2020, ils ont mis à jour leur guide pour y apporter des éclaircissements sur certains points et d’étendre le « framework » à d’autres métiers que celui de l’informatique.
Qu’est ce qui change dans ce nouveau Guide ?
Simplification globale du langage pour un public plus large
Là où la version de 2017 faisait 18 pages, ici la version de 2020 n’en fait plus que 13. En effet, les termes complexes, et redondants ont été révisés ainsi que les allusions informatiques (tests, conceptions…) ont été supprimées pour toucher tous les métiers qui ont des problématiques complexes.
Le guide est plus simple, facile à comprendre. Il revient à un cadre minimal suffisant. Par exemple, les 3 questions quotidiennes du Daily Scrum ont été supprimées pour apporter plus de flexibilité sur l’ajustement du plan d’action.
Une seule équipe, un seul produit
Afin de ne pas enclaver d’équipe dans l’équipe, le Guide Scrum ne reconnait plus qu’elle seule équipe : l’Équipe Scrum. L’objectif est de responsabiliser l’équipe entière et d’éviter les effets de bords « nous et eux » entre le Scrum Master, le Product Owner et les Développeurs.
L’équipe Scrum est concentrée sur un même objectif produit, dont les rôles sont partagés entre le Product Owner, le Scrum Master et les Développeurs.
Introduction de l’Objectif Produit
L’objectif Produit, présent dans le Product Backlog, va permettre à l’équipe de se focaliser sur sa réalisation tout au long des différents sprints. Il est un vecteur de valeur avec une limite claire. Chaque Sprint doit tendre vers cet objectif.
L’Objectif de Sprint, la Définition de Fini et l’Objectif Produit retrouvent du sens
L’Objectif de Sprint, la Définition de Fini et L’Objectif Produit n’avaient pas d’identités propres dans le précédent Guide. Ils ne faisaient pas vraiment parti des artéfacts Scrum.
Cette nouvelle version, vient éclaircir leurs rôles. Pour chaque artéfact Scrum, un « engagement » y est ajouté :
● Pour le Product Backlog, on y associe l’Objectif Produit : qui décrit un état futur du produit, qui sert de cible à l’Équipe Scrum pour planifier ;
● Pour le Sprint Backlog, on y associe l’Objectif de Sprint : qui est le but unique du Sprint, son utilité. Il créé ainsi, de la cohérence et du focus, ce sur quoi l’Équipe Scrum doit travailler ensemble ;
● Pour l’Incrément, on y associe la Définition de Fini : qui est une description formelle de l’état d’un élément du Product Backlog. Il permet la transparence et la compréhension de chacun sur ce qu’est un incrément livrable.
Ces « engagements » permettent d’apporter plus de transparence et de se concentrer sur l’avancement de chaque artéfact.
Une équipe autogérée, plutôt qu’auto-organisée
On parlait d’auto-organisation pour l’équipe de développement ce qui leur permettait de choisir avec qui et comment travailler. Ici, avec la notion d’Équipe Scrum et l’introduction de l’Objectif Produit, on parle d’autogestion c’est-à-dire que l’Equipe Scrum est focalisée sur un objectif à atteindre et décide du : « qui fait quoi, quand et comment »
Trois thèmes pour le Sprint Planning
Dans les anciens Guide Scrum, lors du Sprint Planning, on parlait seulement des sujets « Quoi » et « Comment » réaliser un élément du Product Backlog. Ici, on y ajoute « Pourquoi » qui fait référence à l’Objectif de Sprint. L’ensemble de L’Équipe Scrum collabore à le définir.
