Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Diriger un projet web Agile
  3. Gérer l'équipe
Extrait - Diriger un projet web Agile Utilisez la dynamique des groupes pour décupler Scrum (2e édition)
Extraits du livre
Diriger un projet web Agile Utilisez la dynamique des groupes pour décupler Scrum (2e édition) Revenir à la page d'achat du livre

Gérer l'équipe

Introduction

Manager directement plusieurs équipes plutôt que quelques chefs de projets nécessite de bien maîtriser les concepts de la dynamique des groupes.

De plus, une bonne maîtrise de ce sujet peut avoir de fortes incidences sur la productivité des ressources, donc influencer la réussite ou l’échec du projet.

Principes agiles et dynamique des groupes

Une des forces et certainement l’innovation la plus marquante de l’agilité consiste à constituer une équipe autonome et autogérée, capable de réaliser l’ensemble du projet qui lui est confié, à la fois dans son analyse, sa définition fonctionnelle et sa production concrète. Elle est et doit être parfaitement autonome. Qu’elle soit autogérée implique qu’elle n’est pas dirigée, conduite ou gouvernée par un manager dans ses actions quotidiennes.

Attention, il ne faut pas confondre manager et leader, car ce sont deux rôles différents. Le manager peut très bien ne pas être un leader et agir principalement par coercition. De la même manière, un leader peut ne pas avoir de fonction de manager, il inspire mais ne dirige pas.

Ce rôle est très proche du Scrum Master et l’on constate que lorsque celui-ci est imposé à l’équipe par voie hiérarchique, il peut être accepté et légitimé par l’équipe, mais il peut aussi arriver qu’un autre leader émerge au sein de celle-ci, mettant alors en difficulté le Scrum Master dans l’expression de son rôle.

L’émergence d’un leader dans une équipe n’est pas un processus aléatoire...

Cycle de vie de l’équipe

Comme nous l’avons abordé au chapitre Constituer l’équipe à la section Performance de l’équipe, lors de sa constitution, son évolution dans le temps est régie par le passage par cinq stades d’évolution définis par Tuckman. MacKenzie proposera ultérieurement une révision de ce concept mais celle-ci semble plus adaptée à l’étude des groupes dans un cadre thérapeutique que professionnel.

Pour accroître l’efficacité de l’équipe à moyen terme, il est important de comprendre les phénomènes qui agissent tout au long des trois premiers stades d’évolution afin d’aider l’équipe à les franchir le plus efficacement possible. Cela ne signifie pas le plus rapidement possible, car atteindre rapidement le quatrième stade ne signifie pas que l’équipe parviendra à y rester dans la durée. En revanche, l’atteindre efficacement permet d’importants gains de productivité.

1. Forming

C’est la rencontre de l’équipe. Ses membres ne travaillent pas encore ensemble, mais se découvrent mutuellement. À ce stade, l’équipe est fortement dépendante du manager qui doit lui décrire sa mission, fixer son cadre de travail, définir les rôles, périmètres et responsabilités de chacun.

À ce stade, se mettront en place les premiers processus de normalisation du groupe (Sheriff, 1936), puis de conformisme (Asch, 1952), qui participeront ultérieurement à la pression sociale sous la forme de l’influence majoritaire exercée par l’équipe sur ses membres.

L’attitude et le positionnement du manager par rapport à l’équipe contribueront également à fixer la norme sociale de l’équipe.

L’application stricte des rituels Scrum permet de franchir cette étape plus rapidement. Par exemple, le stand-up meeting implique que tous les membres...

Contrôler

La mise en œuvre de méthodes agiles bouscule les pratiques de management et de contrôle utilisées habituellement. Le directeur de projet n’a plus de chefs de projets qui lui sont, d’une certaine manière, attachés hiérarchiquement et à qui il a délégué un pouvoir, mais doit manager directement des équipes autogérées. 

Dans un cadre idéal, les Product Owners appartiennent à des entités qui ne dépendent pas du directeur de projet et sur lesquels il n’a aucun pouvoir hiérarchique. Même si c’était le cas, mettre en œuvre l’agilité dans l’entreprise implique de revoir également le mode de management et de considérer la pression hiérarchique comme une méthode archaïque qu’il convient de remplacer par des processus plus efficaces.

