BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Q&R avec Bas Vodde sur le Framework LeSS : Principes, Pratiques et Concepts fondamentaux

Q&R avec Bas Vodde sur le Framework LeSS : Principes, Pratiques et Concepts fondamentaux

Favoris

Bas Vodde et Craig Larman ont élaboré et introduit Large-Scale Scrum (LeSS) - Scrum à grande échelle - le modèle de mise à l’échelle.

Large-Scale Scrum (LeSS) est du Scrum appliqué à de nombreuses équipes travaillant ensemble sur un produit.

LeSS est plus qu’un set de principes et d’expérimentations. Il offre également une structure avec des règles. Les Règles de LeSS définissent ce qu’est LeSS (et ce qui ne l’est pas) et donnent un cadre concret pour l’appliquer. Au sein du cadre LeSS, les groupes de produit peuvent appliquer les expérimentations et découvrir ce qui fonctionne le mieux pour eux à un certain moment.

LeSS fournit deux versions de cadre Scrum à grande échelle :

  • LeSS : Jusqu’à huit équipes (de huit personnes chacune)
  • LeSS Huge : Jusqu’à quelques milliers de personnes sur un produit

InfoQ a interviewé Bas et discuté de LeSS et LeSS Huge.

 

InfoQ : Pourrais-tu s’il te plaît introduire LeSS à nos lecteurs ?

Bas : LeSS est un cadre de développement produit pour construire des produits avec au moins deux équipes. Ce cadre est basé sur les règles de Scrum, mais les étend pour créer un Scrum multi-équipes.

Les règles étendues comprennent :

  1. Une explication sur comment réaliser les événements Scrum avec plusieurs équipes.
  2. Des ajouts principalement liés à la structure du groupe de développement produit (“groupe de développement produit” est le terme que l’on utilise pour l’organisation ou le département qui construit le produit).

A côté des règles, nous avons défini dix principes de LeSS.

Les principes viennent sous trois saveurs :

  1. Les principes basés sur Scrum, comme la transparence ou le contrôle de processus empirique.
  2. Les méta-principes, comme les pensées Lean et Systémique.
  3. Les principes spécifiques à Less, comme la focalisation sur l’ensemble du produit ou l’approche centrée sur le client.

Less a également environ une cinquantaine de guides qui sont principalement des explications sur la manière dont le cadre LeSS peut être adopté dans les organisations et à quels changements vous pouvez vous attendre.

La dernière partie de LeSS correspond aux expérimentations LeSS, environ 600 idées à essayer ou à éviter lors d’une mise à l’échelle d’un développement agile.

InfoQ : Quel est le concept fondamental de LeSS ?

Bas : Fondamentalement, LeSS essaie de rester fidèle au Manifeste Agile et à Scrum, tout en déterminant comment travailler avec plus d’équipes sur le même produit.

A la même époque que le Manifeste Agile, Jim Highsmith, co-auteur du Manifeste Agile, parlait de “méthodologie guère suffisante”, ce qui conviendrait bien à LeSS. Cela vient de la prise de conscience que pour adopter l’amélioration continue impliquant tout le monde dans l’organisation, vous avez besoin que les équipes s’approprient leur processus. Cela veut dire abandonner les concepts de management scientifique qui séparent le planning de l’exécution du travail, mais aussi d’abandonner le management de projet rigide, qui est une évolution du management scientifique.

De plus, nous voulons gérer les produits comme des produits, et non comme des projets. Cela conduit à des équipes permanentes à long terme, maîtrisant leur travail et s’améliorant de manière continue tout le temps. L’effet d’avoir beaucoup de rôles, d'artefacts, de processus, et de couches est que l’équipe ne s’approprie pas son processus, c'est le processus qui s’approprie les équipes… Avec LeSS, nous ne voulons pas cela. A la place, nous souhaitons avoir moins de rôles, moins d’artefacts, et moins de processus. Moins de ceux-ci signifie plus d’appropriation, de créativité, d’amélioration et plus de finalité. Nous appelons ce principe Plus avec Moins (More with LeSS - NdT).

InfoQ : Quel est l’objectif d’incorporer la pensée Lean et Systémique dans le cadre LeSS comme principes ?

Bas : Les pensées Lean et Systémique nous ont toutes les deux énormément influencés Craig et moi. Nous voulons que toutes les personnes impliquées dans LeSS soient au courant de ces deux outils de réflexion car ils clarifient comment LeSS fonctionne et vous aide à résoudre des problèmes concrets dans votre développement.

