Scrum@Scale – agilité à l’échelle

Jeff Sutherland, co-créateur de Scrum, nous propose un nouveau framework d’agilité à l’échelle appelé Scrum@Scale. En quoi consiste ce nouveau framework ?

Il existe de plus en plus de framework agiles pour faire de l’agilité à l’échelle et je trouve intéressant de tous les explorer. J’ai donc décidé de regarder le dernier né afin de voir ce qu’il propose d’intéressant pour les organisations agiles.

Vous pouvez aller voire d’autres frameworks à l’échelle que le scrum@scale sur lesquels j’avais fait quelques articles afin de vous faire une idée des framework d’agilité à l’échelle qui existent :

Framework SAFe 4.5
Framework SSwS
Modèle Spotify
Scrum of Scrum : Coordonner plusieurs équipes
Framework Nexus
LeSS
LeSS Huge

Scrum@Scale, les bases

Comme pour le Scrum Guide , le Scrum@Scale est expliqué en 18 pages avec le Scrum@Scale Guide. J’ai eu l’envie de le décortiquer par curiosité car je n’ai pas encore eu la chance de l’appliquer moi même.

Le Scrum@Scale semble vouloir se positionner comme un framework simple ; sans directement le citer, je pense qu’il fait référence à SAFe qui est très complet et complexe à mettre en place.

Du coup ce nouveau framework Scrum@Scale selon son auteur est défini par 3 points importants à comprendre :

1. Poids légers – le « minimum viable bureaucracy » (référence au MVP mais pour la bureaucratie)
2. Simple à comprendre – concerne seulement les équipes scrum
3. Difficile à maitriser – impose d’implémenter un nouveau modèle opérationnel

Le Scrum@Scale a uniquement pour but de mettre à l’échelle du Scrum et n’a pas la prétention de gérer toutes les couches comme l’impose SAFe ; c’est un positionnement clair et concret. Il permettra de coordonner plusieurs équipes Scrum entre elles avec du Scrum of Scrum et du Metascrum.

Cependant vous allez vite voir, qu’il est très compliqué de mettre ce modèle en place tant il ne répond pas aux nombreuses attentes des grandes organisations alors qu’il semble simple dans son fonctionnement.

L’entreprise pourra sans soucis organiser elle même la stratégie de transformation qu’elle désire mettre en place avec ce framework.

Les composants de scrum@scale

Voici la représentation de l’ensemble des composants du Scrum@Scale qui n’est pas si simple à lire au premier regard malgré la tentative de simplification par rapport à d’autres framework.

Ce schéma montre volontairement l’envie de bien séparer le « comment » géré par les Scrum Master et le « pourquoi » géré par les Product Owner. Ce n’est pas clair ? Pas de panique, je vais tout vous expliquer.

Scrum@scale : le cycle Scrum Master

Au niveau des équipes elles-mêmes, le framework n’impose rien de nouveau car celles-ci travailleront dans un Scrum classique. Par contre, les équipes Scrum vont se coordonner ensemble en utilisant le très connu Scrum of Scrum.

Les équipes se coordonneront alors en faisant la fameuse Scaled Daily Scrum (SDS) en rassemblant les Scrum Master ou de simples ambassadeurs de chaque équipe scrum. Ils feront exactement le même exercice qu’une Daliy Scrum de 15 minutes mais à un niveau moins détaillé avec les 3 questions suivantes :

1. Avez-vous rencontré des obstacles pour atteindre les objectifs du sprint ?
2. Qu’avez-vous fait pour permettre à une autre équipe d’avancer sur son travail ?
3. Avez-vous découvert de nouvelles dépendances entre les travaux des teams ?

Dans ce framework, l’équipe de Scrum of Scrum réalisera un Backlog Refinement pour gérer les obstacles rencontrés ; si le terme utilisé est le même qu’en Scrum classique, on y travaille pas la même chose.

Cette équipe va également réaliser ensemble une SoS Retrospective pour continuellement faire de l’amélioration continue comme le fait une équipe scrum classique.

Pour aider à coordonner toutes ces équipes Scrum, ce framework propose de mettre en place un Scrum of Scrum Master (Sos Master) et aura les rôles suivant :

1. Mettra en place et gèrera le board d’obstacle
2. S’occupera de supprimer tous les obstacles que les équipes elles-mêmes ne peuvent pas supprimer
3. Sera responsable de la priorisation des obstacles et distribuera ceux qui concernent certaines équipes.
4. Améliorera continuellement le Scrum of Scrum
5. Travaillera avec les Product Owner pour tenter d’organiser des releases à chaque itération.
6. Cordonnera les équipes pour gérer des plans de release.

Comme nous l’avons vu dans le Scrum of Scrum classique, il est possible de scaler plusieurs Scrum of Scrum ensemble quand il y a besoin d’un plus grand nombre d’équipes ; on appelle cela du scrum of scrum of scrum (Sosos).

Pour rappel, chaque équipe Scrum doivent être composée de 3 à 9 personnes (pour ma part je recommande même de ne pas dépasser les 7 développeurs).

