Nom : Large-Scale Scrum aka LeSS
Catégorie : mise à l’échelle de Scrum
Créateurs : Craig Larman & Bas Vodde
Documentation de référence : https://less.work
Cible : plusieurs équipes travaillant ensemble sur le même produit ; produit au sens solution adressant les problèmes clients/utilisateurs et utilisée par de vrais clients/utilisateurs.
Scrum est un cadre de développement dans lequel une équipe développe un produit de manière incrémentale et itérative. À chaque Sprint, un incrément de produit est livré. Un Product Owner (PO) est responsable de la maximisation de la valeur du produit, de la hiérarchisation des éléments dans le backlog de produit et de la détermination du but de chaque sprint tout cela en se basant sur des retours d’expérience et un apprentissage constants. Une équipe de développement est responsable de la réalisation de l’objectif de Sprint. Un Scrum Master aide le Product Owner, l’équipe de développement et l’organisation à appliquer Scrum et à en tirer profit.
Vous trouverez ici une présentation succincte illustrée et là la documentation officielle.
LeSS se veut une extension de Scrum pour plusieurs équipes travaillant sur le même produit. Nous retrouvons donc dans LeSS tous les rôles, événements et artéfacts définis par Scrum.
LeSS se veut léger, simple et peu contraignant. Pour cela, il n’introduit ni nouveaux rôles ni nouveaux artéfacts.
À l’échelle du produit, LeSS prend la forme du Scrum classique : un PO unique qui donne la vision, un Backlog produit, un Sprint, un planning de Sprint, une revue de Sprint, une rétrospective, un incrément et une définition de “Fini”.
Là où, dans Scrum, on a une équipe de développement accompagnée d’un Scrum master, on trouve dans LeSS plusieurs équipes de développement chacune aidée d’un Scrum master.
À cause du nombre de personnes impliquées, les événements Scrum ont été adaptés.
Le planning de Sprint a pour objectifs de déterminer ce que nous allons faire et comment nous allons le faire. LeSS le divise donc en deux phases :
Lors de la rétrospective, l’équipe cherche à améliorer sa manière de travailler. LeSS la divise en deux phases pour adresser deux périmètres :
Les besoins de synchronisation entre les équipes sont identifiés lors de la première phase du planning de Sprint.
La synchronisation entre les équipes est de la responsabilité des équipes. Il n’y a pas de rôle ou d’évènement spécifique pour la coordination des équipes.
Un dialogue direct entre les clients/utilisateurs et les équipes permet à la fois d’alléger la charge du PO et de rapprocher les développeurs du terrain. Le PO se positionne alors en tant que facilitateur plutôt qu’intermédiaire pour les tâches de clarification des éléments du Backlog.
Et LeSS ne spécifie rien de plus sur la forme.
Les règles qui décrivent le cadre ne représentent qu’une petite partie de LeSS.
Le cœur de LeSS est constitué de dix principes qui guident la mise en œuvre :
Vous en aurez reconnus la plupart : ils sont essentiellement issus ou inspirés du manifeste Agile, de Scrum et du Lean.
La documentation fournit aussi des conseils et recommandations pour la mise en œuvre de LeSS et en faciliter l’adoption. Ils concernent :
On y trouve aussi de nombreux retours d’expérimentations dans diverses entreprises qui constitueront une base d’inspiration pour construire votre propre implémentation.
Jusqu’à ce que le PO fasse un burnout !
Le PO est en effet unique quelque soit le nombre d’équipes … Équipes qu’il faut alimenter en fonctionnalités … Fonctionnalités qu’il faut recueillir et affiner …
Empiriquement, la limite a été mise à huit équipes. Au delà de huit équipes, LeSS propose une version Huge du framework qui est une mise à l’échelle de la version standard.
La version Huge propose simplement de séparer les éléments du Backlog par “domaines de prérequis” et d’en déléguer la gestion à des PO de domaine (ou APO). Pour le reste tout fonctionne comme dans la version pour moins de huit équipes.
Le point faible de LeSS est la charge que l’on met sur le PO. Même si LeSS a quelques conseils pour la limiter, elle est importante à prendre en compte, et ce, dès le début de la mise en place de LeSS. On peut pour cela porter une attention particulière à la définition du produit. La définition du produit permet d’identifier naturellement le nombre de personnes impliquées. Le périmètre sur lequel vous souhaitez mettre en place LeSS ne sera peut-être plus celui auquel vous pensiez au départ …
S’il ne fallait retenir qu’un principe ce serait celui-là : « More with LeSS ». Il incarne la philosophie de la démarche des créateurs de LeSS : réduire la complexité (procédures, rôles, bureaucratie, organisations imposées, etc.) pour augmenter la valeur apportée aux clients/utilisateurs.
En suivant ce principe et le constat par lequel il est plus facile d’ajouter que de retirer des règles, LeSS donne une structure minimale juste suffisante dont les équipes ont besoin pour démarrer. L’adaptation nécessaire qui suivra permettra aux équipes de s’approprier leurs process.
Ce principe encourage aussi les équipes à résister à la tendance naturelle de rajout de complexité pour résoudre les problèmes. Un des moyens d’y parvenir est d’adresser la source du problème plutôt que de s’attaquer aux symptômes.
LeSS est un framework qui séduit de par sa simplicité surtout quand on est déjà familier avec Scrum. Mais, comme Scrum, sa simplicité cache la difficulté à le maîtriser. Cette difficulté n’est pas propre à LeSS, elle est au cœur de toutes les transformation organisationnelles.
Le succès d’une transformation repose sur quelques principes clefs : ne pas changer pour changer, accepter de sortir les squelettes du placard, engager les individus, faire en sorte que les acteurs s’approprient le système, etc. Les auteurs de LeSS adressent cette difficulté sous forme de conseils et d’exemples concrets issus d’expérimentations de mise à l’échelle de Scrum. Leur présence dans le framework même rassure quant à la maturité de LeSS : les auteurs vous annoncent clairement la couleur, la mise en œuvre demandera du travail.
Tous les auteurs de framework de mise à l’échelle de Scrum sont d’accord sur ce point : il faut commencer par faire fonctionner Scrum correctement dans une équipe avant de passer à l’échelle.
Une des raisons pour laquelle la mise en place Scrum au sein d’une équipe échoue est souvent que les principes de Scrum ne sont pas respectés :
Pour LeSS c’est pareil … et c’est d’autant plus important que la mise à l’échelle accentue les problèmes. Alors autant les résoudre avant de passer à l’échelle ;)
Comme Scrum, LeSS propose une organisation simple qui laisse de la marge pour s’adapter à votre situation. Comme avec Scrum, pour en tirer le maximum de bénéfices de LeSS, il faut respecter les principes et les valeurs qui soutiennent le framework. Cela représente un challenge qui, je pense, mérite d’être relevé. Réussir à mettre en place LeSS permettra aux équipes de se concentrer sur livrer de la valeur aux clients/utilisateurs plutôt que suivre des processus dont elles ont oublié la raison d’être. On pourra appeler ça être agile si ça fait plaisir, mais est-ce le plus important ?
