« Portail LeSS

(ce qui a changé depuis la dernière version)

Les Règles LeSS constituent la définition du Framework LeSS. C’est ce que nous considérons comme étant indispensable. Pourquoi ? C’est ce que nous expliquons dans l’article Pourquoi LeSS ? (fr).

Les règles du framework LeSS

Le framwork LeSS s’applique à des produits mettant en jeu de 2 à “8” équipes.

Structure LeSS

  • Structurez l’organisation en utilisant des équipes réelles en tant que bloc de construction de base de l’organisation.
  • Chaque équipe est (1) auto-gérée, (2) pluridisciplinaires, (3) co-localisées et (4) pérenne.
  • La majorité des équipes sont des équipes features centrées sur le client.
  • Les Scrum Masters sont responsables de la bonne adoption de LeSS. Ils sont concentrés sur les Équipes, le Product Owner, l’organisation et le développement des pratiques. Un Scrum Master ne se concentre pas simplement sur une seule équipe mais sur le système global de l’organisation.
  • Un Scrum Master est un rôle à plein temps dédié.
  • Un Scrum Master peut servir de 1 à 3 équipes.
  • Dans LeSS, les managers sont optionnels, mais si les managers existent alors leur rôle va changer. Ils vont passer d’un management quotidien du travail sur le produit à l’amélioration de la capacité à livrer de la valeur de la part du système de développement du produit.
  • Le rôle du Manager est d’améliorer le système de développement du produit en pratiquant le Aller Voir (fr), en encourageant l’Arrêt & Correction, en privilégiant “l’expérience sur la conformité”.
  • Pour le groupe produit, établissez la structure LeSS complète “au démarrage” ; c’est absolument vital pour une adoption LeSS.
  • Pour l’organisation au sens large, au-delà du groupe produit, adoptez LeSS progressivement en utilisant le Aller Voir et créez une organisation où l’expérimentation et l’amélioration sont la norme.

Produit LeSS

  • Il y a un seul Product Owner et un seul Backlog Produit pour la totalité du produit déployable.
  • Le Product Owner ne doit pas travailler seul sur l’affinage du Backlog Produit ; il est soutenu par les diverses Équipes travaillant directement avec les clients/utilisateurs et les autres parties prenantes.
  • Toute la priorisation passe par le Product Owner, mais la clarification est autant que possible réalisée directement entre les Équipes et les clients/utilisateurs ainsi que les autres parties prenantes.
  • La définition du produit doit être aussi large et centrée sur les clients/utilisateurs finaux qu’il est possible de le faire. Au fil du temps, la définition du produit peut s’étendre. Des définitions très larges sont préférées.
  • Une seule Définition du Fini pour la globalité du produit commun à toutes les équipes.
  • Chaque équipe peut avoir une Définition du Fini plus forte en étendant la définition commune.
  • La perfection serait d’améliorer la Définition du Fini pour qu’on obtienne un produit déployable à chaque Sprint (ou en tout cas plus fréquemment).

