Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Mike Cohn
Source : Self-Organizing Teams Are Not Put Together Randomly
Date : 05/06/2018


Traducteur : Fabrice Aimetti
Date : 02/12/2021


Traduction :

Self-organizing-teams-are-not-put-together-randomly-quote.png

La capacité d'une équipe à s'auto-organiser autour des objectifs qui lui ont été donnés est fondamentale pour toutes les approches agiles, y compris Scrum. En fait, le Manifeste Agile fait de l'auto-organisation des équipes un principe clé, affirmant que "les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées."

Pour décider de la meilleure façon d'atteindre l'objectif qui leur est assigné, certaines équipes décideront que toutes les décisions techniques importantes seront prises par une seule personne de l'équipe.

D'autres équipes décideront de répartir la responsabilité des décisions techniques en fonction des frontières techniques : notre expert en bases de données prend les décisions relatives aux bases de données, et notre développeur Python le plus expérimenté prend les décisions relatives à Python.

D'autres équipes pourront décider que la personne qui travaille sur la fonctionnalité prend la décision mais a la responsabilité de partager les résultats de la décision avec l'équipe.

Toutes les équipes agiles ne s'auto-organisent pas de la même façon

Il y a deux points importants ici :

  • Premièrement, toutes les équipes agiles ne choisiront pas de s'organiser de la même manière, et c'est bien ainsi.
  • Deuxièmement, l'utilisation de la sagesse collective de l'équipe conduira généralement à une meilleure façon de s'organiser autour du travail que de s'appuyer uniquement sur la sagesse d'un unique manager.

Le bénéfice de permettre à une équipe de s'auto-organiser n'est pas que l'équipe trouve une organisation optimale pour son travail qu'un manager aurait pu ne pas trouver. Au contraire, en permettant à l'équipe de s'auto-organiser, on l'encourage à s'approprier pleinement le problème de la réalisation de son travail.

Peut-on vraiment s'attendre à ce que les équipes agiles s'auto-organisent ?

L'une des critiques les plus fréquentes à l'égard des équipes auto-organisées est la suivante : "On ne peut pas mettre huit personnes au hasard ensemble, leur dire de s'auto-organiser et s'attendre à ce qu'il en résulte quelque chose de satisfaisant".

Eh bien, je ne sais effectivement pas si on peut mettre huit personnes au hasard ensemble et s'attendre à quelque chose, mais une équipe agile ne devrait pas être une collection aléatoire de personnes. En fait, ceux qui, au sein de l'organisation, sont responsables du lancement d'un projet Scrum doivent déployer beaucoup d'efforts pour sélectionner les personnes qui composeront l'équipe.

Le management exerce un contrôle subtil sur l'auto-organisation

