Le Scrum Guide est mort. Vive le Scrum Guide !

Pour fêter son quart de siècle, Scrum a récemment fait sa petite révolution. Ken Schwaber et Jeff Sutherland, ses créateurs ont profité de l’évènement pour revoir certains aspects en profondeur.

Cet article n’a pas pour but de vous afficher simplement le changelog, mais de vous donner un avis et une lecture de ce changement.

« It doesn’t matter how good you are today; if you’re not better next month, you’re no longer agile. »
Mike Cohn

Le Scrum guide a déjà évolué à plusieurs reprises depuis sa création, en ajoutant le DoD dans les artefacts, en ajustant certains termes de vocabulaire ou en retravaillant les valeurs. Mais cette fois-ci, c’est une changement majeur qui a été opéré et même s’ils ne sont pas parti from scratch, le Scrum guide n’a pas été revu que sur quelques points de wording.

Les nouveautés du Scrum Guide

Premier point marquant de cette nouvelle mouture : la taille.
Là ou d’autres Frameworks (SAFe par exemple) ont tendance à s’enrichir et à se complexifier à chaque nouvelle version, Scrum reste sur son principe d’origine : le Scrum guide reprend un tout cohérent de ce qui a été expérimenté et qui marche le mieux et tout ce qui n’est pas identifié clairement par les auteurs comme la meilleure solution (il peut y avoir plusieurs façons de faire qui marchent aussi bien les unes que les autres) est laissé au choix de ceux qui l’implémentent.

Le Scrum Guide est passé de 20 à 15 pages (dans sa version française, en comptant les pages d’intro et de changelog).

« It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. »
Antoine de Saint-Exupéry

Le KISS (Kepp It Simple Stupid), qu’on applique au code comme pratique agile, s’applique également à l’organisation, et on peut voir ici que Scrum se l’applique aussi à lui-même en rendant son guide plus léger et plus digeste. On cherche ici à enlever tout ce qui n’est pas idéal et ne conserver que ce dont on est certain qui apporte de la valeur ajoutée.

Par exemple, la notion de dev team disparaît pour ne laisser place qu’à l’unique Scrum team composée du Product Owner, du Scrum Master et des développeurs. Cela enlève une complexité qui n’apportait finalement que peu de valeur. D’autant que dans les faits, cela était souvent assez peu respecté.

Le daily par exemple était censé appartenir à la dev team et donc le PO ne devait pas y être convié. Or, d’expérience, je trouve que la présence du PO au daily apporte souvent de la valeur si on parvient à éviter les pièges courants (tomber dans un rituel de report d’activité ou de mesure de productivité par exemple).

Cette nouvelle orientation se rapproche davantage de la définition d’une équipe au sens XP où tout le monde est engagé sur le même résultat mais où des expertises se distinguent pour être complémentaires sans forcément mettre une frontière claire entre les parties ou faire des équipes dans l’équipe.

Ce qui va changer pour les équipes

Opérationnellement, qu’est-ce que cela change pour les équipes Scrum ? Finalement pas grand-chose. L’impact le plus important sera pour les formateurs qui doivent retravailler sur ce sujet et actualiser en profondeur leurs contenus.

Autre axe qui était déjà présent mais qui a été largement clarifié : l’orientation de Scrum.

Scrum est pensé de façon « générique ». Déjà auparavant, mêmes les fervents défenseurs de Scrum le disaient : Scrum c’est bien, mais si vous voulez faire de l’agilité en développement logiciel, faites plutôt de l’XP. C’est maintenant plus clair, Scrum n’est pas destiné (uniquement) au monde du logiciel, mais c’est bien un framework générique qui peut s’adapter à de nombreux domaines. Cela accompagne les courants de pensée de ces dernières années qui tendent à pousser les valeurs de l’agilité en dehors de l’IT.

Appliquer l’agilité à la RH, à la comptabilité, ou même au commerce. Scrum peut aider à aller dans cette voie. Toutes les références au développement ont été enlevées du Scrum guide ou remplacées par des termes plus génériques pour faciliter la transposition à d’autres types d’environnements. Dit autrement, l’objectif est d’adresser une nouvelle cible d’utilisateurs.

Le développement logiciel constituait les early adopters, il est maintenant temps d’aller plus loin et de toucher une majorité de la population.

Enfin, point qui me semble réellement important pour ceux qui découvrent Scrum : la mise en évidence de la relation entre les artefacts et les objectifs.