Historiquement, les pensées Lean et Systémique faisaient partie des “outils de réflexion” que nous décrivions dans notre premier livre “Scaling Lean & Agile Development”. Lors de la réflexion sur les principes LeSS, cela nous a traversé l’esprit d’en faire de véritables principes, tels que “optimiser le tout” et “respecter les personnes”, mais nous avons décidé de ne pas le faire et de les garder telles quelles et de juste les appeler principes (vu qu’elles sont plutôt des cadres de réflexion que des principes).

Pour les personnes intéressées à en apprendre plus sur ces ‘principes’, laissez-moi recommander quelques sources que j’ai trouvées précieuses. Pour la pensée Lean, il y a beaucoup de choses et tout n’est pas bon. Je recommande généralement de chercher des choses qui restent proches de l’origine Toyota, plutôt que celles qui en sont des interprétations. En général, vous ne vous tromperez pas avec le travail de Liker et Ohno. Je suis particulièrement friand du petit livre d’Ohno, le créateur du Processus de Production Toyota, qui s’intitule “Workplace Management”. Pour la pensée Systémique, le travail de Peter Senge ne vieillit pas. Pour d’autres applications de la pensée systémique, regardez le travail de John Seddon ou de Gerald Weinberg, qui ont écrit depuis toujours au sujet de l’application de la pensée systémique au développement logiciel.

InfoQ : Le cadre LeSS a deux versions - LeSS et LeSS huge. Quelle est la différence entre les deux ?

Bas : Correct. Le LeSS ou le cadre basique LeSS est pour un nombre de 2 à 8 équipes, et le cadre LeSS Huge est pour plus de 8 équipes. LeSS Huge est une extension de LeSS a des groupes de produit plus larges. LeSS contient 2 pages de règles et LeSS Huge en est une page additionnelle.

La raison pour ces 2 cadres est qu’après environ 8 équipes, vous aurez besoin de techniques de mise à l’échelle additionnelle qui aident à mettre à l’échelle le product owner et le product backlog. Cependant, ces techniques additionnelles ne devraient pas être utiles lorsque vous n’êtes pas à environ 8 équipes. Elles compliqueraient juste votre développement. Elles ont en réalité un impact négatif si elles sont utilisées sur les petites adoptions de LeSS. Pour être clair, nous avons décidé de partager le cadre en LeSS et LeSS Huge. Vous pouvez voir LeSS Huge comme de multiples LeSS empilés les uns sur les autres.

InfoQ : “LeSS concerne la mise à l’échelle de Scrum lui-même pour atteindre le détartrage organisationnel”. Comment LeSS aide-t-il au détartrage ?

Bas : Lorsque l’on adopte LeSS, cela va affecter la structure de votre organisation. Ce qui arrive souvent est que les problèmes organisationnels qui étaient traditionnellement résolus de manière complexe, sont résolus plus facilement dans LeSS. Avoir de petits lots de logiciel opérationnel sprint par sprint permet d’éliminer la complexité organisationnelle créée pour s’adapter au manque de transparence du développement traditionnel. Rien ne vaut quelques exemples.

Traditionnellement, les organisations gèrent leur travail en utilisant des projets. Un projet, d’une perspective Agile/Lean est une manière de gérer de larges lots de besoins vers une release. Lorsque l’on se focalise sur les produits et sur la livraison continue de valeur aux utilisateurs, la gestion projet du travail devient largement obsolète. Il est bien plus facile de gérer de petits lots de travail via un product backlog pour la vie du produit. Cela permet aussi d’investir (budget) dans le produit en se basant sur de la valeur client prévue et réalisée. Ainsi, de bonnes organisations LeSS ont détartré l’organisation en enlevant les projets et le management de projet, et en résolvant le problème organisationnel de la gestion du travail de manière différente.

Pour aller plus loin, les grandes organisations ont souvent des portefeuilles projets de différents projets (à l’intérieur d’un même grand produit). Si l’on considère un projet comme un gros lot d’exigences, alors la gestion de portefeuille projet est un gros lot de priorisation d’exigences. Ce n’est pas quelque chose que l’on encourage. Donc, au lieu de faire cela, nous considérons la définition du produit comme extensible et la préférons large pour que le product backlog joue le même rôle qu’un portefeuille projet, mais avec simplicité et une fine granularité de priorisation.

InfoQ : LeSS met également l’accent sur l’excellence technique. Quelle est son importance et quels en sont les bénéfices ?

Bas : Sans elle, il est probable que votre développement échoue.