Sprint LeSS

  • Il y a un seul Sprint au niveau du produit, et non un Sprint différent pour chaque Équipe. Chaque Équipe commence et finit le Sprint en même temps. Chaque Sprint donne un produit complètement intégré.
  • La Planification du Sprint se fait en deux parties : la Planification du Sprint (1) est commune à toutes les équipes alors que la Planification du Sprint (2) est généralement faite séparément par et pour chaque équipe. Réalisez la Planification de Sprint (2) multi-équipes dans un espace partagé pour rapprocher les sujets étroitement liés.
  • Le Product Owner et les Équipes ou les Représentants des équipes participent à la Planification du Sprint (1). Ensemble, ils sélectionnent provisoirement les éléments sur lesquels chaque équipe va travailler pendant ce Sprint. Les Équipes identifient les opportunités de travailler ensemble et les questions en suspens sont éclaircies.
  • Chaque Équipe a sont propre Backlog de Sprint.
  • La Planification du Sprint (2) permet aux Équipes de décider de la manière de réaliser les éléments sélectionnés. Cela implique généralement la conception et la création de leurs Backlogs de Sprint.
  • Chaque Équipe tient sa propre Mêlée Quotidienne.
  • La coordination transversale des équipes est décidée par les équipes. Préférez une coordination décentralisée et informelle plutôt qu’une coordination centralisée. Insistez sur le Parler Simplement et les réseaux informels en communiquant par le code, les réunions transversales, les mentors de composants techniques, les voyageurs et explorateurs des espaces ouverts.
  • L’affinage du Backlog Produit est effectué par l’équipe sur les éléments qui vont probablement être réalisés dans l’avenir. Réalisez un affinage global et/ou multi-équipes pour favoriser une compréhension commune et augmenter les chances d’opportunités de se coordonner sur des sujets étroitement reliés ou sur des besoins d’apprentissage large.
  • Il y a une seule Revue de Sprint sur le produit ; elle est commune à toutes les équipes. Assurez-vous que les parties prenantes adéquates viennent contribuer et communiquer les informations nécessaires à une inspection et adaptation efficaces.
  • Chaque Équipe a sa propre Rétrospective de Sprint.
  • Une Rétrospective Globale est effectuée après les Rétrospectives d’Équipe pour discuter des sujets transversaux et des problèmes systémiques, et définir des expériences d’amélioration. Y participent le Product Owner, les Scrum Masters, les Représentants de l’Équipe et les managers (s’il y en a).

Les règles du framework LeSS Huge

LeSS Huge s’applique à des produits mettant en jeu plus de 8 équipes. Evitez d’appliquer LeSS Huge pour un nombre plus faible de groupes produit, vous ne ferez qu’augmenter inutilement l’effort de communication et le nombre d’optimisations locales.

Toutes les règles LeSS s’appliquent à LeSS Huge, sauf indication contraire. Chaque Domaine d’Exigences est basée sur le framework LeSS de base.

Structure LeSS Huge

  • Les exigences client qui sont fortement liées au point de vue du client sont regroupées dans des Domaines d’Exigences.
  • Chaque Équipe est spécialisée sur un seul Domaine d’Exigences. L’équipe travaille sur un domaine pendant un temps assez long. Lorsqu’il y a plus de valeur dans les autres domaines, les équipes peuvent éventuellement changer le Domaine d’Exigences.
  • Chaque Domaine d’Exigences a son propre Area Product Owner (NdT : Product Owner Domaine).
  • Chaque Domaine d’Exigences a entre 4 et 8 équipes. Evitez de transgresser cet intervalle.
  • L’adoption de LeSS Huge, y compris les changements structuraux, est réalisée selon une approche incrémentale progressive.
  • Chaque jour, souvenez-vous que l’adoption de LeSS Huge prend des mois ou des années, faites usage d’une infinie patience et d’un sens de l’humour.

Produit LeSS Huge

  • Chaque Domaine d’Exigence dispose d’un Area Product Owner (NdT : Product Owner Domaine).
  • Un seul Product Owner (global) est responsable de la priorisation globale pour le produit et de décider quelle équipe travaillera sur quel Domaine. Il travaille au plus près des Area Product Owners.
  • Les Area Product Owners agissent comme des Product Owners vis-à-vis de leurs équipes.
  • Il y a un seul Backlog Produit ; chaque élément appartient à un et un seul Domaine d’Exigences.
  • Il y a un seul Backlog Produit de Domaine par Domaine d’Exigences. Ce backlog constitue conceptuellement une vue plus granulaire de l’unique Backlog Produit.

Sprint LeSS Huge

  • Il y a un seul Sprint au niveau du produit, donc pas de Sprint qui serait spécifique à chaque Domaine d’Exigences. Le Sprint se termine avec un unique produit globale intégré.
  • Le Product Owner et les Area Product Owners se synchronisent régulièrement. Avant chaque Planification de Sprint, ils s’assurent que les Équipes travaillent sur les éléments de plus grande valeur. Après la Revue de Sprint, ils encouragent les adaptations au niveau du produit.

Auteur : The LeSS Company B.V.
Source : LeSS Rules (April 2016) (2) - Large Scale Scrum (LeSS)


Traducteur : Fabrice Aimetti
Date de traduction : 19/12/2016


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.