Le turnover au sein d’une équipe Scrum
- Mouvements et interrogations
- Comment réagir face à ces changements ?
- Le modèle de Tuckman
- Conclusion
L’une de mes équipes a vécu du turnover, notamment de l’un de ses rôles clés : le PO. Pendant cette phase, il m’a été difficile de trouver une définition précise du turnover. Aussi connu sous le nom de rotation de l’emploi, ou encore de renouvellement du personnel, il s’agit selon les sites du « taux de renouvellement du personnel dans une entreprise », ou encore du « renouvellement des effectifs suite à des recrutements et/ou des départs ». Cela m’a donné l’occasion de prendre du recul sur la gestion du turnover au sein d’une équipe Scrum.
Mouvements et interrogations
Une équipe en déséquilibre
J’accompagnais, en tant que Scrum Master, une équipe plutôt stable et mature dans son fonctionnement. Il n’y avait pas eu de départs ni d’arrivées depuis 6 mois, les conflits étaient rares et quand il y en avait, ils étaient réglés assez rapidement. De même, les différents événements du Sprint se déroulaient sans accrocs et le cadre de l’équipe était bien défini.
En juin, notre Product Owner a annoncé qu’il quitterait l’équipe fin octobre. Son remplaçant fut trouvé assez rapidement (environ un mois), permettant ainsi une passation suffisamment longue (trois mois), et son départ fut progressif (d’abord présence aux 4/5e, puis 3j/semaine… jusqu’au départ définitif). Je pensais que le processus serait suffisamment fluide pour éviter les impacts sur le fonctionnement de l’équipe, en revanche le coach qui nous accompagnait à l’époque pensait autrement (« ça va chambouler la team », m’avait-il dit) ; la suite lui a donné raison…
L’équipe de réalisation qui jusqu’alors avait trouvé un point d’équilibre avec l’ancien Product Owner est devenue défensive avec son remplaçant, lui reprochant par exemple de ne pas se conformer au rythme des ateliers de l’équipe (exemple : 2 sessions de backlog refinement/sprint).
S’en sont suivis plusieurs mois compliqués avant de retrouver une certaine stabilité. C’est alors qu’un autre changement dans l’équipe a eu lieu, cette fois-ci plus brutal (une semaine entre l’annonce du départ et l’arrivée du remplaçant, le tout sans consultation de l’équipe !). Ce dernier a de nouveau eu un impact sur les interactions entre les membres de l’équipe.
Le coup de grâce pour l’équilibre de l’équipe fut une période sur laquelle cette dernière a fait face à un changement par mois (en moyenne, pour cause de départ, arrivée, remplacement, congé maternité…).
Creuser le sujet du turnover dans l’équipe
C’est cette expérience qui m’a conduit à approfondir la question de l’impact du turnover sur la Scrum Team, et comment le gérer au mieux en tant que Scrum Master.
J’avais plusieurs interrogations : quand parle-t-on de turnover faible ou élevé ? Faire cette distinction, dans une Scrum Team, a-t-il du sens ? Dans une équipe de 10 personnes, le remplacement d’une personne par une autre en 6 mois a-t-il autant d’impact que trois départs et trois arrivées en un mois ?
Les articles que j’ai pu consulter mentionnent effectivement la nécessité d’avoir une équipe Scrum stable, cependant aucun ne dit comment gérer au mieux la situation si ce n’est pas le cas…
De tous ces changements dans mon équipe, de mes recherches et des discussions que j’ai pu avoir avec différents Coachs et Scrum Masters, j’ai tiré quelques pistes de réflexion que je me propose de partager avec vous.
Deux axes, trois phases
Un changement dans une équipe a des impacts sur deux aspects : le savoir-faire et le savoir-être. Ils constituent les axes sur lesquels je me concentre dans mon accompagnement en tant que Scrum Master lors d’un changement dans une équipe (départ simple, arrivée simple, remplacement). Pour chacun de ces axes, j’ai distingué trois phases : l’avant-changement, le changement, l’après-changement.
Avant le changement
Axe “savoir-faire”
Dans la mesure du possible, mettre en œuvre des moyens d’éviter le « bus factor » (une compétence détenue par un seul membre de l’équipe, qui entraîne un risque opérationnel en cas de disparition soudaine de la personne – cf https://fr.wikipedia.org/wiki/Facteur_d%27autobus).
Pour les membres de l’équipe de réalisation, les solutions ne manquent pas (pair programing, matrice de compétences…). En revanche, sur un poste de Product Owner, c’est un peu plus compliqué et fortement lié au contexte ; une solution envisageable est de faire participer d’autres membres de l’équipe à des tâches incombant généralement au Product Owner (priorisation du backlog produit, explication des éléments…).
Il peut être efficace de formaliser un processus d’onboarding (par exemple : présentation du contexte et du produit par le PO, présentation de l’agilité dans le contexte du projet par le SM, présentation de l’architecture et du socle technique par l’équipe de réalisation).
Axe “savoir-être”
En tant que Scrum Master, il faut garder à l’esprit que quoi qu’il arrive, la dynamique de groupe va changer. Dans la mesure du possible, il faut informer l’ensemble de l’équipe le plus tôt possible du changement afin d’éviter une dette émotionnelle liée au sentiment d’exclusion de la vie d’équipe.
Pendant le changement
Axe “savoir-faire”
Dans le cas d’un remplacement ou d’une arrivée, il ne faut pas précipiter le recrutement ! Il faut prendre le temps d’examiner les CV, en équipe (nous y reviendrons dans l’axe savoir-être), de suivre un processus de recrutement suffisamment robuste pour limiter les « erreurs de casting ». Par exemple, pour les développeurs que nous recevions, nous avions mis en place un Coding game que le candidat avait 2 jours pour faire avant de le rencontrer et de discuter de la solution choisie.
Il peut être utile de prévoir une période de transition entre le titulaire et son remplaçant (notamment s’il est le seul à détenir la compétence sur son domaine) ; ou dans le cas d’un départ non remplacé, identifier la ou les personnes reprenant les tâches du partant.
Au-delà du biseau (qui n’est pas toujours possible), il est important que l’équipe prenne le temps d’intégrer le nouveau : être formé par un membre pérenne de l’équipe est parfois plus efficace que l’être par la personne en partance (cela permet entre autres de plus facilement créer des liens).
Axe “savoir-être”
Dans le cas d’un remplacement ou d’une arrivée, il est intéressant d’intégrer l’ensemble de l’équipe dans la boucle de la sélection du ou des candidats, peu importe les rôles (éviter la cloison « les développeurs reçoivent les développeurs, les Product Owners reçoivent les Product Owners »).
Il est impossible d’être totalement certain que l’intégration se fera avec succès, cependant le fait d’avoir un maximum de personnes de l’équipe rencontrant le candidat a plusieurs avantages :
- la cohésion et le sentiment d’inclusion et de responsabilisation sont renforcés
- les risques liés à une incompatibilité au niveau de l’état d’esprit sont réduits
Après le changement
Axe “savoir-faire”
Il est important d’actualiser le cadre de l’équipe ! Il faut clarifier les attentes (give & take matrix) car il est possible que les attentes implicites de l’équipe envers le prédécesseur soient reportées sur son remplaçant. De par son vécu et son expérience, dans le rôle et/ou au cours d’autres projets, il est probable qu’il y ait des malentendus. Il en est de même dans le cas d’un départ non remplacé (clarifier pour tous qui reprendra le rôle occupé par le partant), ou d’une arrivée (clairement établir les attentes pour le nouveau venu).
Il faut également partager le workflow du sprint (quand ont lieu les rituels d’équipe, Scrum ou non, et à quelle fréquence). Dans l’exemple cité en introduction, la fréquence de l’affinage de backlog établie avec l’ancien Product Owner était trop élevée pour le nouveau Product Owner. Clarifier le cadre plus tôt aurait pu permettre d’éviter ce problème.
Axe “savoir-être”
Il faudra être particulièrement vigilant aux interactions et à la nouvelle dynamique au sein de l’équipe. Je pense que c’est une erreur de considérer qu’un départ, une arrivée, ou un remplacement n’aura qu’un impact limité sur cette dynamique. Il peut même arriver que l’équipe soit complètement bouleversée par la modification.
On pourra prévoir quelques ice breakers (une version modifiée du jeu du triangle durant laquelle on ajoute/retire des participants est un bon moyen d’aider l’équipe à comprendre qu’un changement dans le système aura un impact sur la dynamique), et/ou choisir un format de rétrospective privilégiant le travail par groupes (utiliser un tirage au sort pour la formation des groupes afin d’éviter les associations par affinités et favoriser l’intégration du nouvel arrivant).
Un modèle qui peut être très utile
Le modèle de Tuckman (sur lequel je me suis beaucoup appuyé) décrit la vie des équipes en 4 étapes non linéaires (à noter qu’une 5e a été rajoutée récemment). Il est non linéaire, car une équipe ne passe pas obligatoirement à l’étape suivante, peut revenir dans une étape par laquelle elle est déjà passée et peut rester indéfiniment dans une même étape.
Voici ces étapes :
- Forming : L’équipe est nouvelle, les membres apprennent à se connaitre et à vivre/travailler ensemble.
- Storming : Des tensions apparaissent, les membres découvrent les limites les uns des autres, les conflits sont très présents.
- Norming : Se connaissant dorénavant mieux, l’équipe a un cadre et travaille ensemble de manière harmonieuse. Il n’est pas impossible qu’il y ait des conflits ; l’équipe sait y faire face.
- Performing : La phase durant laquelle « tout roule » ! Le cadre qui évoluait encore assez fréquemment durant la phase précédente est maintenant stable, il y a très peu de conflits.
- BONUS Adjourning : Toutes les belles choses ayant une fin, il est temps de se dire au revoir. L’équipe, après cette belle aventure, se sépare.
(Source de l’image : https://alltogether.be/index.php/2018/04/15/diriger-une-equipe-de-projet-cest-aussi-en-comprendre-sa-dynamique-modele-de-tuckman/)
Parfois, il peut d’ailleurs être conseillé d’ajouter du sang neuf dans une équipe pour relancer une dynamique perdue à cause de la routine du quotidien (phase de performing qui dure et entraîne une certaine zone de confort). Dans d’autres cas, on peut identifier une personne “toxique” qui ne joue pas le jeu de la coopération, dans ce cas il est également conseillé de questionner l’avenir de cette personne dans l’équipe (afin de tenter de stopper un storming qui dure) !
Limiter l’impact des changements
J’ai constaté qu’un changement dans le groupe que j’accompagnais, qui selon moi, était dans une phase de norming ou de performing, le ramenait dans une phase de storming. Mon but, à travers mon accompagnement sur les différents axes et les différentes phases est de limiter autant que possible la durée de la phase de storming pouvant survenir lors d’une modification de la composition de l’équipe.
Il ne faut surtout pas oublier de prendre du recul ! En effet, dans notre rôle, faire face à plusieurs stormings peut être moralement éprouvant. Il peut être judicieux de faire appel, si possible, à d’autres Scrum Masters ou Coachs pour animer les ateliers.
Conclusion
En tant que Scrum Masters, notre cadre d’action est limité, et nous pourrons être amenés à faire passer des messages hors de l’équipe, notamment aux Managers. Il est primordial de faire comprendre que l’on gère de l’humain, et non des ressources. Remplacer un ensemble de compétences par un ensemble de compétences équivalent peut fonctionner, mais cela constitue un risque humain (« les individus et leurs interactions » !).
Intégrer l’ensemble de l’équipe et non imposer une décision prise par des personnes ayant avec elles des interactions limitées (voire inexistantes dans le pire des cas) évitera une perte de confiance du groupe dans le système.
Au cours de discussions autour de ce sujet, un point de vue intéressant m’a été soumis : chaque changement dans le groupe entraîne à nouveau un passage dans les premières phases du modèle (forming et storming), aussi rapide soit-il. On peut alors se poser la question : un turnover, aussi « minime » soit-il (remplacement bien anticipé d’une personne par une autre, comme le cas décrit en début d’article), constitue-t-il le changement d’une équipe existante ou la création d’une nouvelle équipe ?
© Néosoft
Toute reproduction interdite sans autorisation de la société.