Première question : C’est quoi déjà ce job là ?

La définition du rôle semble être variable « à la tête du client »et « à la tête de l’emploi ».

Pour certains « On peut voir le ScrumMaster comme la déclinaison agile du chef de projet », « Voire un sous-rôle de chef de projet » Car: « Plutôt que de planifier, de contrôler et de diriger, le gestionnaire de projet Agile facilite et agit comme mentor et leader au sein d’équipes auto-organisées. »

Pour d’autres : « Il n'est pas nécessaire pour un ScrumMaster de bien connaître le domaine de l'application, ni d'être un expert technique. »

Il y a des visions mixtes : « Celui qui le joue peut, ponctuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela doit rester limité : c'est un rôle à plein temps. ».

Mais au fait qui va le payer ?

Voici une vingtaine d’années déjà, le RAD, première méthode Agile, s’avisant que les échecs de projets avaient essentiellement pour cause le manque de communication entre utilisateurs et informaticiens, créait le rôle d’animateur-facilitateur. « Généraliste, expert de la méthode, neutre en regard des parties, rapportant à un instance supérieure », son rôle génial et indispensable se trouvait confronté à un point de détail : personne ne voulait le payer, ou bien sinon, tout le monde voulait sa peau en cas de difficultés. Je ne pense pas que les contextes aient vraiment changé.

Voici ce que j’écrivais sur le sujet en 1999 dans Vite fait, Bien fait, Le Paradigme du futur immédiat. « L’animateur est un crucifié permanent (figure suivante). Son rôle est presque toujours mal compris. Souvent il n’intervient que pour la communication, l’organisation générale et pour l’animation des sessions de travail. Pourtant, on lui demande fréquemment de tout connaître du projet et même parfois d’en savoir plus que les ressources engagées à plein temps. Il doit maîtriser parfaitement les nouvelles architectures, l’intégration technologique et les techniques de modélisation. En fait, en plus des connaissances inhérentes à sa fonction, on exige de lui les compétences techniques de la maîtrise d’œuvre et les compétences fonctionnelles de la maîtrise d’ouvrage. A la moindre erreur, c’est lui qui paie. D’autre part, lorsqu’il veut rester neutre, comme rien n’est plus subjectif que la notion de neutralité, il peut s’attendre au pire.» Citons René Char pour illustrer ce propos » Depuis toujours les justes meurent mutilés pour s’être exposés nus au toucher du bien «

C’est dans ces conditions que j’ai vu se « faire virer » un certain nombre d’animateurs brûlés par quelques jours de sacerdoce. La palme dans ce domaine revenant certainement à la société cliente X. Elle venait d’abandonner un projet d’une taille pharaonique et, pour repartir du bon pied, il fut décidé de réaliser le projet suivant avec une méthode itérative. Un cycle de 90 jours (itérations de 2 semaines) avec quatre développeurs semblait être une bonne mesure de test. Un animateur de la compagnie de services la plus prestigieuse et la plus expérimentée dans ce domaine fut engagé. Après deux ou trois réunions on le remercia : il était trop brutal dans sa recherche d’efficacité. Avait-il remis révolutionnairement en question l’organisation ? non : il avait simplement jeté un stylo sur la table pour faire cesser des bavardages intempestifs. La raison donnée pour le sacrifice du second fut son « intervention » quand à l’estimation du coût de développement d’un rapport. Sachant que le projet était en fait un développement interne, on reste songeur. Que lui serait-il arrivé dans le cas d’un forfait traité en externe ? Lapidation ? Dans les faits, l’informatique n’avait pas l’habitude d’un arbitrage et d’un interlocuteur sachant évaluer les problèmes réels liés à chaque demande. »

Depuis, avec Scrum, tout est devenu de plus en plus flou. Pour conserver sa facturation, le Scrum Master de type « consultant » semble accepter de faire des « petits travaux » (de reporting par exemple), voire de participer au développement (encore faudrait-il qu’il en ai les compétences).

On trouve aussi sur le sujet « Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas. »

Dans le cas où le rôle serait tenu par un chef de projet technique officiel, ne me dites pas que celui-ci organisera une réelle démocratie d’équipe alors qu’il portera la totale responsabilité du projet face à ses supérieurs.

Généralement la culture hiérarchique est justifiée par les différences salariales et les responsabilités s’y rapportant. L’entreprise n’est pas une démocratie dans une société où la « middle classe » couvre 80% de la population et où la notion de hiérarchie plate, avec le nivellement des salaires qui en découle, permet à chacun de choisir son niveau d’engagement en fonction de ses motivations personnelles.

Pour conclure, je n’aime ni le flou ni le mélange des genres. Je préfère la vision claire du RAD, de l’eXtrem Programming ou de PUMA.

Aussi, pour PUMA, dans le cadre d’un projet de taille humaine, tous les informaticiens membres d’une équipe ont un profil de concepteur-développeur et sont dotés, si possible, de spécialités complémentaires. Tous les membres de l’équipe sont engagés simultanément dans l’action en mode « projet » et en mode « plateau ». Tous participent à la conception et au développement. Le chef de projet reste le chef de projet en termes de responsabilités. Dans la limite de ses possibilités, il initiera pourtant une forme consensuelle d’organisation du travail.

En résumé, Puma propose 2 acteurs principaux :

- L’équipe développement : représentée par son responsable « performance du projet » envers la direction informatique ou sa société de service.

- L’équipe utilisateur : représentée par son responsable « adéquation et qualité de l’application » envers la (ou les) directions « métier ».

Par contre, cette dichotomie des responsabilités devra exister dans le cadre d’une véritable osmose des deux parties travaillant concrètement et de manière quasi permanente, en relation directe (et dans un seul code et un seul document s’il vous plait !).

Dans les cas de gros projets, dans des environnements organisationnels complexes ou difficiles, ou bien encore dans le cas d’un premier usage de la méthode, un troisième acteur (animateur, facilitateur, Scrum master, etc.) pourra être engagé. Dans ce cas, un budget spécial devra être prévu pour sa rémunération et il est indispensable qu’il soit rémunéré et réponde à une instance supérieure aux parties prenantes du projet.

Le reste c’est du pipo pour des rêveurs, que la réalité des projets et des organisations semble avoir rapidement rattrapés si l’on analyse les controverses actuelles autour des nouveaux types d’échecs de projets. Il est vrai que former en 2 jours des experts de la méthode et de l’animation-facilitation qui se lancent ensuite eux-mêmes le troisième jour dans la formation d’une nouvelle génération d’experts ressemble plus à une escroquerie pyramidale qu’au développement d’un nouveau métier.

Mais enfin, on ne veut pas « la mort du petit cheval », si « Faire du Business avec Scrum » avait pu assurer quelques revenus à des généralistes ayant perdu le goût ou la capacité de développer, alors j’aurais dis, pourquoi pas et tant pis pour les entreprises trop crédules !

Malheureusement c’est le travail d’évangélisation des vrais professionnels qui en fait déjà les frais et, plus désastreux, le mouvement Agile qui perdra des années avant de retrouver la confiance des dirigeants.

Il est amusant de constater (ici d'ailleurs comme aux US), que les plus malins sentent le vent tourner et remplacent déja leur titre de "ScrumMaster" par celui de "coach Agile".