Créer une équipe

Dans les méthodes agiles, l’accent est mis sur l’équipe. Il suffit de lire le manifeste agile pour s’en convaincre, valoriser les individus et les interactions, collaborer avec le client, répondre au changement. De ce postulat, nous pouvons nous demander ce qui définit l' « équipe », et ce qui la différencie du groupe.

Différence entre équipe et groupe

Contrairement au groupe, une équipe est constituée spécifiquement pour répondre à des enjeux ambitieux et est orientée vers la tâche et vers les hommes. Une équipe se caractérise par sa diversité, son unité et fournit un espace exceptionnel pour ses membres.

Une équipe est coordonnée par un leader, un groupe par un chef. Les membres d’une équipe travaillent, créent et décident ensemble ; les membres d’un groupe se réunissent et se répartissent le travail.

La dynamique d’une équipe

D’un point de vue sociologique, il peut être intéressant de voir comment se comporte la dynamique d’une équipe et la dynamique d’un groupe

La dynamique d’une équipe est très forte, beaucoup d’interactions ont lieu entre les membres et de manière équilibrée. Il est intéressant de voir aussi la position du leader qui fait partie de l’équipe et qui établit des relations multipolaires, c’est à dire que le leader n’est pas le seul pôle d’attractivité. Il est visible sur le schéma de la dynamique d’une équipe que les membres sont proches les uns des autres.

La dynamique d’un groupe est faible, les membres interagissent peu ensemble, ce qui crée une certaine latence : « c’est mou, ça manque d’énergie ». Le leader tient en général un lieu central, les interactions sont bipolaires entre le leader et chacun des membres. Les membres sont plus éloignés, ça se traduit par la distance qui les sépare réellement physiquement.

Pourquoi la dynamique est si importante ?

La dynamique d’équipe est très importante car c’est elle qui est à l’origine de la performance et de la créativité d’une équipe. Exemples réels d’une même réunion d’avancement vu d'un groupe et d'une équipe :

• Vu d’un groupe : Le chef de projet demande aux membres les uns à la suite des autres sur quoi ils travaillent et où ils en sont. Des dialogues entre le chef de projet et chaque membre ont lieu. Les autres membres attendent patiemment leur tour. La réunion a duré 1 heure. Les membres sortent de la réunion sans se rappeler exactement ce qu'ils ont à faire, ils n'ont pas l'impression de faire partie d'une équipe et ne ressortent pas avec plus énergie.
• Vu d’une équipe : L’animation de la réunion est effectuée par un des membres de l’équipe et non par le leader. Le temps de la réunion est vérifié par un des membres qui annonce le temps écoulé de façon régulière. Chaque membre participe, chacun se sent responsable de l'activité des autres (co-responsabilité). Un des membres interroge l’équipe « ça fait 2 minutes que nous parlons de ce sujet, qu’est ce qu’on décide ? ». A la fin de la réunion, un des membres propose de supprimer la réunion en mettant à jour un tableau de suivi visuel visible par tous et mis à jour en temps réel. La réunion a duré 15 minutes et sera supprimée les prochaines fois. Les membres sortent de la réunion en se sentant engagés et dans l'action, leur niveau d'énergie est fort.

L'efficacité d'une équipe peut se traduire par l'obtention des résultats attendus (ou supérieurs) dans un délais le plus faible possible.

Dans le cas du groupe de l'exemple, l'efficacité est médiocre car le groupe n'a pas obtenu de résultats concluants et surtout les membres ne sont pas dans l'action mais dans l'échange d'information, dans le "mou". Le chef est le goulot d'étranglement car c'est par lui que doit passer toutes les discussions, le temps passé est donc long et non optimisé pour chacun des membres, les résultats sont même négatifs car chacun a l'impression d'avoir perdu son temps et se sent démotivé.

Dans le cas de l'équipe de l'exemple, l'efficacité est forte car chacun valorise son temps et celui des autres, les membres participent tous activement au débat et n'hésitent pas à donner leur avis tout en respectant les règles de fonctionnement en équipe (gestion du temps, participation, écoute, ...) . La dynamique est forte et permet même à l'équipe de proposer une amélioration du suivi de l'avancement pour la prochaine fois. Le temps est optimisé et constitue un moteur à la dynamique.

Evolution d’une équipe

Pour construire une équipe, il est donc important de suivre son rythme et de respecter son développement. En particulier une équipe sera moins performante qu’un groupe dans une phase initiale mais par contre sera 10,100, 1000 fois plus performante dans une phase de maturité.

Autant le groupe est orienté vers la tâche, c’est à dire que chaque membre du groupe effectue la tâche qui lui a été donné par son chef, autant une équipe va d’abord chercher à créer des liens affectifs entre ses membres, puis partager une vision commune et enfin va se mettre à exécuter les tâches qu’elle s’est effectuée collectivement.

Et alors ?

Pour créer une équipe, il importe de respecter son développement et c’est bien le manager qui donne les moyens à ce groupe de devenir équipe :

• Dans sa phase initiale, le leader/coach/manager pourra créer une ambiance agréable, aider à tisser les liens entre les membres, par des ateliers de team building ou des dojos randoris sur des problématiques plus techniques
• Dans une phase intermédiaire, le leader/coach/manager travaillera la vision du produit que l’équipe va construire à l’aide par exemple d’atelier product box et/ou par la constitution d’un story map
• Dans la phase finale, le leader/coach/manager travaillera la montée du leadership des acteurs en déléguant et en faisant circuler ses responsabilités pour augmenter la dynamique et surmotiver l’équipe

