LeSS (Large-Scale Scrum) est un framework d’agilité à l’échelle léger qui définit un minimum de règles.
Il mise sur l’expérimentation qui permet d’adapter au mieux les manières de travailler au contexte plutôt que d’imposer un cadre rigide et détaillé.
LeSS est tout simplement Scrum appliqué à plusieurs équipes qui travaillent ensemble sur un même produit. Il préserve les principes, les éléments et l’élégance de Scrum dans un contexte à l’échelle.
Bien qu’il ne soit pas le plus populaire des frameworks, sa simplicité lui confère un atout certain pour passer à l’échelle à moindre coût.
Qu’est ce que le framework LeSS ?
LeSS a été officialisé en tant que framework en 2015.
En réalité, ses fondements reposent sur des expérimentations et des pratiques mises en œuvre depuis 2005.
LeSS est bien documenté et continue à s’enrichir grâce aux retours d’expériences terrain. Sa dernière mise à jour date de novembre 2024.
Il existe 2 versions du framework :
- une version simple, appelée LeSS, adaptée aux dispositifs composés de 2 à 8 équipes.
- une version étendue, appelée LeSS Huge, pour des dispositifs composés de plus de 8 équipes.
Dans la suite de l’article, nous aborderons les principes du framework LeSS pour bien appréhender la philosophie d’approche, et mieux comprendre les pratiques sous-jacentes.
Ensuite, nous insisterons sur les 7 éléments clefs importants à maîtriser pour garantir le succès de la mise en place de LeSS.
Enfin, nous verrons dans quel contexte LeSS peut être pertinent et dans quels cas il n’est pas recommandé.
Les 8 principes de LeSS
Voici un tour d’horizon des principes les plus importants du framework LeSS.
1) Large-Scale Scrum est du Scrum
LeSS est avant tout du Scrum et fournit simplement un ensemble de règles additionnelles et d’astuces pratiques qui ont fait leurs preuves sur le terrain dans des contextes à plusieurs équipes.
Contrairement aux autres frameworks d’agilité à l’échelle, LeSS ne vient pas ajouter une surcouche à des équipes Scrum existantes pour les faire travailler ensemble.
2) Faire plus avec moins
LeSS cherche à supprimer la complexité dans les organisations en résolvant les problèmes d’une manière simple et différente.
Il est résolument contre l’ajout de rôles, de livrables et d’évènements agiles.
La transition vers l’agilité à l’échelle se fait donc à moindre coût.
Par contre, elle nécessite que chacun revisite son rôle et opère un dépassement de fonction pour garantir le succès du collectif.
3) Focus sur le produit complet
Garder chaque équipe focus sur le produit complet plutôt que sur sa partie est un vrai challenge lors du passage à l’échelle.
Une équipe qui développe une partie du produit ne peut pas considérer qu’elle a terminé son travail tant que cette partie n’est pas intégrée au produit complet.
LeSS, notamment à travers ses rôles, renforce le sentiment d’appartenance de chacun à un ensemble d’équipes, au service d’un objectif commun.
4) Le client au centre de la démarche
Dans un dispositif agile à l’échelle, il est courant de rencontrer des personnes qui ne connaissent pas le client, qui ne savent pas comment le client va utiliser le produit et qui ne savent pas, au final, pourquoi elles développent telle ou telle fonctionnalité.
Pour rapprocher les développeurs du client et des utilisateurs finaux, LeSS préconise :
- une organisation en « Feature Teams » (des équipes capables de créer de la valeur directe pour le client).
- un Product Owner qui connecte le client aux équipes, plutôt que de jouer un rôle d’intermédiaire.
- un partenariat entre le client et les équipes pour détailler le besoin.
- un Product Backlog unique et partagé par toutes les équipes pour faciliter la compréhension globale du système.
5) Amélioration continue jusqu’à la perfection
L’expérimentation et l’amélioration sont au cœur de LeSS et ne s’arrêtent jamais. Vous n’aurez donc jamais fini d’implémenter LeSS.
Il y aura toujours quelque chose à perfectionner.
LeSS est basé sur le Lean Thinking qui préconise d’aller sur le terrain pour mieux prendre conscience des difficultés rencontrées par les équipes, aider à éliminer les obstacles, chasser les gaspillages et ainsi améliorer le flux.
6) Pensée systémique
Une solution complexe développée par plusieurs équipes nécessite plusieurs composants pour apporter de la valeur aux utilisateurs finaux.
Le secret de la réussite réside dans la coopération entre tous ces composants.
L’optimisation d’un composant ne permet pas d’optimiser le système dans son ensemble.
Adopter une pensée systémique consiste à avoir un haut niveau de compréhension de la solution, de son comportement et de son architecture.
Une solution ne peut évoluer plus vite que son point d’intégration le plus lent (si un des composants est livré en production 2 fois par an, alors la solution n’évoluera que 2 fois par an également).
7) Processus empirique
Les règles de LeSS ont pour objectif de maintenir la transparence, l’inspection et l’adaptation de manière à ce que les équipes améliorent elles-mêmes leurs manières de travailler.
Pour cette raison, LeSS met en avant le caractère empirique du processus dans la mesure où les règles sont volontairement incomplètes afin que les équipes les adaptent à leur contexte d’itération en itération.
8) Théorie des files d’attente
Nos organisations en silos génèrent un certain nombre de files d’attentes qui ont un impact sur la livraison de valeur pour nos clients.
La loi de Little sur les files d’attente nous apprend qu’un délai de traitement plus rapide diminue l’attente et que des files d’attente plus courtes diminuent également l’attente.
Il est donc important de contrôler la longueur des files d’attente dans notre système. Concrètement, LeSS préconise de limiter les travaux en cours et de favoriser les petits items.
Un Product Backlog est un bon exemple de file d’attente.
Exemple :
Si un dispositif réalise 20 items par sprint de 3 semaines et que le Product Backlog contient 100 items pour lesquels un engagement a déjà été pris, il faudra attendre (100 / 20) x 3 = 15 semaines pour que le 101ème item soit réalisé.
Les 7 leviers du framework pour appliquer Scrum à l’échelle
Voici les 7 leviers du framework :
1) Des « Feature Teams » plutôt que des « Component Teams »
Les équipes sont organisées autour de la valeur.
Autrement dit, chaque équipe est une « Feature Team » capable de délivrer de la valeur, indépendamment des autres équipes.
A l’inverse, une « Component Team » est incapable de délivrer de la valeur de manière autonome.
A gauche, la réalisation d’un item du Product Backlog nécessite la collaboration de plusieurs équipes car chaque équipe ne maîtrise que son composant. Cela introduit des dépendances et donc des délais.
A droite, chaque item est pris en charge par une équipe unique. Cela nécessite une maîtrise par chaque équipe de plusieurs composants et donc éventuellement plusieurs langages de programmation.
En pratique, nos dispositifs contiennent des « Feature Teams » et des « Component Teams » car il est difficile de constituer des équipes qui maîtrisent l’ensemble des technologies embarquées dans les différents composants.
Néanmoins, l’intention est bien d’avoir le maximum de « Feature Teams ».
LeSS préconise des équipes pluridisciplinaires, ce qui permet aux équipiers de s’entraider sur chaque item du Backog et d’être focus sur la livraison de valeur pour le client.
Les équipes sont colocalisées pour faciliter la collaboration et pérennes pour assurer la prédictibilité.
Toutes ces caractéristiques sont indispensables pour construire des équipes hautement performantes.
2) Un Scrum Master multi-équipes
Un Scrum Master est dédié à 100% à son rôle de Scrum Master. Il est Scrum Master pour 1 à 3 équipes maximum.
Les Scrum Masters sont responsables de l’adoption de LeSS. Ils ont 4 centres d’attention :
- les équipes : Lorsqu’une première équipe a atteint un bon niveau de maturité, le Scrum Master peut se concentrer sur la seconde équipe, puis sur la troisième équipe. Être Scrum Master de plusieurs équipes permet d’avoir une vision plus large de l’organisation toute entière.
- le Product Owner : En plus de coacher le Product Owner dans son rôle, le Scrum Master doit l’aider à se rapprocher du client et des utilisateurs finaux pour capter leurs feedbacks et valider l’orientation du produit.
- l’organisation : L’attention initiale sur l’organisation est forte car l’adoption de LeSS nécessite un changement de structure initial et une organisation basée sur des « Feature Teams ». Cette attention revient plus tard pour améliorer l’organisation en fonction des résultats produits par les équipes.
- les pratiques de développement : A l’échelle de plusieurs équipes, le volume de code augmente rapidement. La qualité de code et les pratiques de développement sont donc primordiales pour garder un code propre, maintenable et ouvert aux modifications. Sensible aux pratiques de développement, le Scrum Master sensibilise les différentes équipes et vérifie régulièrement la qualité du produit.
Le graphe ci-dessus montre les niveaux d’attention du Scrum Master en fonction du temps.
L’attention portée initialement au Product Owner et ses équipes diminue peu à peu au profit de l’organisation et des pratiques de développement.
3) Un Product Owner unique focus sur la priorisation
Contrairement à la plupart des frameworks d’agilité à l’échelle, le rôle de Product Owner est porté par une seule personne, ce qui simplifie l’organisation et permet au dispositif d’aller dans une seule et même direction.
Le Product Backlog est lui aussi unique pour l’ensemble de la solution.
Dans LeSS, le Product Owner dispose de temps pour porter son attention sur le client et ses priorités. Il est focus sur l’ordonnancement des items du Product Backlog.
Le Product Owner ne travaille pas seul sur l’affinage du Product Backlog.
Il collabore avec les équipes pour la clarification des items et encourage fortement les équipes à avoir une conversation directe avec le client et les utilisateurs.
Cela permet d’éviter une perte d’informations, de rester focus sur les problèmes réels et d’améliorer l’empathie entre client et développeurs.
Le Product Owner travaille en étroite collaboration avec 4 partenaires clefs :
- les équipes : Les équipes doivent savoir si ce qu’elles ont construit répond au besoin et ce qu’il faut construire ensuite. Le Product Owner doit connaître les besoins des équipes et savoir comment il peut les aider.
- les clients : Le Product Owner doit comprendre les objectifs et les problèmes des clients.
- le Top Management : Le Product Owner a la responsabilité du succès du produit. Il doit donner de la visibilité à son sponsor sur l’avancement de son produit. Il s’appuie sur le sponsor pour améliorer l’organisation.
- les Scrum Masters : Ils doivent comprendre les obstacles rencontrés par le Product Owner pour pouvoir l’aider. Ils coachent le Product Owner et lui donnent des feedbacks pour qu’il s’améliore.
4) Une « Definition of Done » commune
La « Definition of Done » est un accord entre les équipes et le Product Owner sur les activités qui doivent être effectuées pendant le sprint pour considérer qu’un item est terminé.
Elle est unique et commune à l’ensemble des équipes.
Une équipe peut néanmoins établir une « Definition of Done » étendue, et donc plus « contraignante » que la définition commune.
Dans la « Definition of Done » présentée ci-dessus, les éléments soulignés sont communs à toutes les équipes.
Les autres éléments sont ajoutés à la « Definition of Done » commune par certaines équipes.
5) Des évènements agiles multi-équipes
Les équipes sont cadencées et synchronisées (elles démarrent et terminent toutes leurs sprints au même moment).
5.1) Sprint Planning
Le Sprint Planning se décompose en 2 parties :
- Une 1ère partie commune à l’ensemble des équipes avec le Product Owner et des représentants de chaque équipe pour distribuer les items prioritaires du Product Backlog aux équipes et discuter des besoins de coordination pendant le sprint.
- Une 2ème partie plus traditionnelle où chaque équipe détermine comment elle va réaliser les items de son Sprint Backlog.
5.2) Daily Scrum
Chaque équipe a son propre Daily Scrum.
Les équipes décident comment se coordonner en privilégiant la décentralisation et la coordination informelle plutôt que la coordination centralisée.
Par exemple, une équipe peut accueillir ponctuellement dans son Daily Scrum des représentants des autres équipes pour favoriser la coordination entre équipes et mieux traiter les dépendances.
Une autre technique de coordination entre équipes, non recommandée par LeSS, est le Scrum of Scrums.
Plusieurs fois par semaine, les développeurs de plusieurs équipes qui travaillent sur des sujets communs se réunissent pour coordonner leurs travaux.
5.3) Product Backlog Refinement
Le Product Backlog Refinement (PBR) consiste à échanger sur les futurs items et à les affiner pour être embarqués dans le sprint suivant.
L’affinage du Product Backlog est fait de préférence par plusieurs équipes.
Il représente une opportunité de collaboration entre les équipes et favorise le partage d’informations.
Le temps consacré au Product Backlog Refinement ne devrait pas excéder 10% de la durée des sprints.
C’est un compromis qui permet à la fois de bien préparer le sprint suivant tout en maintenant une bonne productivité pendant le sprint en cours.
5.4) Sprint Review & Rétrospectives
La Sprint Review est unique et commune à l’ensemble des équipes. Elle rassemble l’ensemble des membres du dispositif.
Il faut s’assurer que les parties prenantes et les sponsors sont bien présents pour donner les informations permettant l’inspection et l’adaptation.
Chaque équipe réalise sa propre rétrospective. Ensuite, une rétrospective commune permet de discuter des problématiques inter-équipes et des obstacles majeurs rencontrés par l’organisation.
Le Product Owner est présent ainsi que les Scrum Masters et des représentants des équipes.
Pour garantir l’efficacité de la rétrospective commune, les questions suivantes peuvent être posées :
- Est-ce que les équipes collaborent bien ensemble ?
- Est-ce qu’il y a quelque chose qu’une équipe devrait partager aux autres ?
- Est-ce que les équipes ont des discussions directes avec le client et les utilisateurs finaux ?
- Est-ce qu’il y a des obstacles qui freinent l’ensemble des équipes ? comment les addresser ?
- Est-ce que le Product Owner est à l’aise dans son rôle ?
- Comment sont les relations entre le Product Owner et ses 4 partenaires clefs ?
- Est-ce que les communautés de pratiques fonctionnent bien ?
6) Des communautés de pratiques pour diffuser la connaissance
Une communauté de pratique est un groupe de personnes qui ont un sujet d’intérêt commun et qui échangent leurs connaissances et leurs expertises.
LeSS encourage fortement les communautés de pratiques, car elles permettent l’apprentissage continu et la diffusion rapide de bonnes pratiques. La participation de chacun est basée sur le volontariat.
Les communautés de pratiques n’impactent pas la structure organisationnelle en place.
Elles se contentent de connecter des personnes situées n’importe où dans la structure hiérarchique.
Les organisations ne peuvent pas décréter la création des communautés de pratiques mais peuvent les encourager et les faciliter.
Une communauté nécessite un coordinateur passionné par le sujet de sa communauté.
7) LeSS Huge pour aller au-delà de 8 équipes
LeSS HUGE est une extension de LeSS pour gérer des dispositifs composés de plus de 8 équipes.
Conceptuellement, LeSS HUGE parallélise plusieurs dispositifs LeSS.
Chaque dispositif, composé de 2 à 8 équipes, adresse une « Area », c’est-à-dire un périmètre fonctionnel spécifique.
Comme dans le framework LeSS, LeSS Huge préconise un Product Owner unique, un Product Backlog unique, une Definition of Done unique et un produit unique.
Chaque item du Product Backlog est associé à une catégorie de besoin et une seule.
Cette affectation permet de générer différentes vues du Product Backlog, appelées « Area Backlog ».
Chaque « Area Backlog » est priorisé par un « Area Product Owner » spécialisé dans cette catégorie de besoin.
La raison principale de l’introduction des « Area Product Backlog » et des « Area Product Owners » est de pallier à la surcharge que subirait un Product Owner s’il était seul pour gérer un périmètre aussi large.
L’adoption de LeSS HUGE est difficile. Elle doit être opérée de manière graduelle, Area par Area.
Dans quel contexte utiliser LeSS ?
La mise en place d’un framework d’agilité à l’échelle a un coût non négligeable. Il est donc important de faire le bon choix de framework.
1) Quand est ce que LeSS est recommandé ?
LeSS est tout à fait pertinent si votre contexte possède les caractéristiques suivantes :
Votre dispositif ne comporte pas plus de 8 équipes :
Jusqu’à 8 équipes, les principes et pratiques de LeSS vont permettre à vos équipes de collaborer efficacement.
Vos équipes ont des dépendances en nombre raisonnable :
Si votre dispositif est constitué d’une majorité de « Feature Teams », vos dépendances seront plutôt limitées et les évènements agiles multi-équipes de LeSS vous permettront de gérer correctement ces dépendances.
Vos équipes sont matures en agilité :
Le Product Owner et le Scrum Master sont multi-équipes.
Par ailleurs, les équipes sont particulièrement investies lors de l’affinage du Product Backlog.
Autrement dit, il est demandé à chacun de faire plus qu’en Scrum traditionnel.
Par conséquent, il est préférable que vos équipes maîtrisent déjà bien l’agilité.
Vous souhaitez limiter le coût lié à la mise en place du framework :
LeSS est un framework léger qui vous permet de monter en compétences sereinement sur l’agilité à l’échelle sans surcouche méthodologique ni surcoût associé (pas de rôles, ni livrables, ni évènements agiles supplémentaires).
Attention toutefois à l’impact initial sur l’organisation lors de la composition de vos « Feature Teams ».
2) Quand est ce qu'il n'est pas recommandé ?
A l’inverse, LeSS n’est pas recommandé si :
Votre dispositif comporte plus de 8 équipes :
Notre recommandation :
LeSS Huge peut être une bonne alternative à LeSS à condition que votre découpage en Area respecte le prérequis suivant : pas de dépendances entre équipes d’Area différentes.
LeSS Huge n’a pas prévu de gérer des dépendances entre Area.
Vos équipes sont très dépendantes les unes des autres :
Notre recommandation :
Tournez-vous vers un autre framework qui propose des pratiques dédiées pour faciliter la gestion des dépendances.
Le framework SAFe en est un bon exemple mais n’oubliez pas de prendre en compte le coût élevé de son implémentation avant de l’adopter.
Vos équipes débutent en agilité :
Notre recommandation :
Prenez le temps de faire monter en compétences vos équipes agiles avant de passer à l’échelle.
Pour faciliter l’adoption de LeSS, commencez par 2 équipes puis ajoutez des nouvelles équipes, itération après itération.
Conclusion
Le framework LeSS mise sur la simplicité pour sa stratégie de passage à l’échelle. Pas besoin d’ajouter de nouveaux rôles et de prendre le risque d’éparpiller les responsabilités.
Pas besoin non plus de nouveaux évènements agiles. Il suffit d’adapter les évènements existants au mode multi-équipes.
Plutôt que de proposer une structure lourde pour gérer des équipes fortement dépendantes, LeSS préfère impacter dès le départ l’organisation en construisant des « Feature Teams » peu dépendantes et faciliter ainsi le passage à l’échelle.
Au final, l’approche est très pertinente mais elle nécessite une forte maturité agile des équipes car chacun doit aller au-delà de son rôle Scrum pour participer à l’alignement des équipes et favoriser la collaboration.
