Le monde est une scène

Quand je parle autour de moi du projet du référentiel des pratiques Agiles, une question revient à l'occasion: "Est-ce que tu vas parler des rôles du Scrum Master, du Product Owner?.."

Je ne suis pas tout à fait à l'aise avec ces notions de "rôles", en tout cas avec l'importance qu'on leur donne. En y réfléchissant bien, mon raisonnement repose sur un principe simple; je l'ai déjà énoncé en passant mais il mérite que j'insiste:

Ce qui compte surtout pour le succès d'un projet, c'est ce que les gens font.

Il existe bien sûr des contraintes: les journées de travail ne faisant (en principe) que 8 heures, une même personne ne peut pas tout faire. On doit bien se spécialiser afin de mener certaines activités de façon compétente; le temps que j'investis à devenir un meilleur développeur est autant de temps que je ne passerai pas à acquérir des rudiments de graphisme.

Le principe de Ricardo ou principe de l'avantage comparatif me pousse à m'associer à une personne compétente dans le domaine graphique, et montre que je peux y trouver un avantage même dans le cas où je suis un peu doué en graphisme. (Ce qui est contre-intuitif dans le principe de Ricardo, c'est l'idée que même si je suis strictement meilleur en développement ET en graphisme qu'une autre personne, m'associer avec elle en nous spécialisant chacun dans un domaine peut quand même être intéressant pour chacun des deux.)

Mais ce qui vaut en analyse économique ne vaut pas nécessairement dans un projet. Par exemple les acteurs d'un projet ne travaillent pas chacun dans leur coin: ils ont besoin, chacun, de comprendre ce que font les autres acteurs. Trop de spécialisation peut engendrer ce que j'appelle le "syndrôme du bébé", d'après une conversation entre parents, par exemple au supermarché: "Dis donc, le bébé n'est pas avec toi?" - "Ah non, je croyais qu'il était avec toi..." - "Alors où est-il?" Transposé au monde du projet, cela donne des tâches importantes qui ne sont pas réalisées parce que chacun pense qu'elles relèvent de la responsabilité de quelqu'un d'autre.


Prenons donc l'exemple d'un des nouveaux "rôles" Agiles les plus emblématiques, celui du Scrum Master. Le Scrum Master est chargé:

• de lever les obstacles signalés par l'équipe lors des réunions quotidiennes ("mélées")
• d'être un facilitateur lors de ces réunions
• de rappeler à l'équipe les fondamentaux théoriques de Scrum
• de protéger l'équipe des interruptions

Sur le papier, ce rôle est cohérent. Mais imaginez la situation suivante: dans votre équipe, une personne est très douée pour agir et communiquer vers l'extérieur; une autre est très à l'aise pour animer des réunions. A votre avis, vaut-il mieux:

• donner à l'une de ces personnes les quatre responsabilités ci-dessus, au risque que deux d'entre elles soient moins bien assurées, ou
• jeter aux orties la définition stricte du rôle du Scrum Master, et répartir ces quatre responsabilités entre les deux équipiers en fonction de leurs talents?

 Je penche, vous l'aurez compris, pour la seconde solution.

A mon sens un rôle formellement défini n'est qu'une "checklist", un rappel utile d'un certain "lot" d'activités ou responsabilités dont il est important de garantir que chacune est assurée par au moins un membre de l'équipe, afin d'éviter le "syndrôme du bébé". La spécialisation a du sens au niveau des responsabilités isolées, pas au niveau de rôles agrégeant plusieurs responsabilités.

Il existe, bien sûr, des corrélations. Un développeur compétent est probablement une personne plus apte à se charger d'un travail de rédaction technique qu'un graphiste compétent. Mais c'est seulement une tendance (peut-être même pas une tendance très marquée). Lorsqu'il s'agit de se répartir des tâches précises, identifiées, au sein d'un projet particulier, entre des personnes réelles, dans toute leur singularité, la notion de rôles doit passer au second plan. C'est la place que je compte leur accorder dans le référentiel, sauf à entendre des arguments convaincants bien entendu!