Press "Enter" to skip to content

Est-ce que j’ai besoin d’un Scrum Master ?

Est-ce que j’ai besoin d’un Scrum Master ?

Probablement ! Voici les critères pour décider.

Quand on me demande à quoi sert un Scrum Master, on me demande généralement juste après si on en a besoin dans son équipe.

La réponse courte : oui !

La réponse plus en nuance : ça dépend… Ça dépend, de quoi ?

Je vais ressortir toujours la même rengaine : cela dépend de votre projet, de votre équipe, de votre environnement… Chacun sa solution.

Je vais quand même essayer de donner matière à réfléchir. Passons en revue les intérêts d’avoir un Scrum Master dans une équipe.

TL;DR

Pour vous passer d’un Scrum Master ces trois points doivent être réunis :

  • Votre équipe est petite, et
  • Votre équipe est très mature et intéressée par l’Agilité, et
  • Votre organisation est pensée Agile et compatible avec l’Agilité.

Vous pensez être bon pour vous passer de Scrum Master ? Considérez tout de mêmes ces quelques points d’attention :

  • Petite équipe : êtes-vous suffisamment peu nombreux pour ne pas avoir besoin d’utiliser le framework Scrum ? Scrum recommande au moins 3 membres dans l’équipe de développement, PO et SM exclus.
  • Maturité de l’équipe : on se croit souvent plus mature qu’on ne l’est !
  • Organisation compatible avec l’Agilité : l’air de rien c’est quand même rare…

La facilitation de l’équipe

Avoir des réunions efficaces

Le Scrum Master aide à faciliter les différents rituels de l’équipe. Cela veut dire avoir des réunions qui se passent bien et qui sont constructives. Cela veut aussi dire abréger les réunions lorsque l’objectif est déjà atteint, ou lorsque cette réunion n’est plus le meilleur moyen d’avancer. C’est aussi simplement faire en sorte que ces réunions aient lieu, et oui !

Cela semble être une responsabilité qui ne nécessite pas de Scrum Master.

Pas facile de faciliter les réunions quand on fait partie de l’équipe de développement

Sauf que c’est une activité qui est plus difficile qu’il n’y parait. Je l’ai déjà écrit, la clé de la facilitation c’est d’être neutre. Pas facile quand on fait partie de l’équipe de développement.

Ceci étant dit, oui, on peut se passer de Scrum Master si l’équipe est déjà très mature. Cela dépendra aussi des caractères dans l’équipe, et du nombre de personnes dans l’équipe. Le plus dur étant de se réguler soi-même : il n’est pas facile de savoir prendre du recul sur sa propre intervention.

Facilitation des réunions : avoir un Scrum Master c’est cool mais on peut s’en passer si on est peu nombreux et matures. Attention, l’auto-évaluation n’est pas facile.

Aider l’équipe à atteindre les buts qu’elle se fixe

Ou encore : protéger l’équipe d’elle-même.

L’équipe Scrum se fixe un objectif en début d’itération. Mais cela doit rester à l’esprit de l’équipe, à tout moment de l’itération.

L’équipe doit en permanence se demander si, finalement, il n’existe pas une solution plus efficace qui répond au besoin. L’équipe doit faire son possible pour essayer d’atteindre ses propres objectifs.

L’équipe ne doit pas se saboter elle-même en partant dans des refactorings inconsidérés. Quand un bug est trouvé, il n’est peut-être pas pertinent de le corriger immédiatement. L’équipe recroise avec le PO.

Mais aussi, l’équipe n’attend pas le dernier moment pour démontrer une fonctionnalité au PO, ou pour lui faire faire une recette.

L’équipe respecte les priorités affichées au board. L’équipe ne décide pas de sauter sur le bas du board sans concertation au préalable ; l’équipe remonte les points de blocage qui sont affichés clairement.

Et ainsi de suite… L’équipe s’est fixé des règles de fonctionnement, qu’elle doit respecter. Qu’il s’agisse du Scrum Guide, des règles du Kanban ou bien du process spécifique de l’équipe.

