Scrum Guide 2020

25 ans… Scrum a cette année 25 ans. Et pour fêter ce quart de siècle, les deux créateurs de Scrum, Jeff Sutherland et Ken Schwaber, viennent de mettre à disposition de la communauté une nouvelle version du Scrum Guide.

Créé en 2010, le Scrum Guide est considéré comme la définition officielle de Scrum. Depuis, de nouvelles versions sortent régulièrement, apportant des modifications plus ou moins importantes.

La version de 2020 peut être qualifiée de version majeure. Elle apporte d’importants changements qui modifient en profondeur la description du framework.

Nous pourrions discuter longtemps de la façon dont le Scrum Guide est mis à jour, du manque d’implication de la communauté, de l’aspect « secret » des modifications… je me contenterai dans cet article de vous détailler les nouveautés. Mais je peux déjà vous dire que ce nouveau Scrum Guide va beaucoup faire parler dans la communauté 🙂

Pour ceux qui n’ont pas le courage de lire la totalité de l’article, voilà les principales nouveautés de cette nouvelle version :

• Une version beaucoup moins prescriptive et beaucoup plus légère
• Suppression du rôle Équipe de développement au profit de la responsabilité Développeurs (il ne reste plus qu’une seule équipe, la Scrum Team)
• Suppression de la notion de rôle remplacée par la notion de responsabilité
• Remplacement du terme self-organizing par self-managing
• Remplacement de « Servant Leader » par « True Leader »
• Ajout d’un troisième sujet pour le Sprint Planning : le Pourquoi
• Suppression des trois questions du Daily Scrum
• Introduction de l’Objectif Produit (Product Goal)
• Ajout de la notion d’engagement sur les artefacts.

Pour ceux qui ont un peu plus de courage, voilà en détail les principaux changements (en rouge ce qui a été supprimé, en vert ce qui a été ajouté) :

Un Scrum Guide beaucoup moins prescriptif

La première chose qui saute aux yeux à la lecture du nouveau Scrum Guide, c’est sa taille. Le Scrum Guide a subi une grosse cure d’amincissement. La version 2017 comportait 19 pages, la nouvelle version se compose de seulement 13 pages.

Alors que les précédentes versions se contentaient d’apporter quelques nouveaux éléments et reformulations, le Scrum Guide a cette fois-ci été entièrement réécrit.

Au fil du temps et des nouvelles versions, il avait tendance à devenir parfois plus (trop ?) prescriptif. Les auteurs ont choisi cette fois-ci de revenir aux basiques en simplifiant et allégeant drastiquement son contenu.

Le ton est donné dès le début :

Scrum is:

•Simple to understand

•Difficult to master

Scrum Guide 2017

Scrum is simple.

Scrum Guide 2020

Plus d’excuses pour ne plus implémenter Scrum ! 🙂

A noter l’apparition pour la première fois de Lean dans le Scrum Guide :

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.

Scrum Guide 2020

Disparition de l’Équipe de Développement

C’est certainement la modification la plus importante apportée par ce nouveau Scrum Guide et celle qui va, je pense, générer le plus de débats dans les jours qui viennent. L’Équipe de Développement disparait et est remplacée par la notion de Développeurs. La nouvelle version élimine le concept d’une équipe séparée au sein de la Scrum Team.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Guide 2020

Il n’y a maintenant qu’une seule équipe Scrum, focalisée sur un seul objectif.

Cette modification est plus qu’une simple modification de « wording ». En plus de supprimer la confusion qui pouvait exister entre les deux notions d’équipes (Scrum Team et Dev Team), le nouveau Scrum Guide cherche à accentuer le sentiment d’appartenance à une même équipe. Maintenant tout le monde est dans le même bateau. Finie la séparation entre l’Équipe de Développement et le Product Owner.

Comme il n’y a plus d’Équipe de Développement, la taille conseillée est maintenant celle de la Scrum Team. On passe donc de « de 3 à 9 membres » à « moins de 10 personnes ».

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.