Craig et moi utilisons l’expression “l’agilité organisationnelle est toujours contrainte par l’agilité technique” pour exprimer cela. Vous ne pouvez pas être flexible en tant que société sans être flexible dans votre base de code. En d’autres termes, si votre code est un fouillis, vous êtes lent.

Nous sommes de l’opinion que très peu d’organisations ont conscience de l’importance des pratiques techniques. La plupart n’en reconnaissent le mérite que pour la forme. Lorsque l’on plonge dans les bases de codes (ce qui est l’une des choses que l’on aime le plus faire), c’est incroyable ce que l’on peut trouver même dans les plus “agiles” des services de développement. Quand le code est en désordre, avec beaucoup de duplications, manquant d’abstractions de domaine et sans tests automatisés, alors faire des changements est fastidieux. Et peu importe comment vous organiserez votre développement, vous serez inflexibles.

InfoQ : Voudrais-tu nous parler de votre livre à venir ?

Bas : Et bien, j’aimerais qu’il ne soit plus à venir :) Nous pensions à l’origine que ce livre serait un petit projet, mais en pratique il s’est transformé en un projet monstre. Quoi qu’il en soit, le livre s’intitule “Large-Scale Scrum: More with LeSS”, il décrit les règles LeSS et quelques guides LeSS qui aident dans l’adoption. Il devrait être plus facile à lire et légèrement plus prescriptif que les deux précédents livres. Il aurait déjà dû être publié, mais de manière réaliste il sera disponible début 2016.

Pour partager un peu plus à ce sujet, le livre est structuré en trois parties : 1) Structure, 2) Produit, 3) Sprint. La partie Structure parle du design de groupe produit, les rôles du management et du Scrum Master, et de l’adoption. La partie Produit parle de product backlog, product owner, raffinage de product backlog, et de définition de terminé. La partie Sprint couvre le sprint planning, revue & rétrospective et coordination & intégration.

InfoQ : Pourrais-tu partager quelques informations sur les formations LeSS s’il te plaît ?

Bas : Oui, tu nous a rejoins. J’espère que tu l’as aimée !

Craig et moi avons créé deux formations certifiantes, desquelles nous considérons la certification Certified LeSS Practitioner comme la principale. C’est une formation de 3 jours qui plonge dans LeSS et l’adoption de LeSS aux organisations. Après cela, les participants seront Certified LeSS Practitioner et recevront un compte sur le site less.works, que nous considérons comme la base de tout ce qui est LeSS.

Nous mettons en place un réseau de formateurs pour qu’il y ait des formations disponibles partout dans le monde.

Pour les personnes intéressées, vous pouvez trouver le calendrier des formations ici.

InfoQ : Est-ce que tu voudrais passer un message aux organisations pour qu’elles adoptent LeSS ?

Bas : Si vous êtes à la recherche d’un changement simple, facile à adopter et vous fournissant une solution rapide à vos problèmes de développement… n’adoptez pas LeSS. Si vous êtes intéressés par une amélioration à long terme dans le développement qui tend à être disruptif, LeSS est la bonne chose pour votre organisation.

Sérieusement, LeSS attaque des problèmes structurels dans les organisations, ce qui peut conduire à des améliorations considérables mais pas faciles. Soyez persistants et continuez à apprendre.

InfoQ a publié quelques articles en début d’année sur Introduction à LeSS , Bas Vodde sur le cadre LeSS et Utiliser LeSS avec des Feature Teams pour Livrer Votre Produit à Chaque Sprint.

Si vous voulez en savoir plus sur l’implémentation de LeSS, référez-vous aux Cas d’études LeSS.

A propos de l’Interviewé

Bas Vodde est un coach expérimenté en méthodes agiles et spécialement Scrum. Il est également formateur de Scrum Master certifié. A côté de Scrum, il forme et coache les équipes en TDD, rétrospective et planification agile. Il est originaire de Hollande, cependant a vécu en Chine, en Finlande et vit actuellement à Singapour. Dans les années 90, il a travaillé en tant que développeur en Hollande et a senti une inadéquation entre ce qu’il vivait en travaillant et “ce que la littérature officielle disait qu’il fallait faire”. Cela fut résolu avec l’introduction d’Extreme Programming et même bien plus, avec le Développement Agile en général. Début 2001, il en a eu assez de la “vie normale” et déménagea en Chine où il commença a travailler pour Nokia. Là bas, il gagna en expérience sur de très grands projets et sur les manières traditionnelles de les opérer. Après cela, il devient encore plus convaincu que le Développement Agile était la manière de procéder, pour les projets de tout taille. Il dirige actuellement Odd-e, sa propre petite société de coaching et de formation.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT