Ma première lecture du Scrum@Scale Guide
Scrum Master depuis plus de 6 ans, je viens de changer de mission. Ayant surtout connu des contextes avec un petit nombre d’équipes Scrum, plus ou moins isolées, c’est la première fois que je suis confronté à un vrai contexte de mise à l’échelle de l’agilité. Ce n’est plus une équipe ou deux qui interagissent ensemble mais des groupes de 3 à 6 équipes Scrum qui cohabitent dans la même entreprise autour de 2 ou 3 gros produits. Tout naturellement, je cherche à me documenter sur le sujet. Au moment où j’écris ces lignes, la version 1.05 du Scrum@Scale Guide vient tout juste d’être publiée (29/04/2019). Il s’agit de la vision du Scrum à l’échelle créée par Jeff Sutherland, le co-auteur du Scrum Guide sur lequel je m’appuie au quotidien. En voici ma première lecture.
Premières impressions
C’est parti pour les 19 pages qui composent ce guide. Après avoir parcouru sa version anglaise (des traductions existent), une petite pause est nécessaire pour digérer… Si le Scrum Guide définit le cadre qui s’applique à une équipe d’une dizaine de personnes maximum, ce guide, lui, va bien au-delà. On passe à l’échelle avec une architecture “scale-free” (libre d’échelle) ce qui est assez déroutant (le modèle pouvant être reproduit à différents niveaux sans limites). Là où le framework d’équipe est précis et rigoureux, sa version à l’échelle, bien qu’intégrant une nouvelle terminologie et de nouvelles cérémonies, laisse place à une plus grande souplesse et adaptation. J’ai eu le sentiment d’un ensemble de règles bureaucratiques là où Jeff explique que Scrum@Scale met en place une minimum viable bureaucracy pour gérer de façon efficace une multitude d’équipes Scrum.
Passé ce premier effet déconcertant, rentrons dans le vif du sujet.
Retour aux sources
Scrum@Scale veut étendre naturellement Scrum à toute l’organisation. Par là, il faut entendre les services de l’IT mais pas que. Le but est d’appliquer Scrum à toute l’entreprise. La pratique a prouvé que la multiplication des équipes Scrum a tendance à diminuer leur vélocité et l’évolution de leurs produits. C’est de là que vient la volonté de structurer ces organisations avec le but ultime de livrer le double de valeur en la moitié de temps avec un plus haut niveau de qualité et un meilleur cadre de travail.
Les caractéristiques de Scrum@scale restent les mêmes que celles de Scrum :
Léger (la bureaucratie minimum viable)
Simple à comprendre (que des équipes en Scrum)
Difficile à maîtriser (car implique la mise en place de nouveaux modèles opérationnels)
Les mêmes valeurs : ouverture, courage, focus, respect et engagement.
Les mêmes piliers : transparence, inspection et adaptation.
On applique du Scrum sur du Scrum. Ce qui implique qu’avant de se lancer dans sa version à l’échelle, il est impératif d’appliquer correctement Scrum. Sans quoi, on ne fera que porter à l’échelle ses travers. Selon moi, beaucoup de compagnies qui se lancent dans une démarche de transformation agile veulent griller des étapes. S’assurer que la base Scrum est bien en place avant d’aller plus loin devrait être la première étape avant de se lancer dans une refonte organisationnelle.
Les deux cycles qui se croisent et se supportent
On retrouve la séparation claire du “quoi” et du “comment” via la mise en place de deux cycles : le Cycle Product Owner et le Cycle Scrum Master. Je ne vais pas rentrer ici dans les détails de ces cycles. Ce qu’il faut retenir c’est que cela se base sur le Scrum of Scrums (SoS) et l’étape supérieure le Scrum of Scrums of Scrums (SoSoS). (Pour la version détaillée : https://scrumatscale.scruminc.com/scrum-at-scale-guide-online/#the-scrum-of-scrums)
Dans le cycle SM, on va trouver des Scales Daily Scrum (SDS) où les SM (ou d’autres membres de l’équipe) vont se réunir quotidiennement pour partager les différents blocages. Un Scrum of Scrums Master (SoSM) anime ces interactions. Ce dernier peut participer à des niveaux supérieurs de SoSoS (on peut vite s’y perdre avec tous ces S). Là où personnellement j’ai tendance à faire monter en compétence les équipes dans la résolution par eux-mêmes de leur problématiques, ce cycle favorise plus la remontée via le SM qui peut remonter au SM des SM etc.
Ultimement, un souci sera remonté jusqu’à l’Executive Action Team (EAT). Il s’agit du groupe d’individus qui a tous les pouvoirs pour résoudre tous les impédiments, qu’ils soient financiers ou politiques. Comme à chaque niveau, l’EAT a un PO, un SM et un backlog transparent. L’aspect qui m’a vraiment intéressé est cette entité qui est définie de base dans le framework. Elle est en charge de faire émerger la vision commune de Scrum (nécessaire pour être mise à l’échelle) et surtout gère un backlog de transformation organisationnel. Je trouve que c’est une force de ce cadre de travail de rendre visible une structure de transformation non pas formée que de coachs mais d’acteurs de l’organisation et de personnes ayant un vrai pouvoir décisionnel.
Si par nature les Scrum Masters chercheront à s’organiser, il est intéressant de voir l’importance donnée à l’organisation des PO dans leur cycle dédié. A chaque SoS, une équipe de PO est associée. On parle de MetaScrum (MS). Scrum@Scale introduit le Chief Product Owner (CPO) qui jouera le rôle de PO de cette équipe de PO. Dans chaque MS quelqu’un devra assumer un rôle similaire à SM mais je n’ai pas vu d’appellation spécifique lors de cette première lecture. A l’équivalence de l’EAT, on trouvera l’Executive MetaScrum (EMS) qui regroupe les stakeholders, les business owners et la direction qui doivent se réunir au moins une fois par sprint pour s’aligner avec les CPO (voir les CCPO si on en est à mettre en place des SoSoS)
Un schéma d’exemple d’implémentation tiré du site officiel sera assurément plus parlant.
https://scrumatscale.scruminc.com
https://creativecommons.org/licenses/by-sa/4.0/
Le guide décrit chacun des nouveaux rôles et la façon de mettre à l’échelle. Il survole les objectifs des cycles SM (amélioration continue et suppression des obstacles, coordination inter-équipe, déploiement) et PO (vision stratégique, priorisation du Backlog, décomposition et raffinement du Backlog, planning de release) mais aussi leurs interactions autour de métriques et d’une attention particulière à la transparence. Le tout d’une façon précise mais sans rentrer dans la rigueur et la précision d’un Scrum Guide.
Les abonnés absents
Scrum vous parle de 3 rôles dans une équipe sans liens hiérarchiques et ne vous parlera jamais de management. On retrouve ici la même chose. Le management des équipes est à la discrétion de l’organisation. J’aurais aimé l’introduction d’éléments du management 3.0 ou de tout autre élément guidant dans un contexte d’agilité à l’échelle où on tend à supprimer les managers.
En Scrum, le SM guide le PO, l’équipe de développement et l’organisation. Il est leur coach dans l’apprentissage de Scrum. Le framework, n’intègre pas de rôle de coach agile. Il en est de même à l’échelle. Si naturellement, les coachs agiles se positionneront en facilitateurs de SoS ou de MS et participeront activement à l’EAT, ils ne sont pas sensés faire parti de l’équation.
Et en dernier, je note l’absence des équipes de réalisation. J’ai conscience qu’à l’échelle on va parler de l’organisation des rôles plus transverses que sont les PO et SM. Mais, j’aurais apprécié des éléments impactants / impliquants les développeurs dans cette démarche à l’échelle. La réponse réside assurément dans le Scrum Guide.
Après la seconde lecture
Pour ne pas dire des bêtises, vous aurez bien compris qu’en écrivant ces quelques mots j’ai relu en parallèle le guide sachant à présent à quoi m’attendre. Bien que le concept existe depuis plusieurs années, la première version du guide ne date que de février 2018. Il va encore évoluer. Dans quelques mois, une nouvelle version sortira. A l’heure actuelle, j’en retiens un ensemble d’idées, une structure pour passer à l’échelle tout en se basant sur la force du Scrum. J’apprécie la présence de l’EAT et du Cycle PO. Surtout, je repars avec la conviction qu’en tant que Scrum Master, je dois faire au mieux pour qu’au niveau de mes équipes Scrum soit mieux appliqué (et adapté sans être dénaturé) pour que l’agilité puisse ensuite passer à l’échelle.
© SOAT
Toute reproduction interdite sans autorisation de l’auteur.