L’objectif de produit a été ajouté et lié directement au Product Backlog, l’objectif de sprint lié au sprint backlog et l’incrément lié à la Definition of Done. Pour les équipes matures, cela ne change rien. Ces éléments étaient déjà présents auparavant en filigrane et les équipes avec un peu d’expérience faisaient ce lien naturellement. Mais pour les équipes qui débutent, on retrouvait souvent l’absence de vision pour le produit, reproche que j’ai entendu à de nombreuses reprises : « avec l’agilité, on a plus de vision, on vit au jour le jour sans savoir où on va ».

C’est évidemment un anti-paterne Agile, mais le fait de définir explicitement qu’une vision produit est nécessaire et qu’elle doit être traduite par un product backlog  permettra d’éviter des dérives.

Pour aller un peu plus loin…

D’autres points ont évolué pour clarifier certaines parties qui définissent Scrum.

L’accent a été remis sur l’autonomie qu’il est nécessaire de laisser aux Scrum teams en parlant maintenant d’équipes autogérées, plutôt qu’auto organisées. Probablement pour contrecarrer la tendance que l’on voit souvent apparaître d’équipes qui n’ont d’auto-organisé que le titre et auxquelles on intègre des managers ou responsables (d’anciens chefs de projets) qui leur laissent l’organisation (planifiez-les vous-même vos « dailys-trucs » ! ) mais qui en contrepartie sont au sein de l’équipe pour répartir les tâches quotidiennement.

Le rôle du Scrum Master a aussi été remis plus en avant. Il est trop fréquent de voir des équipes sans Scrum Master, ou dans lesquelles le PO est à la fois développeur, Scrum Master et UX designer… Or, pour faire du Scrum, la présence d’un Scrum Master n’est pas négociable. Il représente pour l’équipe le levier qui lui permet de prendre du recul, d’avoir un soutien, d’être challengé (sans être oppressé), de garder le cap en ligne de mire, même quand la production et les urgences nous occultent toutes choses par ailleurs.

Certains mettront en avant la disparition de la notion d’estimation et préfèrent la notion de sizing, la suppression des 3 questions du daily, la simplification de certains éléments de vocabulaire autour des PBIs ou encore l’ajout de thèmes au sprint planning. Pour moi, ce sont des apports mineurs qui ne changent pas réellement le fonctionnement ou la valeur du Scrum guide. Ces éléments étaient déjà intégrés ou à minima n’étaient pas des freins pour les équipes qui mûrissent.

Le bilan

Pour conclure, que penser de cette nouvelle version du Scrum Guide ? Une évolution peut être une régression ou une dégradation aussi bien qu’une amélioration.

Si on conçoit Scrum comme un produit, quelle est la valeur livrée ici ?

Pour les équipes qui pratiquent depuis quelques temps déjà, pas de réel changement. Leurs usages ne vont probablement pas être impactés ou uniquement à la marge (probablement bien moins impactant sur leurs pratiques qu’une seule de leur rétro de sprint).

Pour les agents du changement de Scrum (Coach Agiles, Scrum Masters, formateurs, etc…), cela va à mon sens donner un peu de travail supplémentaire pour mettre à jour les supports de formations mais d‘un autre côté, faciliter les explications et la transmission de connaissance. Un mal pour un bien en somme.

La véritable valeur ajoutée est principalement pour ceux qui ne connaissent pas Scrum. Les jeunes équipes de dev qui découvrent, les métiers en dehors de l’IT qui vont pouvoir se lancer plus facilement.

Toujours en considérant un produit, Scrum a évolué pour élargir sa cible d’utilisateurs sans introduire de régression pour ses early adopters. Les dérives observées sur le terrain (bugs de prod) sur le rôle du Scrum Master ou l’absence de vision produit ont donné lieux à des correctifs mineurs, mais le backlog a été priorisé pour servir leur vision : simplifier la compréhension pour toucher un public plus large (je m’abstiendrai dans cet article les remarques cyniques sur le business model des certifications qui a peut-être un lien avec cette stratégie).

Cette version majeure du Scrum Guide livre donc pas mal de valeurs d’après moi, mais les vieux agilistes, ou ceux qui se demandent ce qui a changé depuis 2017 n’en sont probablement pas les bénéficiaires. La valeur sera pour ceux qui n’ont pas encore conscience que la mise à jour a été faite pour eux.

Léonard, Team NEXTON