« Portail LeSS < Portail Adoption

Les trois principes d’adoption que nous avons vus précédemment nous indiquent qu’il est préférable de commencer l’adoption de LeSS sur un seul produit. Comme pouvez-vous en augmenter les chances de réussite ?

  1. former tout le monde
  2. définir le “produit”
  3. définir la notion de “fini”
  4. avoir des équipes structurées de manière appropriée
  5. faire en sorte que seul le Product Owner soit habilité à donner du travail aux équipes
  6. faire en sorte que les chefs de projets restent éloigner des équipes

  7. Former tout le monde

Les meilleures adoptions de LeSS que nous ayons pu voir sont celles où tout le monde avait pu participer à des sessions de formations à Scrum et à LeSS étalées sur plusieurs jours. Ces sessions de formations étaient ensuite suivies par un coaching d’équipe au niveau organisationnel et technique.

Expliquer le pourquoi : En plus de former sur le quoi et sur le comment de l’adoption de LeSS, il est encore plus important d’aider les personnes à comprendre le pourquoi. Nous voyons bien trop de personnes suivre aveuglément des processus sans en comprendre le pourquoi.

Un super formateur et un super coach (fr) fera une énorme différence dans le succès de votre adoption à LeSS. Comment bien les choisir ? Vous trouverez quelques principes pour vous guider dans votre démarche ici.

1. Définir le “Produit”

Votre définition du Produit permettra de définir le périmètre de votre adoption de LeSS. Privilégiez donc des définitions assez larges afin que vous puissiez bénéficier des avantages suivants :

  1. Une meilleure vision globale de la totalité produit
  2. Une granularité plus fine
  3. La capacité de gérer les dépendances via des équipes features
  4. Une meilleure focalisation sur le problème que les utilisateurs essayent de résoudre plutôt que sur la solution qu’ils proposent
  5. La capacité à simplifier l’organisation

2. Définir la notion de “Fini”

Pour obtenir une Définition de Fini (DoD ou “Fini”, NdT : Definition of Done) qui soit bien meilleure et plus robuste, il est nécessaire que les équipes possèdent un large éventail de compétences. Par exemple, lorsque les tests de performance sont inclus dans le FIni, il est nécessaire que les équipes acquièrent des compétences en la matière. Elles peuvent être acquises par l’apprentissage mais elles sont le plus souvent apprises en faisant venir d’une équipe spécialisée dans les tests une personne ayant des compétences sur les tests de performances et en la mettant dans l’équipe. D’un autre côté, lorsque les tests de performances sont exclues du Fini alors le groupe tests de performance reste à l’identique et peut continuer à travailler de la même manière qu’avant, à moins que le Fini soit étendu.

Une Définition de Fini bien faite et robuste aura comme conséquence qu’il y aura davantage de changements organisationnels qu’une définition qui serait faible/pauvre.

Et une Définition de Fini plus faible peut être la source de risques supplémentaires et de retard !

L’effet sur la quantité de changement organisationnel fait du Fini un outil de gestion essentielle dans l’adoption de LeSS.

3. Avoir des équipes structurées de manière appropriée

Chaque équipe partage la responsabilité de réaliser un même objectif commun. Pour les aider à réussir, il convient de s’assurer que chaque équipe soit correctement structurée (fr).

Cette nouvelle structure implique de faire venir des personnes de leurs équipes fonctionnelles dans ces nouvelles équipes pluridisciplinaires. Est-ce que ces personnes devront maintenir une relation de subordination envers leur ancien responsable ? Non. Car cela provoque des conflits de loyauté qui mettent en péril la responsabilité commune et la cohésion de l’équipe.

4. Faire en sorte que seul le Product Owner soit habilité à donner du travail aux équipes

La concentration/focalisation est importante. Comment les équipes peuvent-elles la perdre ? Eh bien par exemple avec des interruptions toutes bien attentionnés et tout à fait raisonnables et des demandes pour faire du travail en plus de la part de leurs responsables hiérarchiques, des commerciaux, du PDG, des Ressources Humaines, etc. Ne laissez pas cela se produire !

Empêchez donc cela de se produise en vous assurant que le Product Owner soit la seule personne qui puisse donner du travail aux équipes. Non seulement cela permet de renforcer la concentration, mais cela réduit aussi le stress causé par les tentatives de s’occuper d’une multitude de voix disant toutes “Moi d’abord ! Moi d’abord !”. La priorisation est le problème du Product Owner et non celui de l’équipe.

Une manière de se focaliser sur le bannissement est de …

5. Faire en sorte que les chefs de projets restent éloigner des équipes

Le rôle de responsable de projet cesse d’exister dans les organisations expérimentées en LeSS. Le rôle n’est plus nécessaire car les responsabilités de gestion de projet sont partagées entre le Product Owner et les équipes.

Dans la plupart des adoptions LeSS, le rôle de responsable de projet peut être éliminé immédiatement. Dans certaines adoptions, ce rôle peut s’avérer nécessaire encore quelques temps. Cela arrive généralement dans le cas d’une Définition de Fini imparfaite (d’où, un travail non fini) ou pour coordonner des produits transversaux. Dans ce cas, les organisations ne doivent pas nécessairement oubliés leurs chefs de projet.

Donc quelques fois les chefs de projets resteront dans le coin encore quelques temps. Où est le problème ? Il est fort probable qu’ils pourraient interrompre les gens et introduire des priorités conflictuelles.

Cette recommandation reste donc dans le même esprit que “Faire en sorte que seul le Product Owner soit habilité à donner du travail aux équipes” mais elle est encore plus spécifique, et nous avons découvert, bien plus importante à rendre explicite.


Auteur : The LeSS Company B.V.
Source : Getting Started - Large Scale Scrum (LeSS)


Traducteur : Nicolas Mereaux
Date de traduction : 03/01/2017


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.