« Portail LeSS < Portail Structure

Qu’est-ce qu’une équipe ?

Les équipes sont la brique de construction essentielle pour le développement d’un gros produit, et la structure de l’équipe a un énorme impact sur la productivité et le temps de cycle.  L’équipe a :

  • un travail partagé sur le produit
  • un travail interdépendant
  • une responsabilité partagée
  • un ensemble d’accords de travail
  • la responsabilité pour gérer les relations en dehors de l’équipe [SJS03]
  • un leadership distribué [Katzenbach98].

Équipes auto-gérées

Les équipes auto-gérées sont la base de Scrum et c’est une pratique aujourd’hui en extension dans le domaine du management moderne. L’équipe a l’autorité pour concevoir, préparer et exécuter ses tâches et pour suivre et gérer son processus de travail et son état d’avancement [Hackman02]. L’équipe, et non le chef de projet, a la responsabilité de décider comment travailler.

Les équipes auto-gérées n’apparaissent pas d’un coup, elles ont besoin du bon environnement. L’organisation a la responsabilité de soutenir le développement de l’équipe en créant les conditions nécessaires au succès de l’équipe. Evoluer avec des équipes auto-gérées signifie que le travail du manager traditionnel passe de la direction d’équipe à la création de ces conditions.

Équipes pluridisciplinaires

Les équipes auto-gérées sont pluridisciplinaires. Une équipe pluridisciplinaire est un “groupe de personnes avec un objectif clair représentant la diversité des silos ou disciplines de l’organisation, et dont les efforts combinés sont nécessaires pour atteindre l’objectif de l’équipe” [Parker02].

Par définition, une équipe Scrum est pluridisciplinaire. Ses membres intègrent au minimum le marketing produit (Product Owner), le développement logiciel et le test. Une équipe pluridisciplinaire implique de casser les silos de l’organisation entre le développement et le test en les mettant dans la même équipe.

Pluridisciplinaire signifie qu’être membre de l’équipe met en jeu toutes les fonctions essentielles nécessaires à un projet, généralement l’ingénierie, le marketing et la fabrication, et c’est un minimum [Smith07].

Organisation basée sur les équipes

L’organisation LeSS basée sur les équipes a la structure suivante :

  • Équipes dédiées : chaque membre de l’équipe est dédié à plein temps dans une et une seule équipe. Cela peut sembler rigide, mais les membres de l’équipe doivent être à plein remps si vous voulez qu’ils (1) partagent la responsabilité de l’objectif de l’équipe, et (2) s’approprient la façon dont travaille l’équipe et leur processus.
  • Équipes pluridisciplinaires : chaque équipe contient toutes les compétences nécessaires pour fabriquer un produit déployable. La spécialisation traditionnelle peut sembler la plus “efficace” d’un point de vue fonctionnel, mais la plupart des efforts et des problèmes dans le développement produit sont “entre les fonctions”, c’est ce qui explique que les équipes doivent être pluridisciplinaires si vous souhaitez qu’elles se concentrent sur la globalité du produit opérationnel.
  • Équipes co-localisées : chaque équipe est co-localisée dans la même pièce. Cela peut sembler déraisonnable. Ne voudriez-vous pas utiliser, dans la société mondialisée d’aujourd’hui, les personnes disposant des meilleures compétences là où elles se trouvent ? Non. Nous souhaitons les meilleures équipes qui puissent partager la responsabilité des résultats de l’équipe, et apprendre les uns des autres. Une responsabilité partagée nécessite de la confiance. Les personnes bâtissent la confiance plus rapidement avec une coopération étroite et une communication en face à face. La co-localisation encourage aussi l’apprentissage de l’équipe, qui est l’essence de l’amélioration continue.
  • Équipes pérennes : une équipe reste ensemble “pour toujours”. Cela peut sembler idéaliste, mais les équipes ont besoin de stabilité si vous voulez qu’une équipe se préoccupent de la façon dont elle travaille en tant qu’équipe. Toute personne qui a déjà réellement été membre d’une équipe pendant très longtemps sait que les équipes deviennent meilleures lorsque ses membres apprennent à se connaître les uns les autres et apprennent à savoir comment travailler et s’améliorer ensemble.

L’équipe gère les dépendances externes

