Lorsqu’on devient Scrum master et qu’on a, comme moi, un background technique de chef de projet classique, il est nécessaire de changer de « mindset » pour devenir réellement agile.
Le chef de projet : une contrainte dans le système
La gestion de projet classique positionne une personne en tête de file : le chef de projet.
Cette personne est l’unique point d’entrée pour les parties prenantes (les managers, les clients, l’équipe de développement). Il sait tout, il voit tout, il a réponse à tout, il peut tout, il doit tout (vous pouvez compléter la liste…). Il paraît alors assez évident que ce rôle pose problème :
- qu’est-ce qui se passe si cette personne quitte l’organisation ? (départ, maladie, accident, mutation…)
- qu’est-ce qui se passe pour le produit si cette personne est (ou devient) insuffisamment performante (fonctionnellement, techniquement, manque de dispo…) ?
- qu’est-ce qui se passe si les relations avec les parties prenantes se dégradent ?
Là-aussi, on peut facilement compléter la liste.
Il est donc dangereux pour un projet ou un produit d’être confié à une seule personne. Les managers qui gèrent le staffing des équipes doivent veiller à ce que ça n’arrive pas. C’est de leur responsabilité.
Mon expérience personnelle m’a aussi fait entrevoir un autre problème avec le chef de projet. Il est un goulot d’étranglement qui ralentit les travaux et limite les solutions. Une demande métier ne doit pas être bloquée chez le chef de projet. Elle doit arriver directement à l’équipe qui connaît bien le produit, qui a les compétences techniques et la richesse créative pour imaginer une solution pertinente. Pour que ce soit efficace, l’équipe doit évoluer dans un cadre propice à la prise en charge rapide des demandes et à l’émergence de solutions concertées.
Scrum et Kanban offrent un tel cadre.
Confier les clés à l’équipe
Lâcher prise, c’est donner les clés à l’équipe Scrum.
Ses membres doivent « faire ». Ils doivent se confronter aux problématiques afin qu’il en résulte une émulation, une intelligence collective et un enrichissement des solutions proposées.
Scrum est un cadre prévu pour traiter des problématiques complexes. Les membres de l’équipe de développement sont des techniciens compétents, motivés et pluridisciplinaires qui vont embrasser cette complexité pour enrichir le produit. Si une personne fait des choix en amont pour réduire cette complexité, il court-circuite en quelque-sorte les bénéfices de Scrum. Pour éviter cet écueil, il suffit de respecter Scrum ! C’est le Product Owner qui transmet directement ses demandes à l’équipe sans intermédiaire à travers le backlog.
Le manque de confiance
Le principal frein à la mise en place de Scrum et à son succès est le manque de confiance.
On lâche prise lorsqu’on accepte le niveau de productivité et de qualité actuel de son équipe. Il est inutile de décréter unilatéralement un haut niveau de performances. L’équipe doit faire son cheminement pour progresser. L’amélioration doit être continue et recherchée en permanence. L’exigence de transparence prônée par Scrum permet cette inspection. Au final, avec la pratique et la répétition, l’équipe va améliorer ses capacités au fil du temps.
C’est aussi ce manque de confiance qui amène les managers à migrer leurs organisations vers du faux Scrum. Le symptôme le plus courant étant la conservation du rôle de chef de projet, souvent renommé et déguisé en Scrum Master.
Lâcher prise, c’est donc faire confiance !