L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Le Valtech Mag nous parle du chef de projet dans un fonctionnement agile. Le sujet mérite que l'on s'y attarde car, comme le dit à juste titre l'article "l’agilité est bel et bien en train de révolutionner le rôle du chef de projet".
Le diagnostic de l'impact des méthodes agiles est, pour la plupart, bien vu et amplement détaillé.
Citons en vrac :

• "la construction d’un système logiciel n’est pas un exercice de prévision. C’est un exercice d’adaptation."


• "L’équipe décide de ce qui est faisable et de ce qui ne l’est pas. Elle décide qui va s’atteler à quelles tâches"


• "L’une des caractéristiques des projets agiles est de ménager des voies de communication très ouvertes entre les développeurs et le client."


• "La progression doit se mesurer aux résultats que génère le projet et non au nombre d'heures qu'y consacre l'équipe."


• "La vision émane d’un effort collectif."

Si l'article a pour but d'intéresser aux méthodes agiles des personnes qui n'en ont jamais entendu parler, il peut remplir, je pense, dans une large mesure, son objectif.
S'il espère avoir fait une analyse fine du problème organisationnel que pose la transition méthodologique, c'est, à coup sûr, un raté.

La première réflexion qui m'est venue à l'esprit est : mais pourquoi tiennent-ils tant à maintenir cette notion de chef de projet (ou peu importe comment on l'appelle) alors que la plupart (pour ne pas dire la totalité) des méthodes qui se disent agiles ne définissent pas un tel rôle ?
Et pourtant, l'auteur (que je ne peux nommer car l'article n'est pas signé) a bie n compris ce principe quand il (ou elle ?) écrit "Dans un projet agile, des rôles — et non des tâches — sont assignés aux membres de l’équipe."
J'en arrive même à me demander si cette personne a lu le manifeste agile et ses principes. Si tel est le cas, il faudrait me dire à quelq moment il y est question de quelque chose qui pourrait se rapprocher plus ou moins d'un chef de projet...
Je crois surtout que cette nécessité de conserver un chef de projet est un artefact culturel dans un monde où toute organisation qui ressemble de près ou de loin à du communisme est regardée d'un très mauvais oeil.

Autre fantastique contradiction : "Plus les membres de l’équipe seront polyvalents, plus il sera facile de faire face au départ inopiné de l’un d’entre eux."
Lire ça de la part de quelqu'un qui met une telle emphase sur un rôle de chef de projet joué par une unique personne dont l'absence se révèlerait critique pour la survie du projet, c'est tout simplement incroyable !
Si l'auteur a compris que "Protéger l’équipe suppose également d’éviter qu’elle ne devienne trop dépendante d’une seule personne.", il/elle n'a pas vraiment intégré que la seule vraie façon d'y parvenir c'est de ne pas trop compter sur quelqu'un en particulier.

Bien sûr, une équipe a toujours besoin d'une personne qui mette un peu d'huile dans les rouages de la machine pour lui permettre d'avancer. Certains l'appellent coach, d'autres l'appelent scrummaster. Mais la personne qui joue ce rôle ne doit surtout pas prendre l'ascendant sur les membres de l'équipe au point d'établir un semblant d'autorité. Je ne crois donc pas que son rôle "consiste à délimiter les droits et les responsabilités de chaque rôle en collaboration avec la personne chargée de l’exécuter" ni qu'"il ne devra pas craindre de redistribuer les rôles". En fait, il (ou elle) doit être capable d'amener l'équipe à s'auto-gérer. Les décisions doivent venir du collectif : "the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Si on pousse le raisonnement un peu plus loin le bon "chef de projet", c'est celui dont on n'a plus besoin...