Une équipe stable est une équipe dans laquelle la composition de l’équipe ne change pas souvent et est, au contraire, cohérente au fil du temps. Pourquoi devriez-vous vous en soucier ?
In Agile, Where Change is Valued, Why Is a Stable Team So Important? par Mark Levison
https://agilepainrelief.com/blog/in-agile-where-change-is-valued-why-is-a-stable-team-so-important.html
Une équipe stable est une équipe dans laquelle la composition de l’équipe ne change pas souvent et est, au contraire, cohérente au fil du temps.
Pourquoi devrions-nous nous en soucier ? Scrum n’est-il pas comme le basket-ball où vous pouvez changer les joueurs sur le terrain à chaque fois qu’il y a une interruption ? Découvrons-le…
Les équipes très performantes, ou les équipes qui font des choses avec une qualité incroyablement élevée, est l’objectif de beaucoup de ceux qui arrivent dans Scrum en s’attendant à obtenir des performances incroyables de leur système. Mais construire une équipe performante à partir de zéro prend du temps. L’image populaire du modèle de formation d’équipe de Tuckman montre une équipe passant par les étapes de formation/constitution à tension à normalisation puis exécution/production. (Mise en garde : l’image existe pour simplifier la compréhension. La dynamique d’une vraie équipe sera plus désordonnée qu’on ne le montre ici).
Il est facile de former une équipe, puis de passer à toute vitesse à travers la phase de tension. La phase de tension est caractérisée par des conflits, car les gens appréhendent les rôles et les relations.
La normalisation et l’exécution sont considérablement plus difficiles dans les équipes instables, et elles s’y produisent à plusieurs reprises. Chaque fois qu’il y a un changement dans la composition de l’équipe, il y a de fortes chances de revenir à la phase de tension en raison de la nouvelle dynamique interpersonnelle. J’avertis les organisations que, lorsqu’elles doivent apporter des changements, il y a un risque que le changement les renvoie non seulement à la tension, mais qu’il soit également suffisamment dommageable pour que l’équipe ne s’en remette pas du tout. Combien de fois voulez-vous tenter la chance ?
La plupart des travaux de la littérature académique traitent de la familiarité, et non de la stabilité. Grosso modo, cela signifie « nous avons suffisamment travaillé ensemble dans le passé pour nous comprendre en tant qu’individus ». Que vous l’appeliez familiarité ou stabilité, la prémisse est la même : Les gens ont besoin de temps pour apprendre à se comprendre et à communiquer efficacement, la clé est que la familiarité est plus faible que la stabilité.
Comment des équipes stables affectent la qualité
Lorsque les membres de l’équipe se connaissent, vous en voyez les bénéfices dans le niveau de qualité du travail de cette équipe. Prenons, par exemple, la chirurgie. J’espère que la plupart des équipes Scrum font un travail moins risqué que les interventions chirurgicales, mais la chirurgie (pour des raisons évidentes) est bien étudiée, ce qui nous donne une bonne source de données.
Il y a un chirurgien orthopédiste qui opère plus de 500 chirurgies du genou par an, soit 2,5 fois plus que n’importe qui d’autre dans son hôpital. Il a mis en place des dizaines de techniques pour améliorer ses interventions. Au lieu de travailler avec un groupe changeant d’infirmières et d’anesthésistes, il dispose de deux équipes dédiées et il dit que « peu des méthodes qu’il a mises au point seraient pratiques si elles n’étaient facilitées par la familiarité de travailler avec les mêmes personnes tous les jours ».[1]
Tuer le patient est l’erreur ultime. Ne pas les tuer est une barre assez basse de succès côté qualité. Néanmoins, les chirurgiens cardiaques qui travaillaient dans plusieurs hôpitaux mais maintenaient des équipes stables avaient un taux de mortalité plus faible, même avec davantage d’opérations chirurgicales effectuées. Les auteurs de l’étude ont attribué ce niveau de qualité du travail en partie à la familiarité de l’équipe.[2]
L’aviation et l’aéronautique sont également des domaines largement étudiés avec des données qui soutiennent l’importance d’équipes stables. « 73 % des accidents pour lesquels des informations étaient disponibles se sont produits le premier jour où le commandant de bord et le copilote ont volé ensemble. »[3]
Une étude de la NASA a révélé que les équipages fatigués qui avaient l’habitude de travailler ensemble commettaient environ deux fois moins d’erreurs que les équipages composés de pilotes reposés qui n’avaient jamais volé ensemble avant.[4]
Et pour redescendre sur terre, une étude de la société d’externalisation de logiciels Wipro a révélé qu’une familiarité accrue réduisait les défauts de 19%.[5]
Comment les équipes stables affectent-elles la prévisibilité ?
Il n’y a pas de données sur la prévisibilité des chirurgiens, ce qui, à mon avis, pourrait être une bonne chose.
L’étude de Wipro a montré que « les écarts par rapport au budget ont diminué de 30% ». Ignorons l’accent mis sur le budget, alors qu’il devrait s’agir de la construction du bon produit, mais cela montre que la familiarité facilite la prévisibilité.
Dans l’étude « Impact of Agile Quantified »[6], Larry Maccherone a montré que les équipes stables avaient une prévisibilité supérieure de 40%.
Incidence des équipes stables sur la productivité
Nous ne devrions pas vraiment courir après « plus de fonctionnalités produites plus rapidement » comme résultat. Au lieu de cela, nous devrions nous concentrer sur une meilleure valeur et de meilleurs résultats. Cela dit, je n’ai jamais rencontré quelqu’un qui ne voulait pas voir son équipe réaliser plus de choses.
Chez Wipro, « nous avons également constaté que la familiarité était un meilleur indicateur prédictif de performance que l’expérience individuelle des membres de l’équipe ou des managers de projet ». Des données plus impressionnantes du « The Impact of Agile Quantified » ont montré que les équipes stables sont 60% plus productives. Dans de nombreuses organisations, c’est le levier qui nous permet d’aller vers les équipes stables.
N’oubliez pas de vous concentrer sur les résultats plutôt que les productions.
Pourquoi les équipes stables fonctionnent-elles ?
L’esprit d’équipe (ou modèle mental partagé). Nous savons ce que les autres savent et sur qui on peut compter pour faire certaines choses.- La coordination et une meilleure collaboration sont plus faciles lorsque nous nous connaissons bien.
- Flexibilité. L’esprit d’équipe et la capacité à collaborer permettent à l’équipe de s’adapter plus facilement lorsque des changements plus importants dans les produits se matérialisent.
- L’amélioration continue nécessite les mêmes personnes, ainsi nous ne continuons pas à réexaminer des choses que nous avons apprises il y a des mois.
- L’esprit d’équipe et le processus d’apprentissage continu approfondissent la connaissance de l’équipe de son domaine de travail, ses compétences techniques et sa connaissance de sa base de code.
Pourquoi les équipes stables peuvent-elles être difficiles ?
Donc, si les équipes stables sont une bonne chose, qu’est-ce qui rend difficile de les atteindre ?
Organisation matricielle. Lorsque les membres de l’équipe relèvent de différents managers, chaque manager aura des agendas/besoins différents. Par conséquent, les membres de l’équipe peuvent être réaffectés, même si une solution plus élégante pourrait fonctionner et leur permettre de rester dans l’équipe.
Dépendance à l’égard d’experts externes. Lorsqu’une équipe fait appel à une aide extérieure pour acquérir des compétences spécialisées, elle essaie souvent d’inclure « l’expert » dans l’équipe. Cela fonctionne rarement bien. Une meilleure solution est de les utiliser comme consultant/coach, mais de ne pas leur faire faire le travail pratique. Au lieu de cela, ils enseignent aux membres de l’équipe comment effectuer le travail en question, en maintenant la dynamique de l’équipe et en améliorant les compétences en même temps.- Politique organisationnelle. Berk. J’en ai assez dit.
Quand des équipes stables ne sont-elles pas souhaitables ?
Dans certains cas, lorsque la complexité du problème (voir : La complexité et le cadre Cynefin) est telle que les compétences des membres de l’équipe évoluent rapidement, les équipes stables peuvent ne pas être une priorité. Dans ce cas, nous pourrions sacrifier les performances, la réduction des erreurs, etc., pour avoir une chance de nous attaquer d’abord au problème. Les problèmes de cette nature sont incroyablement rares. S’il vous plaît contactez-moi si vous pensez en avoir trouvé un, je veux vérifier.
Reconstruire les équipes
Parfois, le produit sur lequel on travaille n’est plus aussi important et l’organisation doit réduire les coûts et déplacer les membres de l’équipe. Redgate Software a mis au point une technique permettant d’équilibrer la stabilité et l’adaptation à l’évolution des conditions du marché [7], où l’organisation prend chaque année des décisions stratégiques quant aux domaines sur lesquels se concentrer. Une fois les décisions prises, les membres de l’équipe peuvent choisir eux-mêmes l’équipe dans laquelle ils souhaitent travailler.
Préférez une appartenance stable à une équipe plutôt qu’un assemblage changeant de personnes. Lorsque vous n’avez pas le choix, examinez les circonstances et assurez-vous que l’organisation comprend ce à quoi elle renonce.
[1] The Firm Specificity of Individual Performance: Evidence from Cardiac Surgery – Robert S. Huckman and Gary P. Pisano
[2] A Review of Flightcrew-Involved, Major Accidents of U.S. Air carriers 1978 Through 1990 – NTSB
[3] https://hbr.org/2009/05/why-teams-dont-work
[4] Team Familiarity, Role Experience, and Performance: Evidence from Indian Software Services – Robert S. Huckman, Bradley R. Staats, David M. Upton
[5] https://www.infoq.com/presentations/agile-quantify/
[6] https://hbr.org/2013/12/the-hidden-benefits-of-keeping-teams-intact
DantotsuPM.com 