J'avoue qu'au début, cela a généré chez moi une grande frustration, car je n'ai pas pour habitude de ne pas maîtriser mon sujet, et de plus, des choses qui à mes yeux devaient être simples à réaliser se révelaient en fait très complexes.

Ce sentiment a encore été augmenté par le fait que je ne dispose pas du temps nécessaire pour appréhender le code, car la totalité de mon temps est pris par la gestion des clients et la résolution des problèmes de l'équipe.

Mais au fil du temps, je me suis rendu compte que, assez paradoxalement, mon ignorance était en fait une force et me permettait de faire mon travail plus efficacement d'un point de vue agile.

L'un des préceptes fondamentaux de l'agilité dit en effet que c'est à l'équipe qui réalise le travail de prendre les décisions la concernant.

Or, vu que je ne maîtrise absolument pas mon sujet, je suis obligé de la consulter systèmatiquement afin de pouvoir répondre correctement aux questions.

De fait, je suis donc dans l'impossibilité totale de jouer les dictateurs et donc de prendre une décision arbitraire.

Cette consultation systèmatique de l'équipe de développement a eu plusieurs effets, aussi bien à mon niveau qu'au niveau de celui de l'équipe.

À mon niveau, j'ai eu tout d'abord l'impression de trahir la confiance de mon interlocuteur.

Cependant, je me suis rendu compte que ceux qui me posaient des questions préféraient largement que je temporise afin d'avoir la bonne réponse plutôt que je donne rapidement une réponse erronée.

Ensuite, j'ai également eu pendant quelques temps l'impression d'être inutile et de voler mon salaire.

Or, j'ai réalisé que je n'étais pas payé pour être une espèce d'encyclopédie ou un voyant capable de lire l'avenir mais bien pour permettre à mon équipe de travailler dans les meilleures conditions possibles.

Au niveau de l'équipe, les effets ont également été multiples.

Au moment de mon arrivé, ses membres manquaient de confiance dans leur hiérarchie, pour tout un tas de raisons, et le fait qu'ils soient consultés systématiquement a permis de rétablir, au vu du résultat de notre dernière rétrospective, un climat de confiance et une certaine joie au sein de l'équipe.

Ils sont également plus sereins, car ils savent de quoi demain, à défaut d'après-demain, sera fait, notamment en terme de planification.

À une exception prêt, car je n'ai pas eu le choix, ils ne sont en effet plus mis devant le fait accomplis mais sont au contraire décideurs en ce qui concerne les dates de livraisons et la façon dont le travail sera fait.

Enfin, vu qu'ils ont toutes les cartes en main, ils peuvent anticiper certain problèmes, notamment au cours des réunions quotidiennes, et cela nous a déjà permis d'éviter quelques écueils.

Donc pour conclure, si j'avais un conseil à donner à celui qui veut être un bon facilitateur agile, c'est d'être un minimum ignorant de tout ce qui touche aux projets de son équipe.

Cela lui permettra d'éviter, à condition d'avoir l'humilité de reconnaître son ignorance et de l'accepter, de prendre des décisions arbitraires ou de répondre maladroitement à des questions, et donc potentiellement d'engager à lui seul la responsabilité de son équipe.

De plus, cela lui permettra d'instaurer entre lui et son équipe une relation de confiance, ce qui fera que l'équipe sera moins stressée, plus sereine et donc plus apte à travailler efficacement.

Attention cependant, je ne suis pas en train de dire qu'il ne faut absolument rien comprendre à ce que fait l'équipe, bien au contraire.

L'ignorance doit être relative et tout juste suffisante pour voir s'instaurer une relation de dépendance qui évitera au facilitateur de se comporter en tant que tel, et non en dictateur !