Comment améliorer la résilience d’une équipe
Vous est-il arrivé d’apprendre soudain le départ d’une personne clé dans votre équipe ? Vous rappelez-vous cette petite sueur froide lorsque cette personne irremplaçable vous annonce qu’elle sortira définitivement de l’équipe dans les prochaines semaines ?
Comme pour la Tech, la notion de “résilience” peut aussi être employée pour gérer l’instabilité d’une équipe.
“Résilience : Capacité d’un écosystème, d’un biotope ou d’un groupe d’individus (population, espèce) à se rétablir après une perturbation extérieure (incendie, tempête, défrichement, etc.).” — Définition du Larousse.
Je vous propose une technique simple qui va vous permettre d’analyser la résilience de votre équipe, mais aussi des tips pour l’améliorer.
Qu’est-ce que le “Bus factor” ?
C’est une mesure du risque dû à l’absence de partage d’informations et de compétences entre les membres d’une équipe (cf. Wikipedia).
Le principe est le suivant. Posez-vous la question suivante :
« Combien de personnes clés dans votre équipe peuvent se faire renverser par un autobus avant que votre projet échoue ? »
Evidemment, ne lisons pas cette phrase au 1er degré. Il s’agit plutôt de rechercher si l’absence de certains membres entraverait le bon fonctionnement de l’équipe et du projet. Cette technique permet alors de détecter les points faibles de l’équipe avant que le risque soit avéré et donc devienne un problème.
Une vidéo pour mieux comprendre l’effet bus : Hit By A Bus — The Supercut — Vidéo Dailymotion 😊
Comment calculer votre facteur d’équipe ?
Je vous propose la version simplifiée. pendant une Rétrospective, il suffit de calculer le nombre de personnes qui ont la connaissance sur différents sujets fonctionnels ou techniques. Ce sera votre “Bus factor’.
Mais, avant, chaque membre de l’équipe devra définir ses différentes activités et compétences en renseignant la matrice de Poly-compétence.
Vous verrez, plus le “Bus factor” sera élevé, plus le fonctionnement de l’équipe et du projet sera considéré comme élevé !
Mais, on n’est pas des experts !
Il est vrai que le fait de poser à plat les compétences de chacun peut engendrer la peur de devenir LE référent ou l’expert et d’avoir un surcroit de travail ou de n’être cantonné que dans la même activité. Toute la difficulté sera donc de dédramatiser la situation en expliquant bien le but du calcul.
Quelques arguments pour bien lancer l’atelier :
- Un aspect confidentiel : Le résultat n’appartiendra qu’à l’équipe et ne sera pas remonté au management. D’autre part, le résultat du calcul sera global et non par membre de l’équipe,
- Cela fait partie amélioration continue et de l’auto-organisation de l’équipe,
- Pour conserver un produit pérenne et de qualité,
- Pour une équipe efficace et flexible, qui gèrera mieux les pics d’activité ou les périodes de congés,
- Pour donner confiance à l’équipe en connaissant ses points forts et ses axes d’amélioration,
- Pour remonter des demandes de formations techniques et fonctionnelles des membres de l’équipe.
Prenons un exemple
Une équipe, constituée d’un Product Owner, de 5 développeurs et d’un testeur, est en charge du parcours utilisateur pour la souscription d’un contrat d’assurance-vie.
Le Scrum Master demande à chaque membre de l’équipe d’indiquer dans la matrice ci-dessous s’il maitrise ou non l’activité décrite.
En analysant le tableau, l’équipe remarque les points suivants :
- Facteur à zéro : Le Product Owner et la testeuse connaissent fonctionnellement le parcours de bout en bout, mais ce n’est pas le cas des développeurs ==> Analyse de l’équipe : Est-ce réellement important que les développeurs connaissent le parcours ?
- Facteur à 1 : Attention, seule une personne sait gérer les habilitations. Il en est de même pour la partie technique du Webservice ==> Analyse de l’équipe : On risque de bloquer des demandes Métier ou utilisateurs pendant pendant l’absence de cette personne.
- Facteurs 2, 3 et 4 : Super ! 5 développeurs ont une connaissance technique globale de l’outil, MAIS chacun est spécialisé dans son domaine ==> Analyse de l’équipe : Quel est l’impact actuellement sur notre projet ? A-t-on un problème de partage et d’échange dans l’équipe entre le Front et le Back end ?
Une base de travail
Cette matrice permet de factualiser rapidement l’état de connaissance d’une équipe. Il lui restera ensuite d’analyser les résultats, de prioriser les urgences et de lancer des actions associées. Ce qu’elle pourra ajouter en commentaire.
Un conseil : Ne cherchez pas à trop détailler les activités (sauf si l’équipe considère qu’elles sont nécessaires). Sinon, vous risquez de passer beaucoup de temps à remplir la matrice et … démotiver l’équipe !
Mais, comment augmenter votre “Bus factor” ?
Le but est que le “Bus factor” soit le plus proche du nombre de membres de l’équipe. Pour cela, il existe plusieurs façons d’augmenter ce facteur.
En favorisant les échanges entre les membres de l’équipe pour être au même niveau de connaissance,
- Avoir des objectifs clairs,
- Le daily,
- Le partage du suivi des indicateurs de l’équipe,
- Les points d’avancement réguliers avec les Métiers et l’équipe,
- Les démos,
- Les réunions d’échanges (exemple : chapters),
- Les Communautés de Pratiques.
En favorisant la montée en compétence et la polyvalence par le travail en binôme
- Le pair-writting (ou co-écriture d’une Userstory),
- Le flux tiré d’une story sans pré-affection à une personne “experte”,
- Le rôle tournant pour le traitement d’un bug avec la possibilité de faire appel à un expert de l’équipe à tout moment,
- La Code review,
- Le Pair-programming,
- Le Pair-dev (ou Mob programming).
En favorisant l’échange de connaissance et la maitrise du produit et des outils
- Le Story mapping & Event Modeling,
- Les 3 Amigos,
- La documentation vivante,
- L’automatisation des tests,
- L’octroi de temps aux personnes porteuses d’un “Bus factor” faible pour transférer régulièrement leurs compétences aux autres membres de l’équipe.
En résumé
Cette matrice est très pratique pour mettre en évidence le risque de perte de connaissance dans l’équipe, pour favoriser son auto-organisation et privilégier sa polyvalence plutôt que la spécialisation de chacun de ses membres.
“Les Scrum Teams sont pluridisciplinaires, leurs membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint.” — Guide Scrum 2020.
Une matrice qui perdure dans le temps !
Cette matrice n’est pas figée ! Vous pourrez la reprendre quelques mois plus tard pour analyser la progression de l’équipe ou pour préparer le transfert de connaissance lors du départ d’un de ses membres.
Pour aller plus loin
Une variante de la matrice : Un outil simple pour dynamiser son équipe : la matrice de polyvalence — PLEYERS plc
Vidéo de Scrum Life sur la pluridisciplinarité d’une équipe : https://youtu.be/rUSxzIw8_D0?list=PLxTb_ZC4kmrSpjDE2IkRjSRAkfIsLYfP9
Vidéo sur le biais de la “malédiction de la connaissance” : https://youtu.be/6LQVUPcTxwA