Protéger l’équipe d’elle-même en rappellant les règles de fonctionnement que s’est défini elle-même l’équipe

Le Scrum Master ne flique pas ; par contre il rappelle ces règles de fonctionnement. Règles que s’est défini elle-même l’équipe. Cela commence par un board niquel, à jour. Un board qui permettra au Scrum Master de voir si les règles sont respectées, sans faire de suivi détaillé de toutes les tâches !

Respecter les règles de l’équipe : il sera plus dur pour quelqu’un qui n’est pas Scrum Master, ou pas Scrum Master à temps plein, de détecter quand l’équipe est limite avec les règles de l’équipe. Globalement, plus l’équipe et grande et moins elle est mature, plus le besoin d’un Scrum Master se fait sentir. L’Agilité requiert une extrême rigueur, ce qui n’est pas facile.

Aider le PO à être un vrai Product Owner

La réponse est ici évidente. Si votre PO est déjà un vieux routard du Scrum qui pense produit et valeur plutôt que fonctionnalités à dépiler, il n’aura pas besoin de l’aide d’un Scrum Master pour se former au rôle.

Si votre PO n’est pas déjà expérimenté, il lui faudra un accompagnement

Attention tout de même : on a souvent une image biaisée de soi-même, et Product Owner est souvent réduit à un rôle simple alors que c’est un des plus subtils de Scrum. Difficile pour le PO débutant, notamment l’ancien MOA en reconversion, d’avoir le recul nécessaire pour se rendre compte qu’il a besoin d’accompagnement. Peut-être pense-t-il déjà tout connaître de son métier, sans réaliser qu’il a changé de métier.

Notre PO fait un nettoyage de printemps des demandes et sujets accumulés au fil du temps, pour se concentrer sur l’essentiel. Merci au Scrum Master de donner l’impulsion !

À défaut d’un Scrum Master dans l’équipe, des formations et un accompagnement par une guilde ou un coach agile peuvent avoir l’effet escompté. Malgré tout, le Scrum Master (expérimenté) reste la meilleure option car il vit avec l’équipe Scrum et pourra donner des conseils moins abstraits au PO qu’un coach agile, une formation ou une guilde, forcément un peu déconnectés de son quotidien.

Accompagnement du PO : si votre PO n’est pas déjà expérimenté, il lui faudra un accompagnement. Le Scrum Master est idéal mais d’autres options existent à défaut. Dans tous les cas l’accompagnement ne doit pas être négligé.

La facilitation de l’organisation

Être bouclier de l’équipe

Le Scrum Master va protéger l’équipe des interférences externes. D’un côté, c’est faire le tampon avec un client ou une hiérarchie pas vraiment Agile pour que l’équipe puisse avancer dans une ambiance sereine. Le Scrum Master passera le temps nécessaire pour rassurer les parties prenantes, et n’en communiquer que la partie positive à l’équipe. C’est une posture qui peut être un peu schizophrène, mais c’est pour le bien de l’équipe !

Le Scrum Master servira à compenser les manquements de l’organisation au sens large

Le Scrum Master expérimenté, saura également mettre en place les indicateurs qui permettront de rassurer et d’expliquer à l’extérieur les performances de l’équipe. Par exemple en calculant le ratio entre bugs traités et nouvelles fonctionnalités, ce qui explique souvent beaucoup de choses. Ou encore en matérialisant la dette technique et en expliquant aux parties prenantes son importance.

Positivons : heureusement, toutes les équipes n’ont pas besoin de ce bouclier, ou pas toujours de manière aussi exacerbée. Finalement, ce Scrum Master servira à compenser les manquements de l’organisation au sens large.

Dans certaines équipes, ce rôle de bouclier est assuré par le PO. Attention, le PO aussi a besoin d’être dans un environnement sain pour donner son plein potentiel. Vous risquez surtout le burnout de PO à lui imposer cela alors qu’il voit déjà suffisamment souvent les parties prenantes pour discuter roadmap, encore et toujours. Le PO aussi a besoin de temps bien à lui pour avancer ; il ne peut pas être en permanence en réunion.

