Tout comme le personnage principal de sixième sens, j’ai un pouvoir. Le pouvoir de voir et d’entendre les gens morts par agilité.
Dans les complaintes qu’ils hurlent les nuits de pleine lune en courant nus dans les forêts, le logo d’une grande ESN tatoué sur l’aine, il y’en a une dont j’aimerai parler : “je suis un expert avec 15 ans d’expérience, le Scrum Master s’en fiche et me considère au même niveau qu’un junior qui sort de l’école ! Bouh !”.
Ce qui est vrai. Et … faux ! Voyons ça de plus près.
L’expertise experte
Une véritable expertise couvre généralement un domaine bien particulier. Tout comme l’expérience.
Si je prends mon exemple, j’ai plus de 15 ans d’expérience de développeur PHP. Pourtant, un développeur junior qui a fait 2 ans de Java (le pauvre) sera plus efficace que moi en Java, même si mon expérience de développeur, ayant vu plus d’un langage, me permet de rester pertinent sur des concepts de programmation.
Et puis, un langage, ça s’apprend assez vite.
Mais alors pourquoi ?
Pourquoi donc une équipe agile essaie-t-elle d’effacer cet expertise ?
En fait, je ne pense pas qu’un agiliste digne de ce nom demande à un expert de se taire, ou aux autres membres de l’équipe de ne pas tenir compte de son avis. Ce serait bête et contre productif.
“Scrum ne reconnaît aucun titre aux membres de l’équipe de développement”
Scrum Guide
Il n’y a donc pas de “lead dev”, “lead tech”, “architecte”, “dba”, etc.
Mais… Scrum n’oublie pas pour autant les compétences :
“Les membres de l’équipe de développement peuvent détenir individuellement des compétences et des centres d’intérêts spécifiques, mais c’est l’équipe de développement dans son ensemble qui est tenue responsable”
Scrum Guide
Ce que Scrum cherche à faire en effaçant les titres dans une équipe, c’est à rendre chacun responsable de ce que l’équipe délivre.
Si une seule personne est capable de faire quelque chose, alors il ou elle devient un risque énorme pour l’équipe, le produit et donc l’entreprise. Nous cherchons donc à responsabiliser chacun, sur l’objectif du sprint. On ne doit pas accepter, au sein d’une équipe Scrum, le rejet de la faute : “c’est machin qui devait faire ça”. Le Scrum Master pourrait répondre : “Et voyant que ce n’était pas fait, qui a pris le relai ?” S’en suivent généralement des protestations, des excuses plus ou moins bien trouvées, ou un silence de mort.
Mentor ! Mentor ! T’es qu’un mentor !
Quelle position prendre quand on est expert.e dans une équipe agile ? Déjà, il faut être humble. Savoir que nous ne sommes pas experts sur tout et qu’il arrive que même dans notre domaine de prédilection un autre esprit, même jeune, puisse nous apporter un regard différent.
Le positionnement de n’importe quel.le expert.e dans une équipe, doit être celui de mentor. Encore plus si cet.te expert.e est temporaire dans l’équipe. J’ai eu cette discussion avec Allen Holub il y a quelques jours sur Twitter :
C’est l’expert.e qui va proposer et expliquer les bonnes pratiques, organiser des kata, etc. Il ou elle peut aussi challenger et proposer des solutions.
Le but étant de ne pas être un super-héro, mais un maître Jedi.
C’est un changement de rôle et de positionnement sur lequel l’agiliste (coach, scrum master ou autre) de l’équipe peut l’accompagner.
Tout est une question de posture. Comment arrivez-vous à vous positionner, si vous vous êtes expert, ou si au contraire vous devez vivre avec un expert qui n’est que ça ?
Au fait, voici les liens vers les tweet que j’ai mentionné : 1 et 2. Aussi, un rappel du lien vers le Scrum Guide d’où j’ai extrait les citations.
Pour la photo de vignette : Hutomo Abrianto