Dans le document original décrivant Scrum, Takeuchi et Nonaka ont identifié le "contrôle subtil" (NdT : Les nouvelles règles de développement d'un nouveau produit) comme l'un de leurs six principes. Ils citent les décisions relatives au recrutement du personnel comme une responsabilité clé du management.

Sélectionner les bonnes personnes pour l'équipe projet tout en veillant à l'évolution de la dynamique de groupe et en ajoutant ou en retirant des membres si nécessaire [est une responsabilité clé du management]. "Nous ajouterions un membre plus âgé et plus conservateur à l'équipe si l'équilibre penchait trop vers le radicalisme", a déclaré un cadre de Honda. Nous choisissons soigneusement les membres du projet après une longue délibération. Nous analysons les différentes personnalités pour voir si elles s'entendent bien."

Intégrer les bonnes personnes dans l'équipe agile

Si vous êtes responsable du personnel ou si vous avez une influence sur la composition des équipes dans votre organisation, voici quelques-uns des facteurs à prendre en compte.

Inclure toutes les disciplines nécessaires dans les équipes agiles

En tant qu'équipe pluridisciplinaire, il est important que toutes les compétences nécessaires pour passer de l'idée à la fonctionnalité réalisée soient représentées au sein de l'équipe. Au départ, cela peut signifier que la taille de l'équipe est légèrement supérieure à celle souhaitée.

Mais, avec le temps, les membres d'une équipe Scrum vont acquérir certaines des compétences de leurs collègues. C'est un résultat naturel lié au fait de faire partie d'une équipe Scrum. Au fur et à mesure que certains membres de l'équipe développent des compétences plus larges, d'autres personnes peuvent être transférées dans d'autres équipes.

Le mélange des niveaux de compétences techniques dans les équipes agiles

Sous réserve de considérations liées à la taille de l'équipe, vous devez vous efforcer d'équilibrer les niveaux de compétences au sein de l'équipe. Si une équipe compte trois développeurs expérimentés et aucun développeur moins expérimenté, les développeurs expérimentés devront coder des fonctions à faible criticité qu'ils pourraient juger ennuyeuses.

Non seulement un développeur junior aurait pu trouver de telles fonctionnalités intéressantes à travailler, mais ce développeur aurait également bénéficié de l'apprentissage par l'association avec les développeurs seniors.

Équilibrer les connaissances du domaine dans les équipes agiles

Tout comme nous nous efforçons d'équilibrer les compétences techniques, nous devrions nous efforcer de trouver un équilibre entre ceux qui ont une connaissance approfondie du domaine dans lequel nous travaillons ou du problème que nous tentons de résoudre.

Cela ne veut pas dire que si nous avons la possibilité de constituer une équipe entièrement composée d'experts du domaine, nous ne devons pas la saisir. Nous devons plutôt tenir compte des objectifs à long terme de notre organisation.

L'un de ces objectifs est probablement la constitution d'une connaissance du domaine dans l'ensemble de l'organisation. Vous aurez du mal à atteindre cet objectif si vous placez tous les experts du domaine dans une seule équipe.

Rechercher la diversité dans les équipes agiles

La diversité peut signifier beaucoup de choses différentes : le sexe, la race et la culture n'en sont que trois parmi d'autres. La manière dont les personnes envisagent les problèmes, la façon dont elles prennent des décisions, la quantité d'informations dont elles ont besoin avant de prendre une décision, etc. sont peut-être tout aussi importantes.

Les recherches montrent que les équipes homogènes parviennent plus rapidement à un consensus que les équipes hétérogènes, mais elles y parviennent en omettant d'envisager toutes les options.

Tenir compte de la résistance lors de la constitution d'équipes agiles

Il faut du temps aux membres d'une équipe agile pour apprendre à bien travailler ensemble. Efforcez-vous donc de conserver ensemble les membres de l'équipe qui ont bien travaillé les uns avec les autres dans le passé. Lors de la formation d'une nouvelle équipe, tenez compte de la durée pendant laquelle les membres pourront travailler ensemble avant que certains ou tous soient dispersés sur d'autres engagements.

Quelques objections fréquentes concernant les équipes auto-organisées

Examinons quelques objections fréquentes à l'idée de faire confiance à une équipe pour s'auto-organiser.

Une personne influente va prendre toutes les décisions

On craint souvent qu'une personnalité influente, par exemple un tech lead, décide que l'auto-organisation signifie qu'il doit prendre toutes les décisions.

Ou encore, une personnalité influente va imposer sa volonté à l'équipe avant même que celle-ci ait eu l'occasion de discuter d'un problème.

Si vous remarquez que cela commence à se produire, prenez la personnalité influente à part et informez-la du problème. Faites-lui comprendre que même dans les situations où elle sait ce qu'il faut faire, elle doit parfois s'abstenir d'exprimer son opinion avant que les autres n'aient la possibilité de le faire.

Demandez-lui si elle pense que l'équipe prendrait la bonne décision si elle exprimait ses idées comme une simple opinion plutôt que comme une décision incontestable.

Faites appel à son aide en tant que mentor pour les autres - son travail ne doit pas seulement consister à s'assurer que les bonnes décisions sont prises, mais aussi que les membres de l'équipe se développent de telle sorte qu'ils prendront les bonnes décisions sur leurs prochains projets, où elle ne sera peut-être pas là pour eux.

Mon équipe attend du Scrum Master qu'il prenne le leadership.

Une deuxième objection fréquente est que l'équipe est trop passive pour s'auto-organiser elle-même et qu'elle attendra plutôt de son Scrum Master ou de son coach qu'il prenne le leadership de l'équipe et prenne les décisions importantes à sa place.

Si cela se produit, assurez-vous que les membres de l'équipe savent que le travail du Scrum Master consiste à les soutenir, et non à prendre des décisions à leur place. Si vous jouez le rôle de Scrum Master / membre de l'équipe, vous n'avez pas besoin de réprimer vos idées et de vous taire en permanence.

Cependant, vous devriez chercher des moyens d'impliquer les autres en ne prenant pas la décision à chaque fois. Par exemple, essayez de poser des questions aux autres avant de donner votre avis.

L'équipe est trop jeune pour s'auto-organiser

Une troisième crainte est que les membres de l'équipe soient trop jeunes pour s'organiser.

Je n'ai jamais rencontré d'équipe trop jeune pour s'auto-organiser. Si les membres de l'équipe ont assez d'expérience pour construire un produit logiciel, ils ont probablement assez d'expérience pour comprendre comment s'organiser.

Si ce n'est pas le cas, offrez à l'équipe une formation ou un accompagnement.

Souvent, cette objection masque en réalité l'objection suivante : "Je ne fais pas confiance à l'équipe pour s'auto-organiser de la manière dont je le souhaite". C'est dommage. Exercez un contrôle subtil sur l'équipe en choisissant les personnes qui la composent et en définissant l'objectif que vous lui assignez, mais pas sur la façon dont elle s'auto-organise pour effectuer son travail au jour le jour.

Quelle est votre propre expérience à ce sujet ?

Votre équipe a-t-elle accepté l'idée de s'auto-organiser elle-même autour de son travail ? Si non, quels problèmes avez-vous rencontrés ? Comment les avez-vous surmontés ? Veuillez partager vos réflexions dans les commentaires ci-dessous.