Le quatrième volet de notre série va nous conduire du côté du Scrum Master. Dans l’épisode précédent (l’été dernier, donc) nous avons remis en cause le Product Owner, il semble justice d’en faire de même avec le Scrum Master, n’est-ce pas ?
Avant d’aller plus loin, rappelons l’avertissement désormais habituel : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.
C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !
Scrum Master, ta mission si tu l’acceptes …
Comme nous l’avons fait avec le Product Owner, il est bon de camper le paysage en synthétisant les missions du S.M. ; Nous avons de la chance, le terrain est mieux balisé aujourd’hui.
Le Scrum Master est souvent décrit comme le “chien de berger”, qui doit :
- Veiller au bon suivi des cérémonies Scrum et âtre un agent du changement(1) (3)
- Encourager l’équipe, l’aider à progresser et devenir autonome (1) , un rôle qui se prolonge envers les autres parties prenantes du projet (2)
- Eliminer les obstacles (4)
Je note aussi que les écrits initiaux de Scrum donne un trait nettement plus fort au Scrum Master, le décrivant notamment comme un rôle de management, que ne le font les textes plus récents où il est plutôt décrit comme un facilitateur et un “servant leader”.
Pourquoi en faut-il un ?
Scrum édicte en règle la présence du Scrum Master : l’équipe doit pouvoir se concentrer à 100% sur le projet sans perdre de temps sur des considérations annexes, car le SM y veille. A la base, cette présence du Scrum Master repose donc sur deux postulats:
- L’équipe n’a pas la maturité pour prendre en charge sa discipline agile sans qu’un garant soit là pour y veiller.
- L’environnement nécessite que quelqu’un joue le rôle de pare-feu, car les parties prenantes en contact avec celle-ci créent trop de perturbations.
Maintenant, imaginons un environnement favorable (donc ne nécessitant pas de “firewalling”) et une maturité affirmée de l’équipe, que reste-t-il de cette nécessité ?
C’est probablement le point qui a motivé la question posée en ce sens cet été sur Quora.
La question sur Quora
Is it possible to run Scrum without Scrum Master ?
Les réponses que j’appelerais “bibliques” sont quand même majoritaires. Toutefois je constate qu’elles reposent sur deux fondements :
- Le fait que les conditions d’un projets entrainent nécessairement la présence des deux postulats que j’ai cité plus haut.
- Une croyance forte dans le bienfait de la présence des rôles.
Une autre partie des réponses affirme que cela est possible, généralement sur la base du niveau de maturité de l’équipe. Ma réponse préférée est celle de Xu Yi : “when you need to ask the question, no, you can’t. when you don’t need to ask the question, yes, you can.”.
Retour à la case départ : il est nécessaire du fait du manque de maturité de l’équipe et pour protéger des perturbations. Non seulement la réponse n’est pas satisfaisante, mais il y a plus : le SM peut s’avérer dommageable à l’équipe !
Protection ou isolation ?
Dans un excellent post qui a d’ailleurs devancé ma chronique, Tobias Meyer parle d’éliminer le Scrum Master ! Il avance plusieurs arguments à cela :
- Le rôle tel qu’il est décrit ne peut être décemment endossé par quelqu’un se dénommant “master”.
- L’idée même qu’une personne dédiée à être guide de l’équipe, à résoudre les problème pour elle est un non-sens, lorsque l’on considère le niveau de qualification des membres de cette équipe.
- “protéger” l’équipe va à l’encontre de l’idée de responsabiliser celle-ci.
Ce troisième point plus particulièrement m’interpèle : l’un des principes de base de Scrum est de permettre à l’équipe de se concentrer à 100% sur son travail. Les rôles de PO et de SM sont là pour aider à atteindre cet objectif. Mais “protéger” peut rapidement devenir “isoler”. Le Scrum Master devient ainsi l’interlocuteur privilégié et parfois unique avec l’équipe. Certains développeurs y trouvent leur compte, qui préfèrent dialoguer avec leur machine qu’avec des utilisateurs. Au-delà de cette formulation ironique, n’oublions pas que nous avons tous tendance à nous replier sur notre zone de confort : programmer c’est être en terrain connu, donc dans la zone de confort, parler avec l’utilisateur à propos de son métier, c’est être dans l’inconnu, hors de la zone de confort.
Les valeurs agiles nous parlent de communication. L’équipe doit aller hors de sa zone de confort, elle doit aller au front pour comprendre et s’approprier la matière sur laquelle elle travaille. Scrum ne dit pas le contraire, mais la notion de “rôle” et de “protection” est tellement facilement assimilable au chef de projet à l’ancienne …
Une question de maturité d’équipe
Livrons-nous à un petit “remember the futur”. Tous les membres de l’équipe ont un niveau de maturité élevé en agilité, l’organisation a bien compris la nécessité de n’être pas intrusive. A quoi ressemble le fonctionnement de cette équipe ?
- Le product owner vient aux stand-up. Il sait qui travaille sur quelle store. Il échange directement avec le développeur ou même le plus souvent, il lui envoie l’utilisateur le plus directement concerné.
- Les améliorations du processus viennent de n’importe quel membre de l’équipe. Chacun évoque son idée au moment opportun (durant l’itération) et on n’attends pas l’itération suivante pour la mettre en oeuvre.
- L’organisation n’interfère pas avec l’équille pour des questions politiques. Elle sait que la manière la plus productive d’obtenir un résultat est de laisser les personnes faire leur travail. Le comité de direction donne cependant du feedback lors des démos afin de réorienter le projet si nécessaire.
Dit comme ça, ça fait un peu bizounours. En fait, ça l’est bien un peu, hélas ! Nous n’avons pas terminé notre exercice, toutefois. Voyons comment on pourrait arriver ici en venant d’une situation standard.
Des rôles qui peuvent se répartir
Un coach m’a un jour affirmé qu’il voyait l’inutilité de sa présence comme l’accomplissement réussi de sa mission. C’est fort bien dit et aussi très juste.
La hiérarchie interfère avec l’équipe ? Certes, on peut faire rempart. Mais n’est-ce pas mieux de travailler avec la hiérarchie pour trouver un mode de fonctionnement équilibré et non intrusif ? Si le management intervient, c’est souvent qu’il a des craintes ou des insatisfactions.
Le mode de fonctionnement de l’équipe peut être amélioré, la productivité augmentée ? Oui bien sûr on peut montrer du doigt les voies d’amélioration … mais n’est-ce pas plus efficace d’enseigner à l’équipe à voir son propre gâchis, comme on dit en Lean ? Si un homme a faim, apprends lui à pêcher plutôt que de lui donner un poisson…
D’ailleurs, l’équipe étant auto-organisée, ne peut-elle dédier une personne sur chacun de ces fronts ? Pourquoi nécessairement tout ramener à une seule personne ? Que se passe-t-il quand elle n’est pas là ? Il est temps d’évoquer la sociocratie.
L’approche sociocratique
N’étant pas spécialiste du sujet, je ne vais pas m’y étendre. Ce mode de gouvernance est régit par 4 principes (5) :
- Prise de décision par consentement: Les actions sont entérinées à moins d’objections.
- Le cercle : c’est une entité autonome dans son travail et les décisions qui régissent son exécution.
- Le double lien : en plus du lien hiérarchique traditionnel, chaque cercle choisit son représentant au niveau supérieur. Il participera aux décisions par consentement de ce niveau.
- L’élection sans candidat: personne ne se porte volontaire pour un poste, les électeurs proposent des candidats qui sont libres d’accepter ou non le résultat du scrutin.
Pour une équipe ayant acquis une certaine maturité et une certaine conscience agile, l’évolution vers ce type de gouvernance semble une suite logique. Elle permet aussi au final de faire tourner le rôle de Scrum Master ou même s’y mettre fin.
Effets collatéraux
J’ai évoqué la “non nécessité du Scrum Master”. Mais allons plus loin : sa présence peut elle être nuisible, même si ce dernier est bien intentionné ?
Hélas la réponse est : oui ! Et sa présence paut avoir des effets de bord néfastes, jugez-en !
Enfin non, ce n’est quand même pas à ce point. Dans une équipe auto-organisée, l’agilité doit être l’affaire de tous. C’est déjà un peu antinomique de décider qu’une personne donnée sera porteuse de cette mission ! Passons.
Mais que peut-il se passer si une personne est en charge de la mise en oeuvre de Scrum ?
- D’abord, les autres membres de l’équipe ne s’en préoccupent plus, jugeant que c’est l’affaire de “l’autre”.
- Puis on arrive dans une situation de passivité où les choses ne se passent que si le SM s’en charge. Par exemple : avez-vous vu des équipes qui ne font pas le daily meeting un jour, car le Scrum Master est absent ? Oui, ça arrive !
Bien sûr, ce n’est pas toujours comme ça. Heureusement. Mais ça peut aussi être pire, si le Scrum Master n’est pas bien disposé.
Le chef de projet est de retour
Au secours ! Car oui, si Scrum décrit explicitement le rôle du SM comme n’étant pas un rôle de management, il n’est pas trop difficile de s’assoir dessus, surtout si tout le monde est bien disposé en ce sens. Retour au bon vieux commande-controle !
Alors quelle est la recette du désastre ? Elle n’est pas compliquée.
Prenez une bonne vieille équipe fonctionnant à l’ancienne. Ca ronronne bien. Les membres de l’équipe sont tranquillement en mode “ouvrier spécialisé”. Le chef de projet stresse un peu plus car tout repose sur ses épaules. Il distribue les tâches, car au moins c’est un mode de fonctionnement qu’il comprend.
Prenez une équipe managériale que l’on a fait mijoter dans un saladier-séminaire d’agilité. On l’a saupoudré d’épices exotiques lui faisant miroiter monts et merveilles : ils pourront changer d’avis tous les jours, la productivité sera multipliée par 100000 (je dois oublier un ou deux zéros), les utilisateurs auront des trucs mieux que ce qu’ils espèrent grâce à l’usage avisé de le télépathie. Les trucs standard, quoi.
Extrayez de l’équipe le chef de projet et faites-le revenir dans une poelle-formation Scrum Master. Les autres membres de l’équipes restent à la boite à bosser, car faut quand même pas exagérer.
Mixez l’ensemble, servez et voyez ce qui se passe.
Les membres de l’équipe ne comprennent pas trop ce qu’on attends d’eux et sont un poil déstabilisés (on vient de leur dire qu’ils sont enfin libre, mais bon ça reste un peu abstrait). Par défaut on va attendre les ordres, là on ne risque pas grand chose. Le chef de projet enthousiaste attends le démarrage de l’auto-responsabilité, l’allumette à la main. Pas grand chose n’arrive. Histoire d’amorcer la pompe, le chef de projet va distribuer les tâches (ou les user stories, ou ce que vous voulez) aux développeurs. Retour à la case départ. Enfin pas tout à fait, on a changé le vocabulaire.
Et si on ne trouve pas, on ne va pas ?
Le tableau que je dresse parait noir. Hélas il arrive. Et généralement on essaie alors de se voiler la face en se disant que non ce n’est pas comme avant. Pas tout à fait.
Mais que fait-on si on n’a pas de Scrum Master sous la main ? Ou que personne ne souhaites l’être.
- On prends une victime au hasard ?
- On roule sans ?
Clairement, sélectionner une victime n’est jamais la bonne approche. Surtout dans un rôle où la confiance est primordiale. Si l’équipe n’est pas non plus aguerrie à la pratique de l’agilité en générale ou de Scrum en particulier, il est aussi illusoire de penser que les choses se mettront en place tout seul. Il est préférable alors d’aller chercher un Scrum Master expérimenté en prestation. Mais oui.
Encore faut-il que ce Scrum Master ait bien compris son rôle et guide l’équipe dans le bon sens afin de ne pas faire tourner Scrum à la grosse farce !
Bon, alors le Scrum Master, c’est mal ?
“Scrum Masters, soyez les coaches de vos équipes agiles”. J’évite généralement dans cette colonne de faire la promotion de qui que ce soit. Mais ce slogan nous est asséné par Véronique Messager depuis maintenant un certain nombre d’années (6). Et elle a raison, c’est bien de cela dont on doit parler. Scrum n’évoque pas la chose, mais la véritable voie du Scrum Master est celle du coaching : être celui qui rends possible non pas Scrum, mais que l’équipe s’approprie Scrum !
Bref, le Scrum Master doit être un catalyseur, et pas le gars sur lequel on se décharge de l’agilité. Et dans ce cadre, son apport peut s’avérer décisif !
Références
(1) Scrum 2nd edition ; Claude Aubry ; Dunod 2011 ; p. 44
(2) Scrum field guide : Mitch Lacey ; Addison Wesley 2012 ; p. 104
(3) Agile Software Development with Scrum ; Ken Schwaber & Mike Beedle ; Prentice Hall 2002 ; p. 31
(4) Essential Scrum ; Kenneth S. Rubin ; Addison Wesley 2012 ; p. 185
(5) Sociocratie : http://fr.wikipedia.org/wiki/Sociocratie ;
(6) Coacher une équipe agile ; Véroniue Messager ; Eyrolles 2012
Software Freethinker 
