headerphoto

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!

7 commentaires:

Luc Jeanniard a dit…

"Faciliter" une équipe ne s'improvise pas et exige de se perfectionner chaque jour. Par example, animer des rétrospectives demande de l'expérience pour qu'elles soient animées et non rébarbatives. Les autres membres de l'équipes ne prennent pas le temps de s'informer sur ce sujet et ont plus tendance à aller vers des sujets techniques. Pour les fondamentaux de Scrum, c'est selon moi un peu la même chose, je connais très peu de membres d'équipes qui plongent dans les bouquins Agiles pour mieux comprendre les fondamentaux.

Donc, je ne suis pas tout à fait d'accord avec toi, être ScrumMaster est pour moi une spécialité à part entière.

Expérience : Demandez à votre équipe qui souhaiterait animer la prochaine rétrospective. Par deux fois, dans deux équipes différences, personne ne s'est proposé!

pablopernot a dit…

Bonjour,
Je ne suis pas vraiment de cet avis non plus.

a)La séparation des activités de ces différents rôles permet d'équilibrer les "forces" en présence sur le projet. Exemple : le PO priorise, l'équipe estime.

b)Un scrummaster doit aussi bénéficier d'un statut à part. Comment "faciliter" si on est partie prenante de l'équipe ? Notamment avec des problèmes de moyen ou d'implication de la hiérarchie.

c)Si "tout le monde est tout le monde", l'effort nécessaire de transparence va s'appauvrir.

Donc, à mes yeux, la séparation de ces rôles est essentielle pour l'équilibre, la facilitation et la transparence nécessaire à la réussite du projet.

Pablo

Institut Agile a dit…

@Luc: la compétence de facilitateur, c'est la moitié de ce qu'on attribue au ScrumMaster; s'il est nul sur l'autre moitié, on fait quoi? Question sérieuse...

@Pablo: le point b) apporte plutôt de l'eau à mon moulin. On pourrait très bien imaginer qu'un rôle de facilitateur dédié vienne à se créer dans les entreprises, ce seraient des personnes recrutées pour (par exemple) faciliter des rétros ou autres réunions, et qui ne feraient pas partie de l'équipe.

Je suis d'accord pour que tout le monde ne soit pas responsable de tout: ce serait ne pas tenir compte des compétences individuelles, et ça c'est idiot...

Luc Jeanniard a dit…

Avec une équipe peu rodée à SCRUM, je pense qu'il est très important de bien choisir son SM (ie: pas un nul dans la moitié des compétences nécessaires!). Sinon, on finit avec du "Scrum BUT" et tous les problèmes qui vont avec.

Par contre, Une équipe qui maîtrise le fonctionnement de SCRUM peut se passer d'un SM et distribuer le contenu du rôle à l'équipe. Faut-il que les membres de l'équipe acceptent et ceci n'est pas une évidence ...

Benoit Gantaume a dit…

Laurent, j'aime ton point de vue, et j'ai envie d'aller plus loin: à quand une entreprise sans titre sur les organigrammes qui ne seraient plus pyramidaux?

pierrefauvel a dit…

A l'usage, à chaque fois que je démarre une mission de coaching agile, j'aide mon client à faire un mapping entre les différentes fonctions de chacun des rôles et les personnes réelles qui vont les assumer, et il n'y a jamais une correspondance simple.

Et puis, franchement, "Scrum Master" ca fait un peu geek.

Oaz a dit…

J'abonde dans le sens de l'article mais la raison la plus importante à mes yeux n'y est pas vraiment évoquée : que fait le reste de l'équipe le jour où le scrummaster est en RTT ? en formation ? en vacances ? à l'hopital ?
Le scrummaster unique et incontournable, c'est un truck number de 1 pour l'équipe.

On essaie de ne plus trop catégoriser en termes d'architecte/concepteur/analyste/programmeur/testeur/... mais les activités dévolues à chacun de ces rôles n'ont pas disparu pour autant. Elles sont souvent réalisées de manière plus collectives et diffuses.
Pourquoi faudrait-il alors promouvoir d'autres rôles tenus par des individus distincts si leur activité peut être distribuée pour une meilleure résilience de l'équipe ?

Paradoxalement, les méthodes agiles ont mis en avant l'intérêt d'une certaine polyvalence des individus sans aller jusqu'au bout de la démarche.
Sans vouloir lancer de polémique, j'ai l'impression que des profils type chefs de projet, nécessairement moteurs dans la mise en place de méthodes de travail, voient leur intérêt dans la conservation d'un pré carré qui leur évite de devoir se fondre dans la masse.

Enregistrer un commentaire