Quelles sont les implications sur le développement d’un gros produit ? Elles sont profondes ! Premièrement, chaque équipe doit avoir un objectif clair pour connaître les limites. Etablir des équipes feature qui soient centrées sur le client aide dans ce sens. Cela génère une communication inter-équipes et orientée sur le code. Deuxièmement, l’organisation doit clarifier au maximum que les équipes sont elles-mêmes responsables de coordonner leur travail avec les autres équipes. Le succès d’une équipe peut être mesurée par le succès du produit global, ceci afin de prévenir toute optimisation locale. Si vous supprimez les rôles officiels de coordination tels que les chefs de projet, il devient très clair pour l’équipe que la coordination est de leur responsabilité. Troisièmement, mettez en place un système d’intégration continue à l’échelle du produit global. Cela offre la visibilité dont les équipes ont besoin pour coordonner leur travail. La santé du produit doit toujours être visible par tous.

Des employés multi-compétents

Apprendre est l’activité principale dans le développement de produit. Sur le long terme, réduire l’apprentissage réduit l’efficacité, cela ne l’augmente pas. Sherman dit dans Fortune Magazine : “Les employés seront récompensés en fonction de leur connaissance et adaptabilité. Le spécialiste n’est plus de mode, c’est le généraliste qui l’est maintenant. Les personnes les plus employables seront des gens flexibles qui pourront facilement passer d’un poste à l’autre, en intégrant diverses disciplines et perspectives… ces personnes devront être capables non seulement d’acquérir de nouvelles compétences mais aussi de désapprendre les anciennes manières de travailler.”

L’équipe prend des décisions

Les équipes auto-gérées prennent elles-mêmes leurs décisions. Pourtant, beaucoup de personnes ont grandi dans des environnements contrôle-commande où le management prend les décisions pour elles. Un ScrumMaster peut aider les équipes à apprendre comment prendre des décisions. Un accord entre les membres de l’équipe sur la façon de prendre des décisions est plus important qu’une méthode particulière de prise de décision.

Le protocole Decider [MM02] est un moyen facile et rapide de prendre des décisions par consensus (NfT : voir les Core Protocols).

Le conflit dans une équipe

Le fait de travailler ensemble génère des conflits. Ce n’est pas une mauvaise chose. Mais le conflit doit être résolu. Un conflit non résolu a un impact négatif sur la performance de l’équipe et crée un dysfonctionnement dans l’ambiance de l’équipe [Lencioni02]. Un conflit résolu, par contre, crée de l’apprentissage et de la confiance, les deux ont un impact sur la performance. Le conflit est une opportunité pour l’équipe d’améliorer sa performance, c’est donc une bonne chose.

Ne passez pas par une phase d’allocation de ressources

Scrum, ce n’est pas du Cycle en V. Il n’y a pas de phase. Avec l’auto-gestion, la pluridisciplinarité et les équipes feature pérennes, il équilibre le “besoin en ressources” sur la version. Ce sont les mêmes personnes qui restent sur la version du début à la fin.

Conclusion

Ces concepts d’équipe, différents mais éprouvés, causent des changements majeurs dans les organisations :

  • Des équipes auto-gérées ont besoin de passer d’un management contrôle-commande à un management-enseignant. Au lieu de se concentrer sur ce que les gens font, le management devrait vraiment réfléchir à la manière de créer un environnement pour que les équipes réussissent.
  • Des équipes pluridisciplinaires ont besoin de casser les silos de l’organisation globale et de travailler ensemble pour optimiser la valeur livrée au client. Au lieu de parquer les gens dans des silos, le management devrait se concentrer sur l’apprentissage pluridisciplinaire.
  • Des équipes dédiées pérennes ont besoin de laisser les équipes existantes décider de leur façon de travailler. Au lieu de considérer chaque individu comme une unité de performance, concentrez-vous sur les équipes.

Lectures conseillées

Lorsque vous passez sur des équipes pluridisciplinaires, il est difficile de changer le style de management. Heureusement, beaucoup de choses excellentes ont été écrites sur le sujet :

Les équipes pluridisciplinaires sont principalement décrites dans la littérature sur le développement produit. Voilà quelques bons ouvrages :

D’autres textes sur les équipes de développement logiciel :

  • Software for Your Head de Jim et Michele McCarthy. Jim et Michele ont passé des années dans des “boot camps” pour découvrir les meilleures manières de travailler pour les équipes. Ils l’ont documenté sous la forme d’un ensemble de protocoles dans ce livre.
  • Peopleware de Tom DeMarco et Tim Lister. Ce classique sur l’importance des personnes dans le développement logiciel comporte aussi quelques chapitres axés sur les équipes.

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


Traducteur : Fabrice Aimetti
Date de traduction : 02/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.