Plutôt que de convoquer les chefs de projets à une réunion hebdomadaire lors de laquelle ils rendent des comptes, le directeur de projet peut mettre en place plusieurs méthodes, de manière concomitante, en fonction du niveau de confiance en soi et de l’autonomie prise par les équipes.

Il est utile de rappeler que Scrum repose sur trois piliers : la transparence, l’inspection et l’adaptation. Ces trois piliers, mis en œuvre par l’équipe Scrum, conduisent celle-ci à être en capacité de mesurer sa performance en permanence (inspection), et à pouvoir communiquer clairement ces indicateurs (transparence). Scrum introduit donc une forme d’inversion du contrôle. Celui-ci est effectué par l’équipe et pour l’équipe (afin de s’adapter efficacement) et est communiqué au manager par la transparence induite par Scrum.

Nous distinguerons deux formes de contrôle : le contrôle non mesuré, effectué de manière ponctuelle, principalement mû par l’intuition, et le contrôle mesuré qui repose sur des indicateurs formels étudiés de manière cyclique.

1. Contrôle non mesuré

a. Échange informel

Il repose avant tout sur un échange d’informations. Le directeur de projet informe un membre de l’équipe...

L’effet Janis

Communément appelé pensée moutonnière, l’effet Janis peut avoir de fâcheuses conséquences sur un projet. Il est le résultat d’un consensus mis inconsciemment en place par l’équipe dans le but de sauvegarder sa cohésion, voire son existence.

Il a pour effet d’appauvrir le système décisionnel de l’équipe qui, au lieu de rechercher de réelles solutions aux problèmes qu’elle rencontre, mettra en œuvre des solutions simplistes, rapides à déployer. Elle perd sa vision critique à moyen et long terme et s’oriente exclusivement vers des solutions visant à régler les problèmes à très court terme sans prendre en compte les risques ultérieurs éventuels.

L’effet Janis a de fortes chances d’apparaître lorsque :

  • La cohésion du groupe est élevée.

  • Une forte pression hiérarchique est appliquée sur l’équipe, lorsque le projet revêt des enjeux stratégiques pour l’entreprise, lorsque l’équipe a vécu plusieurs échecs successifs (sprints en retard, forte dette technique, stories abandonnées en cours).

  • Il existe une situation de stress, d’angoisse, de menace.

  • Le Product Owner n’exerce plus assez de pouvoir...

Autres risques potentiels

1. Pression sociale négative ou antiproductive

Ce risque est assez proche de l’effet Janis et apparaît plus souvent que l’on pourrait le croire. Toujours dans le but de préserver l’équipe, celle-ci va inconsciemment mettre en place des normes visant à se protéger de l’entité qui menace le plus directement sa cohésion : le Product Owner.

Cela se traduit par une surévaluation des estimations de complexité lors d’un planning poker. On remarque alors que le leader de l’équipe influence les membres sur leur choix.

  • « Es-tu sûr que c’est si simple ? »

  • « Je crois que tu sous-estimes la tâche. »

Un effet plus retors est la mise à l’écart d’un membre plus productif que les autres. Cet effet se constate par la position des membres de l’équipe autour du Scrum Master lors des réunions de mêlée quotidienne. Le membre productif cherchera à occuper le centre de l’équipe mais sera reporté progressivement vers l’extérieur par celle-ci. Par la suite, les autres lui adresseront de moins en moins la parole, allant jusqu’à oublier de le convier à des activités extraprofessionnelles, pauses, sorties, déjeuners... Dès lors que la productivité de celui-ci redescendra au niveau moyen de l’équipe, il sera pleinement réintégré.

2. Déportation de menace

Lors du processus de forming, il arrive souvent qu’un bouc émissaire soit désigné soit au sein du groupe, soit à l’extérieur du groupe. Cette démarche permet à l’équipe en tant qu’entité émotionnelle de reporter l’agressivité interne sur cette cible. Plutôt que d’affronter les divergences au sein du groupe, celui-ci, se sentant menacé par les tensions internes, décide de les déporter sur un tiers. Si le leader du groupe a été imposé par voie hiérarchique et que l’équipe prend ce dernier comme bouc émissaire, l’équipe peut basculer dans un état de casse comme défini par Anzieu. Elle se comporte alors comme les tribus sacrifiant leur chef...