Scrum@scale : the Executive Action Team (Le EAT)

Le scrum of scrum de plus haut niveau s’appelle l’Executive Action Team : elle a pour but de coordonner l’ensemble des Sosos de l’entreprise et d’être le dernier rampart pour supprimer les obstacles rencontrés que personne n’a pu lever ; cette équipe est habilité politiquement et financièrement à le faire.

Cette équipe a comme rôle également de créer un backlog de la transformation de l’organisation (Organizational Transformation Backlog) et de suivre son avancement.

Voici les rôles clés qu’on attendra de cette équipe EAT :

• création du modèle du scaling (mise à l’échelle) de l’entreprise en définissant les règles opérationnelles, les procédures et les guidelines
• mesurer la maturité agile et scrum des équipes ainsi que d’améliorer la qualité de l’application du scrum
• création d’un centre de formation continue scrum
• recherche de nouvelles voix pour améliorer le travail

Scrum@scale : l’organisation de la Scrum Master Organization

Les rôles principaux de cette organisation générale de Scrum Master sont :

1. l’amélioration continue et la suppression des obstacles
2. la coordination des équipes transverses
3. la gestion des déploiements

Ils devront faire leur possible pour maintenir un environnement sécurisé et structuré pour prioriser correctement et ne plus avoir d’obstacles.

Scrum@scale : le cycle du Product Owner

Les Product Owner vont ensemble gérer un même Product Backlog en créant ensemble une équipe appelée la MetaScrum ; il y a une équipe MetaScrum par Scrum of Scrum. Du coup, c’est cette équipe qui fera le Product Backlog Refinement une fois par semaine en invitant les parties prenantes, les sponsors et des utilisateurs clés.

Les fonctions principales de cette équipe Metascrum seront de :

• créer une vision du produit et de faire en sorte de bien la partager à l’ensemble des équipes Scrum
• construire un véritable suivi avec les parties prenantes clés de l’implémentation du backlog
• créer un backlog unique et priorisé tout en s’assurant qu’il n’y a pas de duplication de demandes.
• créer un « Definition of Done » unique pour l’ensemble des équipes de la Scrum of Scrum.
• éliminer les dépendances remontées par la Scrum of Scrum
• générer un plan de release coordonné
• décider et monitorer des métriques qui indiquent la perspicacité du produit

Le CPO (Chief Product Owner) sera comme dans un Scrum of Scrum classique, celui qui saura aider l’équipe à bien s’organiser autour des différents sujets ; il sera un peu comme le Scrum Master de cette équipe MetaScrum.

Voici un article qui parle plus concrètement du rôle du CPO.

Article : Qu’est-ce que le Chief Product Owner (CPO) ?

Scrum@scale : le scaling du MetaScrum

De la même façon que pour le Scrum of Scrum, les équipes MetaScrum vont se créer selon le nombre d’équipes. En cas de Scrum of Scrum of Scrum (Sosos), alors il y aura un CCPO (Chief chief Product Owner) pour coordonner tous les CPO.

Au même niveau qu’un EAT, on créera également un Executive MetaScrum (EMS) afin de gérer la vision organisationnelle et la stratégie générale.

Scrum@scale : l’organisation de Product Owner

Cette organisation devra gérer la vision stratégique, la priorisation et l’affinage du backlog ainsi que la planification de release.

Les buts de la vision stratégique sont :

• d’aligner clairement l’organisation complète et le chemin vers où aller
• articuler de manière convaincante le pourquoi l’organisation existe
• décrire ce que l’organisation veut faire pour tirer parti des atouts clés dans le suivi de sa mission
• capable de répondre continuellement aux changements de conditions marketing

Les buts de la priorisation du backlog sont :

• identifier un ordre clair des produits, des fonctionnalités et des services à livrer
• réfléchir à la création de valeur, aux risques et les dépendances internes et ordonner le tout
• prioriser les initiatives de haut niveau dans toute l’organisation agile avant la décomposition et l’affinage du backlog

Les buts de la décomposition et l’affinage du backlog sont :

• de découper les projets complexes et les produits en éléments fonctionnels qu’une équipe Scrum peut terminer en 1 seul sprint.
• d’obtenir et distiller les pré-requis et feedback clients.
• de s’assurer que tous les items du backlog sont bien « Ready » pour être pris par les équipes

Les buts de la planification de release sont :

• la prévision de la livraison des fonctionnalités clés et capacités
• de communiquer les attentes en matière de livraison aux stakeholders
• modifier la priorisation si besoin

Conclusion scrum@scale

Vous connaissez maintenant les grandes lignes de ce nouveau framework d’agilité à l’échelle Scrum@Scale qui est en fait une amélioration du très connu Scrum of Scrum.

Si il n’a pas la prétention de tout couvrir, il permet d’adapter l’organisation agile au delà de nos équipes métiers et techniques. Mais ne souffre t’il pas des mêmes soucis que le scrum of scrum classique ?

Cependant, j’espère que ce petit tour de ce dernier framework d’agilité à l’échelle scrum@scale saura vous aider pour créer vos propres modèles d’agilité à l’échelle à l’avenir.