Carte d’identité

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.

Petit rappel sur Scrum

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 la documentation officielle.

LeSS c’est Scrum

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.

À quoi ça ressemble ?

 

À 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”.

Ce qui diffère de Scrum

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 :

  1. le PO et les représentants (ie. personnes pertinentes) de chaque équipe déterminent les fonctionnalités à réaliser pendant le Sprint et se les répartissent ;
  2. chaque équipe décide de son côté comment elle effectuera le travail nécessaire pour achever l’incrément.

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 :

  1. chaque équipe de développement avec un focus sur son fonctionnement interne ;
  2. le produit pour adresser les problèmes liés à l’organisation ; y participent le PO, les Scrum masters et les représentants (ie. personnes pertinentes) de chaque équipe de développement

Communication/Synchronisation

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.

La partie immergée de l’iceberg

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 :

  1. Large Scale Scrum est Scrum : facile à comprendre, difficile à maîtriser et dont la mise en œuvre risque de révéler les problèmes organisationnels ;
  2. transparence : principe édicté par Scrum comme la base de l’amélioration continue ;
  3. “more with less” : être plus efficace avec moins de complexité (procédures, rôles, bureaucratie, etc) ;
  4. le produit est un tout (whole product focus) : tant que ce n’est pas intégré au produit ça n’a aucune valeur pour le client/utilisateur ;
  5. centré sur le client/utilisateur final : les processus et les personnes doivent apporter de la valeur au client de la manière la plus directe possible ;
  6. amélioration continue jusqu’à la perfection : continuer de s’améliorer même si le système en place est satisfaisant ;
  7. Lean : embrasser les principes du Lean ;
  8. pensée systémique (Systems thinking) : travailler sur le système dans sa globalité et éviter les optimisations locales ;
  9. processus de contrôle empirique : c’est l’essence de Scrum, tester, analyser et adapter de manière itérative ;
  10. la théorie des files : supprimer les files dans l’organisation et les processus séquentiels pour éviter les goulots d’étranglement et les ralentissements.

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 :

  • l’adoption pour que les équipes s’approprient la nouvelle organisation ;
  • l’excellence technique pour que les équipes puissent livrer fréquemment un logiciel de qualité ;
  • la structure des équipes pour qu’elles partagent au mieux les informations utiles sans être ralenties par les interactions superflues ;
  • le management pour que celui-ci passe de la direction à l’accompagnement des équipes.

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’où le modèle peut-il tenir ?

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.

Points d’attention

La charge du PO

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 …

More with LeSS

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.

Passer à l’échelle c’est transformer

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.

Commencer petit

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 :

  • l’équipe de développement est-elle réellement en capacité de réaliser l’incrément ? Sans dépendance extérieure qui la ralentisse ?
  • l’équipe de développement est-elle réellement habilitée à s’auto-organiser ?
  • le PO a-t’il le dernier mot quant à la priorisation du backlog produit ?
  • est-ce que la mission principale du PO est bien d’être PO ? L’organisation lui accorde-t’elle bien le temps et l’aide nécessaire pour accomplir sa mission ?  

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 😉

Conclusion

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 ?