Équipes auto-organisées – voici comment ça fonctionne

La capacité à s'auto-organiser est fondamentale dans toutes les méthodes agiles, y compris Scrum. En fait, les équipes auto-organisées constituent l'un des principes fondamentaux du Manifeste Agile, qui stipule que « les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées ».

Lorsqu'il s'agit de déterminer la meilleure façon d'atteindre un objectif visé, certaines équipes choisiront de confier les décisions sur toutes les questions techniques importantes à une seule personne de l'équipe.

D'autres équipes choisiront de répartir la responsabilité des décisions techniques selon les domaines d'expertise : l'expert en bases de données prend les décisions relatives aux bases de données et le développeur ayant le plus d'expérience en Python prend les décisions concernant Python.

D'autres équipes encore peuvent choisir que la personne travaillant sur une fonctionnalité donnée puisse prendre la décision, mais qu'elle doive communiquer les résultats de cette décision à l'équipe.

Toutes les équipes agiles ne s'auto-organisent pas de la même manière

Il y a deux points principaux à retenir :

• Toutes les équipes agiles ne s'organiseront pas de la même manière, et c'est tout à fait normal.
• On peut mieux organiser le travail en exploitant les connaissances collectives de l'équipe, plutôt qu'en se fiant uniquement au savoir d'un seul responsable.
  L'avantage des équipes auto-organisées n'est pas que l'équipe trouve une façon optimale d'organiser son travail qu'un manager aurait oublié de leur montrer. Permettre à l'équipe de s'auto-organiser a plutôt l'avantage de l'encourager à se sentir responsable de l'accomplissement de son travail.

Peut-on vraiment attendre des équipes agiles qu'elles soient auto-organisées ?

Une critique répandue concernant les équipes auto-organisées est : « On ne peut pas simplement réunir huit personnes au hasard, leur dire de s'auto-organiser et s'attendre à un résultat positif ».

Eh bien, je ne suis pas certain que réunir huit personnes au hasard et s'attendre à un résultat positif ne soit pas problématique en soi, mais une équipe agile ne devrait de toute façon pas être composée d'un groupe de personnes assemblées au hasard. En réalité, les responsables de l'entreprise chargés de lancer un projet Scrum devraient sélectionner les membres de l'équipe avec soin.

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

Dans l'article original sur Scrum, The New New Product Development Game, Takeuchi et Nonaka ont identifié le « contrôle subtil » comme l'un des six principes. Les décisions relatives au personnel y sont mentionnées comme l'une des principales responsabilités du management.

Choisir les bonnes personnes pour une équipe projet tout en observant les changements de dynamique de groupe, et si nécessaire ajouter ou retirer des membres de l'équipe, fait partie des responsabilités principales du management.

« Nous intégrons un membre plus expérimenté et un peu plus conservateur dans l'équipe si celle-ci devient trop radicale », expliquait un manager chez Honda. « Après mûre réflexion, nous sélectionnons nos membres de projet avec beaucoup de soin. Nous analysons les différentes personnalités pour déterminer si elles sont compatibles entre elles. »

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

Si vous êtes responsable RH ou si vous influencez d'une autre manière la composition des équipes dans votre entreprise, voici quelques points à considérer :

Tenez compte de toutes les disciplines nécessaires aux équipes agiles
Pour les équipes pluridisciplinaires, il est important que toutes les compétences nécessaires, de l'idée jusqu'à la fonctionnalité implémentée, soient représentées dans l'équipe. Cela peut signifier que l'équipe sera initialement un peu plus grande que souhaité.

Mélange de différents niveaux de qualification technique dans les équipes agiles

En ce qui concerne la taille de l'équipe, on devrait toujours essayer d'établir un équilibre entre les différents niveaux de qualification au sein de l'équipe. Si une équipe dispose de trois développeurs seniors et n'a pas de programmeurs moins expérimentés, les développeurs expérimentés doivent aussi programmer des fonctionnalités moins importantes qui risquent de les ennuyer.
Non seulement un programmeur junior aurait peut-être été ravi de faire ce travail, mais il aurait certainement profité de la collaboration avec son collègue expérimenté.

Équilibre de l'expertise métier dans les équipes agiles