Scrum Guide 2020

Disparition de la notion de rôle

La notion de rôle disparait également. Il n’y a plus 3 rôles, mais trois responsabilités (« accountabilities ») : Product Owner, Scrum Master et Développeurs.

Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Scrum Guide 2020

Self-organizing vs Self-managing

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Scrum Guide 2017

They are also self-managing, meaning they internally decide who does what, when, and how.

Scrum Guide 2020

Jusqu’à présent, l’Équipe de Développement était auto-organisée. Dans le Scrum Guide 2020, la Scrum Team est maintenant self-managed (auto-gérée).

Je suis curieux de voir comment Jeff & Ken expliquent ce changement et définissent ces termes… Font-ils référence à la définition donnée par Hackman dans son livre Leading Teams ? Ce changement est-il là pour donner une définition plus claire (la notion d’auto-organisation n’étant pas vraiment définie dans la littérature) ?

L’Équipe de Développement avait jusqu’à présent le pouvoir de décider de l’organisation de son travail (le Comment). Avec l’incorporation du Product Owner dans l’équipe, la Scrum Team possède aussi le pouvoir de décider ce sur quoi elle va travailler (le Quoi).

Les autres caractéristiques de l’Équipe de Développement (pluridisciplinaire, pas de titre (pas de hiérarchie dans le nouveau guide), pas de sous-équipe) sont transférées au niveau de la Scrum Team.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

Scrum Guide 2020

Le Scrum Guide décrit maintenant clairement les activités et responsabilités de la Scrum Team : collaboration avec les parties prenantes, vérification, maintenance, exploitation, expérimentation, recherche et développement et tout ce qui pourrait être requis.

J’aime beaucoup cet ajout qui permet de clarifier le périmètre de l’équipe et de montrer qu’il ne se limite pas seulement à la partie codage ; ce qui permettra peut-être d’éviter les anti-patterns classiques d’équipes de test ou d’ops séparées…

Le Scrum Master au cœur du framework… devient un “True Leader”

Le rôle de Scrum Master est plus que jamais au centre de Scrum puisqu’il apparait dès les premières lignes du Scrum Guide comme une responsabilité indispensable :

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4.Repeat

Scrum Guide 2020

Peut-être un bon moyen de souligner que ce rôle est essentiel au bon fonctionnement de Scrum et d’aider à éviter les trop nombreuses implémentations de Scrum sans Scrum Master…

La description de ses responsabilités change :

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide

Scrum Guide 2017

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.

Scrum Guide 2020

Elles passent de « promouvoir et supporter Scrum » à « instaurer Scrum ».

The Scrum Master is accountable for the Scrum Team’s effectiveness.

Scrum Guide 2020

Certainement l’une des phrases qui va faire le plus parler : “Le Scrum Master est responsable de l’effacité de l’équipe Scrum.”

Je pense que la bonne façon de lire cette phrase, c’est de le voir comme responsable de l’amélioration continue de l’équipe et de la mise en place d’un environnement qui permet à l’équipe d’être efficace. Mais cette modification ouvre la porte au retour du Scrum Master vu comme le “chef de l’équipe” responsable de sa productivité 🙁

Le terme « Servant Leader » disparait au profit du terme « True Leader » :

The Scrum Master is a servant-leader for the Scrum Team.

Scrum Guide 2017

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

Scrum Guide 2020

Curieux de voir comment Jeff et Ken vont justifier ce changement…

Scrum Master au service de l’Équipe de Développement

La partie Scrum Master au service de l’Équipe de Développement est logiquement transformée en Scrum Master au service de la Scrum Team.

A noter un petit changement que j’attendais et qui clarifie le fait que la responsabilité du Scrum Master n’est pas de lever les obstacles mais de s’assurer que les obstacles sont levés :

Removing impediments to the Development Team’s progress

Scrum Guide 2017

Causing the removal of impediments to the Scrum Team’s progress

