Retour d’expérience sur un processus d’autosélection d’équipes

La structuration des équipes est un enjeu central dans le développement logiciel, tant pour leur efficacité que pour leur capacité à livrer des produits de qualité. Des concepts comme la célèbre règle des 2 pizzas d’Amazon, qui stipule qu’une équipe devrait être suffisamment petite pour se nourrir avec deux pizzas, ou encore les principes d’autonomie de Daniel Pink, illustrent bien l’importance de concevoir des équipes capables de fonctionner de manière autonome et alignée. Ajouter plus de force brute à une équipe en croisant les doigts, comme mettre un four à 1000 degrés pour cuire une pizza en 1 minute, ne mène pas forcément à des résultats meilleurs ou plus rapides.

Au contraire, une organisation réfléchie, émergente d’un besoin et basée sur la confiance permet d’améliorer des métriques clés comme le temps de revue de code, le délai de changement et le sentiment d’engagement des équipes. C’est dans ce contexte que nous explorons l’impact d’une approche innovante comme les équipes autosélectionnées.

Les défis des grandes équipes

Au début du projet, l’équipe comprenait un total de 14 développeurs et développeuses (dont 2 teams leads), 1 responsable de produit (Product Owner), 1 designer et 2 spécialistes en assurance qualité. Il est facile d’imaginer comment cela pouvait rendre plusieurs aspects du travail en équipe complexe, surtout au niveau de la communication. Le diagramme ci-bas démontre que plus le nombre de membres d’une équipe augmente, plus le nombre de « lignes de communication » augmente.

Évolution des canaux de communications relativement à la grosseur d’une équipe

Voici quelques exemples plus concrets des défis rencontrés au début du projet quand l’équipe formait une seule grosse équipe :

• Trop de monde dans les réunions : avec 18 participants, les réunions deviennent chaotiques. Le consensus est difficile, le focus se perd, et beaucoup de temps est gaspillé.
• Manque d’imputabilité et de responsabilité : plus il y a de personnes impliquées, plus l’ownership des tâches est flou. Cela mène à des actions non assignées, des responsabilités négligées et un désengagement.
• Chevauchement dans les tâches : dans une équipe de 14 développeurs et développeuses, gérer le travail en cours (work in progress ou WIP) est compliqué. Les tâches s’entrecoupent, ce qui ralentit le progrès malgré le travail en parallèle.
• Dilution de la responsabilité : quand il y a trop de personnes sur une revue de code, tout le monde pense que quelqu’un d’autre s’en occupera. Résultat : les revues prennent plus de temps, ou ne sont pas faites efficacement. Ce concept se nomme la dilution de la responsabilité.

Fort à parier que vous avez déjà rencontré ce genre de défis dans divers contextes.

L’introduction des équipes autosélectionnées

Une des solutions peut être assez simple : il faut séparer cette équipe d’une manière ou d’une autre pour tenter d’augmenter la productivité et diminuer le temps perdu. Il aurait été facile de laisser les gestionnaires s’occuper de diviser les équipes par eux-mêmes, compte tenu de leur vision 360 sur l’équipe.

Mais pourquoi ne pas laisser les membres de l’équipe choisir ?

C’est ici qu’entre en jeu le concept d’équipe autosélectionnée. Globalement, l’exercice est relativement simple :

• Définition et présentation des différentes équipes disponibles et de leur mission ;
• Explication des règles et contraintes (le moins possible) qui doivent être remplies par chaque équipe et qui mènent à l’achèvement de l’exercice ;
• Ronde(s) de sélection :
  • Chaque individu décide de l’équipe de son choix ;
  • Les sous-équipes se forment et se réunissent pour évaluer s’ils répondent aux contraintes ;
  • Chaque équipe présente ses enjeux : si les contraintes ne sont pas respectées, le processus recommence ;
  • Continuer jusqu’à ce que les équipes répondent aux contraintes ou jusqu’à l’épuisement des troupes.
• Une fois les équipes complétées et les contraintes remplies, conclure et informer les équipes de la suite des choses (mise en fonction des équipes).

Processus de formation des équipes autosélectionnées

Dans le cadre de notre projet, il y avait :

• 3 fonctionnalités à amorcer en parallèle et donc 3 sous-équipes possibles ;
• Les contraintes étaient :
  • Au moins 1 développeur de l’équipe client dans chaque équipe, pour bien partager la connaissance des fonctionnalités ;
  • Chaque équipe devait être capable d’amener la fonctionnalité jusqu’au bout et donc avoir des forces variées et complémentaires.

Le truc ici est de ne pas avoir peur et de ne pas hésiter. « Si jamais une équipe n’est formée que de juniors ? », « si jamais personne ne veut travailler avec cette personne ? » ou bien « si personne ne veut travailler sur la fonctionnalité X ? ». En suivant le processus, les contraintes et en faisant confiance aux membres de l’équipe, l’autosélection sera toujours possible.

Finalement, après 1 seule ronde de sélection, les équipes étaient complètes. Le résultat fut donc 2 équipes de 3 et 1 équipe de 5 en gardant les 2 team leads, le responsable de produit, le designer, les spécialistes en assurance qualité et 1 développeur expérimenté flottant.

À partir de ce moment, même si beaucoup d’autres choses ont changé dans le projet, la séparation en sous-équipes autosélectionnées est devenu un catalyseur pour plusieurs initiatives et résultats positifs.

Les bénéfices constatés

