Le LeSS est un framework de développement de produit qui vient étendre la mise en place du Scrum sur plusieurs équipes alors que ce dernier ne se concentre que sur une équipe seule. LeSS est l’acronyme de Large-Scale Scrum.
L’idée de ce framework n’est en aucun cas de dénaturer le Scrum mais propose au contraire des règles d’organisation de plusieurs équipes Scrum autour d’un même produit.
Bas Vodde et Craig Larman ont créé ce framework en profitant de leurs différentes expériences où ils ont tentés de mettre en place une gestion multi-équipe Scrum dans le monde des télécom et de l’industrie. Ils ont proposé une version complète de LeSS en 2013.
Nous avions déjà vu une autre méthode qui permet de faire travailler plusieurs équipes Scrum ensemble que vous pouvez consulter : Scrum of Scrum : Coordonner plusieurs équipes
Vous pouvez regarder la vidéo de la minute agile sur le sujet :
Version anglaise: What is LeSS agile framework?
Qu’est-ce qui est différent en LeSS ?
Le LeSS propose d’avoir un seul Product Owner pour l’ensemble des équipes. Voici les différences majeures du LeSS par rapport à plusieurs équipes Scrum qui travaillent totalement indépendamment.
La Sprint Planning 1 : Le Product Owner fera une Sprint Planning avec l’ensemble des équipes du LeSS. Cependant, chaque équipe géra son propre découpage de tâches techniques de ses user-stories. Les équipes pourront profiter de cette cérémonie pour discuter ensemble du projet.
Si il y a plus de 2 équipes, il faudra amener 1 ou 2 ambassadeurs à cette Sprint Planning par équipe (le Scrum Master ne pouvant pas en faire parti). En LeSS, ce sont les équipes qui se répartissent les user-stories entre elles.
C’est à ce moment là que les équipes définiront si elles ont besoin ou non de faire un Sprint Planning 2 en plusieurs équipes (si ils doivent travailler ensemble sur des fonctionnalités)
La Sprint Planning 2 : Quand la Sprint Planning 1 sera terminé, les équipes feront la Sprint Planning 2. Les équipes qui ont décidé de travailler ensemble sur des fonctionnalités la feront ensemble et les autres feront une Sprint Planning classique.
La Daily Sprint : Si le déroulement de la Daily est le même, le LeSS propose pour les équipes qui travaillent sur les mêmes fonctionnalités (celles qui ont fait la Sprint Planning 2 ensemble) d’envoyer un observateur à la Daily d’une autre équipe.
La Sprint Review : Le Product Owner va rassembler les équipes, les clients et les managers pour présenter le travail réalisé par les équipes ; l’ensemble finira par discuter sur le produit et ses potentielles évolutions.
La Sprint Retrospective : La cérémonie en LeSS est identique à celle que connait le Scrum classique à l’exception que le Product Owner ne s’y présente pas.
La Sprint Overall Retrospective : Cette cérémonie en LeSS qui n’existe pas en Scrum se fait à la suite de la Retrospective entre le Product Owner, les Scrum Master et les Managers.
Voici les sujets qui y seront évoqués :
- Est-ce que les équipes travaillent bien entre elles ?
- Est-ce que les pratiques du framework sont bien appliquées ?
- Est-ce que quelque chose peut-être partagé par une équipe ?
- Est-ce que les équipes ont appris ensemble ?
- Est-ce que les équipes sont proches des clients ?
- Y a t’il des soucis d’organisation systémique qui viennent perturber l’organisation des équipes ?
- Est-ce que le Product Owner arrive à tout gérer sans soucis ?
- Est-ce que le Product Owner est en bon contact avec les Scrum Master, les clients, les équipes et les managers ?
Il est possible de faire cette cérémonie LeSS en début de l’itération suivante si il n’est pas possible de la faire après la Sprint Retrospective ; la faire juste après les Sprint Planning peut-être une solution qui permet aux équipes techniques de ne pas avoir un trou entre la Retrospective et la Sprint Planning.
La Overall Product Backlog Refinement : Cette réunion qui n’existe pas en Scrum permet de faire un premier affinage des user-stories qui doivent passer lors du Sprint suivant. La réunion réunit le Product Owner et deux représentants par équipe.
C’est à ce moment là que le Product Owner et les représentants vont décider de la répartition des user-stories. Les représentants feront une estimation rapide des user-stories pour aider à la répartition et parleront ensemble des demandes si elles ne sont pas comprises.
L’estimation pourra permettre aussi de découper la user-story en plusieurs stories.
La Product Backlog Refinement : Cette réunion qui est devenue un impératif dans le Scrum actualisé (par le scrum guide) permet de faire un affinage complet du Backlog.
Allez lire l’article qui explique le contenu de cette cérémonie Scrum : La Product Backlog Refinement.
Le LeSS va proposer de rassembler les équipes qui travaillent sur les mêmes fonctionnalités de faire cette cérémonie ensemble.
Conclusion LeSS
Le Framework LeSS est un des framework utilisés pour faire travailler les équipes Scrum entre elles. L’image ci-dessous permet de conclure sur le déroulement de ce framework.
Pensez-vous pouvoir être capable de mettre un tel framework comme LeSS dans votre organisation ?
Bonjour
C est tres intéressant et demande un POC :d
Merci
Je me tâte à mettre ce framework en place chez un de mes clients. Si je décide de le faire, je ferais un retour d’expérience dessus 🙂
Hello,
Je sors d’un projet Big Data; Et intuitivement, sans savoir que LeSS existait, j’ai adapté la méthodo SCRUM de base au contexte du projet. Mais sans trop le dire autour de moi car je croyais faire des Scrumbuts. De même pour le passage de SCRUM à SCRUMBAN. (Après avoir allongé la durée des sprints)
Sur notre projet le clés du succès ont été :
– une très bonne coordination entre les équipes et une autonomisation des devs en les encourageants à beaucoup plus échanger en dehors de toute cérémonie
– une très forte implication du PO et des sponsors/key users pour valider le modèle de données au fur et à mesure des incréments
– une vision produit largement comprise et partagée par tout le monde
Je pourrai développer d’avantage si besoin car la réussite d’un projet Big Data dans l’agilité va bien au-delà de la mise en place d’un framework.
A+
On peut sans soucis imaginer un article « retour d’expérience » sur le sujet 🙂 Ca devrait vraiment intéresser la communauté.
N’hésite pas à me contacter si l’idée te plait 🙂
On est dans une configuration du scrum de scrum, le mieux c’est un PO par équipe, et un PO ou CPO vour PM pour orchestrer 🙂