Scrum Guide 2020

Scrum Master au service du Product Owner

La partie Scrum Master au service du Product Owner a été allégée :

Suppression de :

Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible

Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;Understanding and practicing agility

Ajout de :

Facilitating stakeholder collaboration as requested or needed

Scrum Master au service de l’organisation

La partie Scrum Master au service de l’organisation subit quelques modifications :

Leading and coaching the organization in its Scrum adoption

Leading, training, and coaching the organization in its Scrum adoption

Planning Scrum implementations within the organization

Planning and advising Scrum implementations within the organization

Helping employees and stakeholders understand and enact Scrum and empirical product development

Helping employees and stakeholders understand and enact an empirical approach for complex work

Suppression de :

Causing change that increases the productivity of the Scrum Team

Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Ajout de :

Removing barriers between stakeholders and Scrum Teams

Ajout d’un troisième thème pour le Sprint Planning : le Pourquoi

Le Sprint Planning était jusqu’à maintenant divisé en deux thèmes : le Quoi et le Comment.

Dans cette nouvelle version du Scrum Guide, le Sprint Planning est maintenant composé de trois thèmes : le Pourquoi, le Quoi et le Comment

• Thème 1 : Pourquoi ce Sprint apporte-t-il de la valeur ?
• Thème 2 : Que peut-on réaliser pendant ce Sprint ?
• Thème 3 : Comment le travail va-t-il être réalisé ?

Cet ajout revient juste à formaliser la création de l’Objectif de Sprint (Sprint Goal) qui était jusqu’à maintenant inclus dans le thème « Quoi ».

Rendre explicite sa création renforce l’importance de l’Objectif de Sprint. Un ajout qui va dans le bon sens car c’est toujours une bonne chose lorsque les développeurs comprennent le pourquoi de ce qu’ils développent.

Suppression des trois questions du Daily Scrum

Une modification majeure apportée par cette version du Scrum Guide est la disparition des trois questions historiques du Daily Scrum (Qu’est-ce que j’ai fait hier…?, Que vais-je faire aujourd’hui…? Est-ce que je vois des obstacles… ?).

Dans un premier temps obligatoires, elles n’étaient présentes qu’à titre d’exemple de pratique depuis 2017.

J’apprécie beaucoup cette suppression. Pour moi ces questions très « mécaniques » sont l’une des raisons pour lesquelles le Daily Scrum ne fonctionne généralement pas bien et se transforme souvent en réunion de compte-rendu d’activité.

Elles ont tendance à mettre l’accent sur le travail individuel (chacun parlant de son propre travail) plutôt que sur l’aspect collectif. Et l’aspect très « mécanique » des questions (chacun ayant son temps de parole) va à l’encontre des discussions collectives.

Le Daily Scrum doit être un lieu d’échange qui permet les discussions nécessaires entre les participants. Les supprimer permet donc de se recentrer sur le but premier de cet événement : synchroniser le travail de l’équipe pour la journée afin d’être collectivement en mesure d’atteindre l’objectif du Sprint.

J’aime aussi beaucoup l’ajout de cette phrase qui insiste sur le fait que le Daily Scrum ne doit pas être le seul moment d’échange et de collaboration de l’équipe :

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Scrum Guide 2020

Allègement de la description de la Revue de Sprint

La partie consacrée à la Revue de Sprint a été entièrement réécrite pour ne garder que l’essentiel.

A noter la suppression de la phrase suivante qui n’apportait de mon point de vue que de la confusion vis-à-vis de la rétrospective :

The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved

Scrum Guide 2017

Rétrospective

La partie consacrée à la Rétrospective a également été entièrement réécrite avec un focus sur la prise d’actions :

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

Scrum Guide 2020

Bienvenue au Product Goal…

En 2013, la notion de Sprint Goal avait été ajoutée. Le Scrum Guide 2020 introduit quant à lui le concept de Product Goal.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.

Scrum Guide 2020