Protéger l’équipe : votre besoin en Scrum Master sera directement proportionnel au niveau de maturité de l’organisation. Cas extrême : sur un projet où tout va mal et dans une organisation qui prône la culture du blame, il sera difficile pour l’équipe d’accomplir quoi que ce soit sans personne qui protège l’équipe.

Notre PO fait un nettoyage de printemps des demandes et sujets accumulés au fil du temps, pour se concentrer sur l’essentiel. Merci au Scrum Master de donner l’impulsion !

Assurer un premier niveau de support technique : compenser la dette de l’équipe

Dans certaines équipes, le Scrum Master assure aussi un premier niveau de support technique. Est-ce que cela fait bien partie des responsabilités du Scrum Master ? On peut en débattre… Mais voici mon point de vue.

Le support technique, le vrai, celui qui résout des problèmes, est en général le mieux assuré par l’équipe de développement. Le PO, en tant que contact privilégié avec l’extérieur, joue aussi souvent ce rôle avec brio.

Mais il y a aussi la dette technique. Les doc qui ne sont pas à jour. Les comportements bizarres qui ne s’expliquent pas à moins de connaître tout l’historique du projet. Dans ces cas-là, cela entraîne beaucoup de support pour aucune valeur ajoutée. Cela ne me choque pas que dans ces conditions le Scrum Master assure un premier niveau de support, finalement à purement et simplement compenser la dette technique du projet. Soyons clair : si la doc existait, était claire, et que le produit n’avait pas des comportements délirants, on n’aurait pas besoin de ce genre de support. Toutes les demandes de support seraient pertinentes.

Soyons clair : si la doc existait, était claire, et que le produit n’avait pas des comportements délirants, on n’aurait pas besoin de ce genre de support.

Bien entendu, cela ne donne pas le droit à laisser exister cette dette technique ! Mais il y a un temps pour chaque chose, et on peut faire le choix stratégique de temporiser la disparition de certaines dettes. Par exemple parce qu’on est déjà en train de s’occuper d’autres dettes, plus critiques encore.

Support technique : si vous avez du code legacy, et qu’une bonne partie de vos demandes de support n’apportent aucune valeur mais ne font que mettre en lumière votre dette technique, alors cela vous aidera d’avoir un Scrum Master qui se chargera de cette partie à la place de l’équipe qui délivre un produit.

S’occuper de la paperasse

Dans pas mal d’organisations, le fonctionnement Agile semble décorrélé de la réalité. Les budgets, ça se négocie en amont et ensuite il faut faire avec pour l’année. Quand on a besoin de fournitures, il faut remplir des formulaires et faire valider la demande. Pour faire un simple achat en ligne, il faut se procurer un devis pour avoir droit à un code de e-carte bleue.

Ça ne colle pas vraiment avec cette idée que l’équipe va découvrir son marché et ses clients à chaque itération, et qu’elle peut changer de direction à tout moment. Pour essayer de courir à l’opportunité qui apporte le plus de valeur.

On peut parler de bureaucratie. Cette bureaucratie va ralentir les équipes, mais pour rien. Et c’est ça le plus fou. On va leur demander de suivre des process qui mettent des semaines voire des mois pour aboutir, alors que tout le monde dans le projet sait qu’il faut agir vite.

Il est question de compenser la non-Agilité de l’organisation au-dessus de l’équipe Agile

Vous l’aurez compris, le Scrum Master s’avérera précieux dans ces organisations. D’une parce qu’il prendra le temps nécessaire à cette bureaucratie. Par exemple en commandant les fournitures, plutôt que de se résigner à ne plus utiliser de post-it.

Ou encore en faisant pression (gentiment !) sur l’organisation pour accélérer ces process. Une demande est toujours traitée plus vite quand on va voir la personne, qu’on lui demande régulièrement où ça en est. Ça évite à la demande d’être oubliée et de ne ressurgir que bien plus tard.