Le démarrage de projet est très important pour une équipe car c’est le moment où le système se met en place et se stabilise. C’est l’étape où l’équipe se projette et visualise son succès ou son non succès. L’équipe évolue dans un système plus large, en particulier la culture de l’entreprise est un élément qu’il ne faut négliger ; une culture où « chez nous, je n’ai jamais vu un projet terminer à l’heure » peut avoir un effet néfaste sur l’équipe porté de manière inconsciente chez l’individu ; dans ces cas, il faut fournir beaucoup d’énergie pour arriver à focaliser l’équipe et la rendre performance avec un gros travail de visualisation et d’encouragement à chaque résultat.

Les règles de codage en équipe

Problème récurrent

Une équipe de développeurs de 8 personnes se crée. Chacun membre possède des compétences techniques très diverses. Cette équipe est en charge de créer un produit logiciel de qualité. Lancée directement vers la tâche, au bout de quelques jours de développement, personne n’arrive à comprendre le code de l’autre et finalement chacun se spécialise et se restreint à son petit univers. Un consultant externe ou le leader intervient et propose de mettre en place des indicateurs de qualité. 1 mois plus tard la situation ne s’est pas améliorée voire elle s’est dégradée.

Pourquoi ?

• Parce que chaque membre de l’équipe ne se sent pas coresponsable du code qui est produit
• Parce que le consultant externe ou le leader tombe sur une réticence au changement même si sa solution est pertinente.

Cette situation est un problème récurrent auquel j’ai pu me confronter sur plusieurs projets.

And here is the rest of it.

Autre approche

L’approche que je vous expose ici a permis à une équipe de développement agile de garder un niveau de qualité du code sur la durée.

La clé est d’accepter que l’équipe ne soit pas performante pendant une quinzaine de jours voire un mois pour lui permettre de s’aligner sur la qualité attendue du logiciel et gagner en performance sur la durée.

Un atelier très adapté pour permettre cet alignement est le Dojo Randori (c.f. Annexe) . Il peut être proposé de faire la première itération de l’équipe sous ce mode : construction de tests Fitnesse, tests JUnit, tests manuels. Cette première itération est alors un moment où l’équipe se constitue équipe en s’alignant sur les pratiques de codage. Cette première étape est positive pour la montée en compétence des membres de l’équipe, néanmoins cela ne signifie pas que le code est de qualité, que le code est « refactoré » correctement.

Pour le consultant externe ou le leader de l’équipe, ça peut être l’occasion d’organiser une séance de « code sur les murs » où il demande à l’équipe « qu’est ce qui vous permet de dire que le code est de qualité ? » à partir d’exemples déjà développés. L’équipe définit alors ces propres règles, qui par expérience, ne sont pas si différentes que celles proposaient par Martin Fowler dans Refactoring Improving the Design of Existing Code

Pendant un à deux mois, le consultant externe ou le leader peuvent alors provoquer des séances de refactoring régulières pendant lesquelles l’équipe modifie le code à partir des règles qu’elles s’étaient fixées. Ces rendez-vous peuvent être l’occasion pour ajouter des règles ou d’en supprimer.

Les métriques de code

Je suis contre l’utilisation de métriques de code PMD, CheckStyle car ces métriques créent un sentiment de contrôle sur l’équipe. Cela demande que le leader vérifie que ces règles soient respectées et qu’il aille voir les développeurs pour respecter ces règles. De plus, ces métriques sont limitées, par exemple elles ne permettent pas de savoir si une méthode est bien nommée. Ces métriques créent une déresponsabilisation des développeurs qui se disent : « Je peux faire du code de merde et je le corrigerai plus tard à partir des résultats des métriques » ; les métriques sont sujettes à proscranisation.

Annexe : Fonctionnement du Dojo Randori

• Le terme Dojo vient du japonais, lieu consacré à la méditation, au travail et à la discipline
• Lieu où les programmeurs travaillent sur un défi de programmation
• Cet atelier permet à chaque participant d’améliorer sa pratique de développement
• Il est très utile pour faire progresser les individus, les expérimentés apprennent aux plus débutants
• Les participants s’alignent sur des pratiques, des conventions de codage
• Deux personnes sont devant un ordinateur, une des deux code, l’autre la conseille, les autres derrière regardent l’écran géant et attendent leur passage

Cadrer une demande

Un cadrage rigoureux de la demande d’aide permet de mieux comprendre le système et de répondre au mieux à la demande. La demande d’aide est souvent exprimée de manière floue, soit sous forme d’un problème à résoudre, soit sous forme de solutions à mettre en œuvre. En général, le demandeur attend tout de suite une réponse. Il est important de ne pas tomber dans ce piège tant que la demande n’a pas été cadrée.

Dans la phase de cadrage, il est important de savoir si le demandeur est bien le demandeur réel ou un transmetteur, est-il responsable de la demande ? A t-il le pouvoir de décision ? Ensuite il convient de connaître la situation qui a déclenchée la demande d’aide. Pour éviter que le demandeur soit un frein au changement, vérifier que le demandeur est engagé dans sa demande.

Un objectif exprimé par le demandeur est souvent un problème ou une solution, il est important de connaître l’(es) objectif(s) supérieur(s) et valider la cohérence de l’objectif avec les objectifs supérieurs. Ensuite pour cadrer la mission, il est nécessaire de connaître les résultats attendus après l’intervention du consultant. Dans un système, il est un avantage de connaître les acteurs ressources ou freins à l’objectif (Insiders, Outsiders).

D’un point systémique, les relations entre les acteurs permettent de mieux connaître le système. Les acteurs ont-ils intérêt à s’engager dans le changement, qu’est ce que les acteurs gagnent, en particulier le demandeur ?

Connaître les marges de manœuvre du système permet de connaître l’évolution possible du système. La recherche des contraintes permet de connaître les leviers créateurs du changement. Il est important de connaître les actions en cours et les solutions qui ont déjà été tentées pour éviter de faire de la même chose.