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 !
5 réactions
1 De Alexandre Salomé - 06/02/2012, 17:35
J'ai souligné en fluo les phrases "s'engager quand on ne sait pas de quoi on parle, c'est con" et aussi "quand on ne sait pas, il faut le dire et ne pas avoir peur".
2 De Fred Blanc - 14/02/2012, 13:09
Merci pour ce retour d'expérience, Fred. C'est un bon exercice, il faudra que je pense aussi à faire la même chose
3 De JoeBzh - 15/02/2012, 23:37
Et moi plus je lis ce blog, plus il me comble... mon ignorance... :o)
4 De las92i - 17/02/2012, 14:17
Aixia System est un niveau d'architecture très intéressant, et les développeurs en place que je connais bien sont très bons et efficaces. Ne t'inquiète pas, il est rare de trouver des personnes capables d'avoir le niveau exigé par ce projet très complexe car c'est un niveau d'architecte web.
En tant que CTO, tu ne peux pas avoir le niveau technique nécessaire mais ce n'est pas le rôle que tu dois en effet te donner, à chaque son savoir faire. Tu peux avoir confiance en ces développeurs et à Philippe aussi qui maîtrisent très bien le sujet et qui représentent à mes yeux les seuls développeurs (niveau architecte pour l'un d'entre eux) de très bon niveau que j'ai découvert à Lyon (avec un autre à M6 Web.
Bon courage, belle analyse et bonne conclusion.
5 De mageekguy - 18/02/2012, 23:04
@las92i : Le logiciel est loin d'avoir la complexité technique d'autres projets sur lesquels j'ai travaillé, et le fait que je ne sois pas parvenu à rentrer dans le projet n'a donc rien à voir avec cela.
C'est juste que j'ai eu d'autres chats à fouetter, si je peux m'exprimer ainsi, et qu'en conséquence, je n'ai jamais pris le temps de rentrer dans le projet et cela d'autant plus parce que je me suis rendu compte que c'était loin d'être un problème.
Et ta remarque sur le fait qu'un CTO ne peux pas avoir m'a bien fait rire...