Là encore, finalement, il est question de compenser la non-Agilité de l’organisation au-dessus de l’équipe Agile.

Bureaucratie : si la paperasse et les process lourds règnent dans votre organisation, un Scrum Master facilitera grandement la vie de l’équipe. Faites le test : comment faites-vous pour vous procurer un tableau blanc ? Est-ce simple ? Faut-il faire une demande d’achat ? Est-ce compliqué de dépenser 100€ ? Doit-on négocier ? En résumé : l’équipe a-t-elle mieux à faire que de suivre ce parcours du combattant ?

Voler le temps aux autres équipes pour lever les dépendances

Est-ce que votre équipe est pleinement autonome dans l’organisation ? C’est rarement le cas. Peut-être plusieurs équipes travaillent sur le même produit, en parallèle. Ou peut-être existe-t-il des entités externes qui se réservent certains sujets, tels que l’exploitation des serveurs (les ops), ou la partie UI/UX du produit (les graphistes et designers), ou encore des architectes qui supervisent l’ensemble des projets d’un point de vue technique.

Dans ce genre d’organisation, tôt ou tard apparaitront des dépendances envers ces entités externes. Tôt ou tard l’équipe aura des demandes spécifiques aux ops, aura besoin de retoucher la charte graphique, devra faire valider sa solution à un architecte. Ou tout simplement sera en attente d’un développement en cours dans une autre équipe sur le même produit.

Comment gérer au quotidien ces dépendances de l’équipe envers d’autres entités ?

Ce genre d’organisation n’est pas une organisation Agile. On parle de silos. Peut-être qu’une transformation Agile a été entamée mais pas encore terminée. En effet idéalement l’équipe Scrum est composée des différentes compétences nécessaires pour faire le boulot de bout en bout, la fameuse feature team. Ce qui suppose, logiquement, qu’on n’a pas d’entité partagée sur des sujets spécifiques, tels que l’exploitation, l’UX ou l’architecture. Chaque équipe a les compétences nécessaires pour y répondre. Ce qui est, du point de vue de l’équipe, beaucoup plus efficace.

Jurgen Appelo explique cependant dans Management 3.0 que ce passage aux feature teams n’est pas forcément la meilleure option, dans toutes les organisations. D’un point de vue organisationnel, il faut essayer de réduire les communications ; et peut-être que les différents experts ont plus de communication entre eux qu’avec les équipes Scrum. Ce qui peut donc justifier une telle organisation avec certaines équipes d’experts. Il faut alors accompagner ce fonctionnement d’un véritable esprit de service, de sorte que ces entités soient bien en aide des équipes Scrum. Êtes-vous dans ce genre d’organisation ? Ou au contraire c’est compliqué de faire passer la moindre demande ?

Bref : comment gérer au quotidien ces dépendances de l’équipe envers d’autres entités ? Voici une phrase qui résume tout :

Pour prendre le temps d’autres personnes, il faut perdre son propre temps avec eux.

Et c’est exactement ce que fera le Scrum Master. Il ira voir ces personnes et restera avec eux le temps nécessaire pour que les demandes prioritaires de l’équipe soient gérées.

Ne jamais sous-estimer le pouvoir des relations humaines. Le Scrum Master débutant aura peut-être l’impression d’être impuissant face aux problèmes externes que remonte l’équipe en Rétrospective. En effet, le Scrum Master n’a aucun poids hiérarchique à mettre dans la balance pour forcer les choses. Par contre, il peut aller voir les gens. Leur parler. Souvent. Très souvent. Et là, ça débloque souvent pas mal de trucs !

Blocages avec entités externes : sauf si votre organisation dispose déjà d’une très bonne maturité Agile, il y a fort à parier que l’équipe rencontre régulièrement des blocages à cause de dépendances envers le reste de l’organisation. Dans ce cas le Scrum Master sera d’une grande aide pour fluidifier ces interactions et lever les points de blocage.

La veille sur l’Agilité

Qui au sein de l’équipe fait de la veille sur le thème de l’Agilité ? Qui ira piocher toujours de nouvelles idées à expérimenter pour animer les rituels, pour améliorer le process, pour grandir en maturité ?