En plus d'un équilibre des compétences techniques, nous devrions également établir un bon équilibre entre les membres de l'équipe qui possèdent une expertise métier approfondie et le problème que nous essayons de résoudre.
Cela ne veut pas dire que nous ne devrions jamais avoir une équipe composée entièrement d'experts métier si nous en avons l'occasion. Au lieu de cela, nous devrions plutôt considérer les objectifs à long terme de l'organisation.
L'un de ces objectifs est certainement le développement de l'expertise métier dans l'entreprise. Atteindre cet objectif sera difficile si tous les experts métier sont dans une seule et même équipe.

Diversité dans les équipes agiles

La diversité peut signifier beaucoup de choses : le genre, l'origine et la culture n'en sont que quelques exemples. Mais il peut être tout aussi important de considérer comment les membres de l'équipe abordent différemment les problèmes, comment ils prennent leurs décisions, de combien d'informations ils ont besoin pour prendre une décision, etc.
Des recherches ont montré que les équipes homogènes atteignent le consensus plus rapidement que les équipes hétérogènes. Cependant, elles y parviennent uniquement parce qu'elles ne sont pas capables de considérer toutes les options possibles.

Persévérance dans la composition des équipes agiles

Les membres d'une équipe agile ont aussi besoin de temps pour apprendre à bien travailler ensemble. Essayez donc de garder dans la même équipe les membres qui ont bien collaboré par le passé. Lorsque vous constituez une nouvelle équipe, réfléchissez également à combien de temps les membres pourront probablement travailler ensemble avant que certains ou même tous doivent retourner à d'autres obligations.

Objections courantes contre les équipes auto-organisées

Il existe plusieurs objections contre l'auto-organisation des équipes :

1) Une personne dominante prend toutes les décisions

Une crainte fréquente est qu'une personnalité dominante – par exemple le responsable technique – décide que l'auto-organisation signifie que c'est lui ou elle qui prend toutes les décisions.

Ou bien une personnalité dominante impose son opinion à l'équipe avant même que celle-ci ait eu la chance de discuter du sujet.

Dès que vous observez ce genre de comportement, prenez la personne concernée à part et expliquez-lui le problème. Faites comprendre à cette personne que, même si elle pense connaître la bonne solution, elle devrait parfois retenir son opinion et donner aux autres l'occasion de partager leurs réflexions.

Demandez à cette personne si elle pense que l'équipe serait capable de prendre la bonne décision si elle formulait ses pensées plutôt comme une opinion que comme une décision incontestable.

Faites appel à cette personne comme mentor pour l'équipe – son rôle ne devrait pas seulement être de s'assurer que les bonnes décisions sont prises, mais plutôt que les membres de l'équipe grandissent et soient capables de prendre les bonnes décisions dans de futurs projets où cette personne ne sera peut-être pas là pour eux.

2) Mon équipe s'attend à ce que le Scrum Master organise tout

Une deuxième préoccupation que beaucoup ont est que l'équipe est trop passive pour l'auto-organisation et s'attend plutôt à ce que le Scrum Master ou le coach prenne les devants et prenne les décisions importantes à leur place.

Si cela se produit, assurez-vous que les membres de l'équipe comprennent que le travail du Scrum Master est de les soutenir, et non de prendre les décisions à leur place. Si vous êtes vous-même dans le double rôle de Scrum Master/membre de l'équipe, vous n'avez bien sûr pas à toujours réprimer votre opinion et pouvez tout à fait vous exprimer.

Dans tous les cas, cherchez des moyens d'impliquer les autres plutôt que de prendre toutes les décisions seul. Par exemple, demandez d'abord aux autres membres de l'équipe avant de donner votre propre avis.

3) L'équipe est trop inexpérimentée pour l'auto-organisation

Une troisième objection contre l'auto-organisation est souvent que les équipes sont trop inexpérimentées pour s'auto-organiser.

Je n'ai encore jamais vu d'équipe trop inexpérimentée pour l'auto-organisation. Si les membres de l'équipe ont assez d'expérience pour construire un produit logiciel, ils ont très probablement aussi assez d'expérience pour trouver comment travailler de manière auto-organisée.

Si ce n'est pas le cas, soutenez l'équipe avec de la formation et du coaching.

Dans la plupart des cas, cette objection signifie simplement qu'on ne fait pas confiance à l'équipe pour être aussi auto-organisée qu'on le souhaiterait. Tant pis ! Exercez un contrôle subtil sur l'équipe ; et ce, grâce à la composition de l'équipe et à l'objectif que vous lui fixez, et non par le « comment » du travail quotidien de l'équipe.