En reprenant les défis mentionnés au début de cet article, voyons maintenant comment la séparation en sous-équipes autosélectionnées a participé à régler plusieurs défis auxquels faisait face l’équipe en début de projet.

• Trop de monde dans les réunions : avec des équipes plus petites, les réunions deviennent plus dynamiques, productives et pertinentes, car elles n’impliquent que les membres vraiment concernés.
• Manque d’imputabilité et de responsabilité : les équipes ont maintenant choisi ce sur quoi ils travaillent et avec qui. Ceci est naturellement plus engageant. Le but de l’équipe est mieux défini et le partage des tâches se fait beaucoup plus rapidement puisque les choix sont plus limités.
• Chevauchement dans les tâches : chaque équipe possède ses propres fonctionnalités de bout en bout, réduisant les confusions et augmentant la vélocité grâce à des pratiques adaptées comme la programmation en binôme ou en groupe (pair ou mob programming).
• Dilution de la responsabilité : Les revues de code et le temps de livraison se sont nettement améliorés, puisque les revues deviennent ciblées à un sous-groupe très précis qui est plus imputable.

Que disent les chiffres ?

Dès l’instauration des sous-équipes, un vent de fraîcheur s’est installé. Les équipes semblaient plus engagées et alignées et moins de temps était perdu. Mais que disent réellement les chiffres ?

Dans les 5 mois suivant la mise en place des sous-équipes autosélectionnées, il a été possible de remarquer des améliorations significatives.

Au niveau des revues de codes, une baisse de 60 % du temps de cycle total de revues de code ainsi qu’une baisse de 67 % du temps de prise en charge de la revue de code ont été mesurées. Il est intéressant de noter ici la diminution de la dilution de la responsabilité qui devient un facteur clé qui pour impacter ces chiffres.

Évolution du temps de revue de code sur les 5 mois suivant l’autosélection des équipes. Capture de notre outil Axify.

De plus, le délai de changement pour l’amener de l’implémentation à son déploiement a diminué de 63 %, ce qui représente une différence majeure dans un processus de développement.

Évolution du délai de changement sur les 5 mois suivant l’autosélection des équipes. Capture de notre outil Axify.

Les métriques ci-haut sont également influencées par plusieurs autres facteurs et initiatives qui ont été mis en place durant le projet. Il faut toujours douter des chiffres ! Mais, avec un ensemble de métriques, il reste possible d’avoir une idée globale du résultat.

Que disent les membres de l’équipe ?

Outre les chiffres, que disent certains membres de l’équipe ? Comment se sont-ils sentis après ce changement ? Trois membres de l’équipe ont été interrogés de la manière suivante :

• Décris en une phrase l’impact que le changement vers les sous-équipes a eu sur toi ;
• De 1 à 10, note les 3 aspects suivant, avant et après le changement :
  • Perception globale de l’aisance à livrer des changements
  • Engagement et satisfaction
  • Productivité perçue

Voici ce qu’ils avaient à dire et plus bas les notes qu’ils ont accordées aux différents aspects avant et après le changement :

La séparation en sous-équipes a réduit la charge mentale de devoir être au courant de toutes les initiatives en cours et a permis de recadrer les priorités pour voir clairement le travail à accomplir.

– Francis, Développeur

La séparation en sous-équipes m’a permis d’avoir un meilleur focus, une équipe de travail soudée et un meilleur ownership des fonctionnalités sur lesquelles je travaille.

– Jeanne, Développeuse

On se sent plus responsables de ce sur quoi l’on travaille, donc on est plus activement impliqués, mais en même temps, ça facilite le lâcher-prise, car on sait ce qu’on peut laisser entre les mains des autres. Donc paradoxalement, on lâche plus prise, mais au final, on s’implique aussi davantage.

– Mylène, Développeuse

Conclusion

Tout d’abord, il est à noter que la mise en place des sous-équipes n’a été qu’un facteur parmi tant d’autres qui ont mené à ces améliorations majeures. Par contre, il est valide de supposer que l’avènement des sous-équipes auto-organisées a été un catalyseur pour plusieurs autres initiatives telles que :

• L’implication de l’équipe de développement dès l’écriture dans la création des récits utilisateur ;
• La création d’équipes de rotations pour gérer les situations d’urgences ou les demandes externes ;
• La mise en place de différentes méthodes de travail telles que le pair, le mob et les revues de codes synchrones, toutes adaptées aux sous-équipe.

Il est également important de prendre du recul face à ce qui a mené à ce changement. Au début du projet, une idée similaire existait, dans laquelle la grosse équipe allait être séparée d’une manière prédéfinie et chaque sous-équipe aurait un rôle clair. Cette idée a généré beaucoup de frictions et n’a finalement pas été mise en place. Pourtant, seulement quelques mois plus tard, l’équipe est arrivée à un résultat similaire, mais en laissant émerger le besoin et en laissant les gens choisir plutôt qu’en l’imposant sans répondre à un besoin précis.

Que faut-il en retenir ?

• Les humains aiment avoir de l’autonomie ;
• Une plus petite équipe permet plus de focus et donc ultimement une livraison de la bonne chose, plus rapidement ;
• Il est important de vivre et d’accepter une période d’adversité pour en ressortir des solutions qui répondent à de vrais besoins ;
• N’ayez pas peur d’innover pour éliminer des problèmes.

Qui sait, peut-être que vous pourriez gagner à mélanger vos équipes de temps à autre en laissant le choix aux membres des ces équipes !