Alors que le Sprint Goal définit l’objectif à court terme de l’équipe Scrum, le Product Goal peut être vu comme son objectif à long terme. Il lui permet de rester focalisée, chaque élément du backlog et chaque Sprint devant permettre de s’en rapprocher.

A noter aussi que pour la première fois, le Scrum Guide donne la définition du mot produit :

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Scrum Guide 2020

… et aux “Commitments”

Jusqu’à maintenant, Scrum définissait uniquement 3 artefacts (Product Backlog, Sprint Backlog et Incrément). Les deux derniers éléments de Scrum, le Definition of Done et le Sprint Goal, n’étaient pas vraiment considérés comme des artefacts (le Definition of Done était décrit comme un artefact de transparence) et il était difficile de les mettre dans une catégorie.

Pour remédier à ça, le Scrum Guide définit maintenant un « engagement » pour chacun des 3 artefacts. Pour le Sprint Backlog, c’est le Sprint Goal. Pour l’Incrément, c’est le Definition of Done. Et pour le Product Backlog, c’est donc le tout nouveau Product Goal. Chaque engagement est là pour augmenter la transparence et permettre de s’assurer de l’avancement vers chacun des artefacts.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

For the Product Backlog it is the Product Goal.

For the Sprint Backlog it is the Sprint Goal.

For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Scrum Guide 2020

Backlog, la fin du D.O.V.E

Concernant le Product Backlog, le nouveau Scrum Guide est beaucoup moins prescriptif.

Jusqu’à maintenant, chaque élément du backlog devait obligatoirement posséder les 4 attributs suivants : description, ordre, estimation et valeur (DOVE).

Product Backlog items have the attributes of a description, order, estimate, and value

Scrum Guide 2017

Aujourd’hui, il est stipulé que les attributs peuvent être différents suivant les domaines.

3 des 4 anciens attributs (description, ordre, taille) sont maintenant donnés uniquement à titre d’exemple. L’attribut « valeur » disparait donc du Scrum Guide.

This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Scrum Guide 2020

De plus, le mot « estimation » est remplacé par le mot « taille ».

La préconisation des 10% de la capacité de l’équipe pour le refinement disparait également du guide.

Refinement usually consumes no more than 10% of the capacity of the Development Team.

Scrum Guide 2017

Increment, place à la livraison continue

Dans les précédentes versions du Scrum Guide, l’équipe de développement devait délivrer un increment de produit à la fin de chaque Sprint. Et cet incrément devait être potentiellement livrable :

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.

Scrum Guide 2017

Ce point conduisait à une critique de Scrum assez fréquente : en Scrum, on ne peut livrer qu’à la fin de chaque Sprint !

Pourtant, rien dans le guide ne vous empêchait de livrer plus fréquemment.

La nouvelle version du Scrum Guide est très claire là dessus :

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Scrum Guide 2020

Ce point constitue selon moi une des meilleures modifications de cette version. La livraison de l’Increment est maintenant décorellée de la fin du Sprint, ce qui incitera peut-être les équipes à livrer plus fréquemment.

Conclusion

Comme vous avez pu le voir, le millésime 2020 du Scrum Guide remet beaucoup de choses en cause. Si l’on peut saluer le souci de simplification, certains points (comme la disparition de l’Équipe de Développement, le choix du mot Developers, le Scrum Master reponsable de l’efficacité de l’équipe…) sont plus contestables. J’attends aussi de voir quelles repercussions auront ces modifications sur les frameworks d’agilité à l’échelle.

Le résultat est en tout cas un Scrum Guide beaucoup plus simple à lire et à comprendre. La contrepartie, c’est qu’il donne beaucoup plus de place à l’interprétation. En étant moins prescriptif, il laisse potentiellement la place à des implémentations plus ou moins fantaisistes de Scrum. Et vous, qu’en pensez-vous ?

Retrouvez l’intégralité du Scrum Guide 2020 : https://scrumguides.org/