On peut d’emblée dire qu’un Scrum Master doit faire cela. Bien entendu, ce n’est pas sa chasse gardée ; tout le monde a le droit de faire sa propre veille sur l’Agilité, et ce serait même une excellente chose. À encourager !

Cependant on n’a pas tous les mêmes centres d’intérêts, et on n’a par ailleurs jamais assez de temps pour tout faire. Les développeurs, par exemple, consacreront déjà beaucoup de temps à faire de la veille technique sur la multitude de technos et méthodes qu’ils pratiquent au quotidien, et bien plus.

Voici un exemple de lecture qui ravira tout praticien de l’Agilité, et notamment du management visuel :

Le Scrum Master qui fait sa veille sur l’Agilité, a d’ailleurs toujours les mêmes atouts pour que l’équipe en tire parti :

  • Il vit dans l’équipe, et connait ses problèmes, ses process, son produit : il sera à même de savoir si appliquer une nouvelle idée est pertinente ou non, et de comment s’y prendre pour y arriver. C’est plus compliqué par exemple pour un coach, qui n’est pas aussi impliqué dans l’équipe.
  • Il garde un regard neutre sur l’équipe, sait prendre de la distance, et aura une vision beaucoup plus process et organisation que le reste de l’équipe. Il sera ainsi capable d’envisager des changements radicaux, ou non-orthodoxes.

Le Scrum Master sera le garant de l’amélioration continue

Finalement, le Scrum Master sera le garant de l’amélioration continue, au-delà des Rétrospectives qui peuvent patiner au bout d’un moment avec une équipe bien rodée. Et cela commence justement par tester de nouveaux formats de Rétrospectives !

Veille sur l’Agilité : il n’est même plus question de la maturité de l’équipe, mais de simplement l’intérêt de l’équipe pour l’Agilité. Si vous avez ce genre de personne dans l’équipe… Pourquoi ne pas lui donner l’opportunité d’être Scrum Master ?

Et le reste alors ?

Je n’ai pas parlé du classique qu’on retrouve sur les fiches de poste :

Le Scrum Master s’assure que les rituels Scrum ont lieu.

C’est souvent à cela qu’on réduit le rôle de Scrum Master. Et dans ce cadre uniquement, il n’y a pas d’expertise spécifique ni de valeur ajoutée. Oui, ce rôle-là de Scrum Master peut être partagé dans l’équipe. Sans problème.

Mais posez-vous les questions soulevées ci-dessus :

  • L’équipe est-elle capable de mener à bien ses réunions sans aide extérieure ? En optimisant le temps de chacun ?
  • L’équipe respecte-t-elle bien les règles de fonctionnement qu’elle s’est donnée ? Donne-t-elle son maximum pour atteindre l’objectif de l’itération, qu’elle a fixé elle-même ?
  • Le PO a-t-il besoin d’un accompagnement pour bien prendre son rôle en main ?
  • L’organisation est-elle Agile-friendly ? Comment les parties prenantes interagissent avec l’équipe ? La bureaucratie règne-t-elle ? L’équipe est-elle indépendante ou est-elle souvent bloquée par d’autres entités ?
  • Qui mène une veille sur l’Agilité et sait la réinjecter dans l’équipe ?

Conclusion

Est-ce qu’il me faut un Scrum Master dans mon équipe ? Pourquoi ?

Oui car il va vous aider à devenir Agile, à rester Agile, et surtout à compenser une organisation peu adaptée.

Paradoxalement, si l’équipe se pose la question, c’est certainement qu’elle a besoin d’un Scrum Master.

Finalement, ce n’est pas pour rien qu’il y a le rôle de Scrum Master dans le framework Scrum !

Cet article vous a plu ?

  • Cliquez sur le cœur pour m’encourager, et partagez l’article autour de vous
  • Abonnez-vous à mon profil via le bouton Follow
  • Consultez mes autres articles sur le thème du rôle du Scrum Master !
Top