Le scrum Master est-il (encore) utile ?
Comment ? Le scrum master inutile ? Attends mais tu contredis le manifeste agile là ! Quelle parjure ! Au bûcher !
Le titre est fort je sais, mais la question mérite d’être posée.
Ces derniers mois j’ai beaucoup lu de commentaires assez virulents qui traitait de ce sujet sur le web anglophone.
- Mais à quoi sert le scrum master ?
- Le scrum master, c’est le type qui a pris le temps de lire une notice que personne n’a lu et qui se fait appeler Maître au bout de 2 jours grâce à une certification.
- Le scrum master c’est celui qui veille à faire appliquer Scrum, c’est tout.
- Comment ? Tu veux savoir si les clients sont contents de la dernière fonctionnalité en prod ?
- Je sais pas, demande au PO, moi je prépare une super rétrospective avec un nouveau jeu de rôle.
Certes, je n’aperçois pas encore la même tendance dans la blogosphère francophone.
Cependant, dans les faits j’entends beaucoup de bruits de couloir qui font écho à cette impression.
Dans ce post, je traite d’un sujet quasi tabou dans le milieu de l’agilité.
- Pourquoi le scrum master ?
- Que lui reproche t-on ?
- Le scrum master est il devenu has been ?
Confrères Scrum Masters et coach agiles, ne zappez pas. Je tiens à préciser que le but de ce poste n’est pas de provoquer mais d’interroger.
Pourquoi le scrum master ?
Il y a (pas si) longtemps, dans une galaxie (pas si) lointaine
C’est une époque de bulle internet.
A bord de bureaux agencés en open space, les rebelles Scrum ont remporté leur première victoire sur l’abominable empire Waterfall.
Au cours de la bataille, les rebelles ont réussi à propager leur arme absolue auprès des médias experts : Le manifeste agile, un écrit qui décrit une méthodologie assez puissante capable de changer tout le Game de la planète développeurs.
Poursuivis par les grands méchants chefs de projets SSII, le scrum master rejoint le monde des startups, porteur de la bonne parole à propager qui pourrait sauver le monde des projets informatiques et restaurer la liberté dans la galaxie de l’entreprise.
Pendant ce temps en Gaule
J’ai commencé ma carrière dans le web, en France vers 2005/2006.
A l’époque, avant de commencer le moindre développement, il fallait valider un cahier des charges grand comme un papyrus égyptien.
Sans exagérer, il fallait parfois plus de temps pour écrire et valider le cahier des charges que pour faire le développement.
Si un seul truc manquait sur le cahier des charges, il fallait parfois tout revoir avec tous les acteurs afin de le valider à nouveau.
Pour certains gros projets, l’exercice du cahier des charges ressemblait à un exercice de dépôt de texte de loi à l’assemblée nationale… l’horreur absolue.
Découverte du scrum
Peu de temps après, j’ai eu l’opportunité de partir dans la Silicon Valley pour travailler dans le milieu des startups.
Au delà de la vague entrepreneuriale qui envahissait le monde entier, j’ai découvert le Scrum et le mouvement lean startup.
Tout à coup, un projet pouvait (presque) démarrer du jour au lendemain.
Avec une idée, sans cahier des charges, on se réunissait et on commençait à coder quelque chose pour le mettre dans les mains des clients.
Cette méthode m’est apparu tout de suite naturelle.
L’introduction du Scrum en entreprise
Le succès du Scrum à presque été immédiat dans l’environnement Startup. Quand on connaît le mode de fonctionnement interne des startups, c’est tout à fait logique.
En revanche dans le monde de l’entreprise classique, le succès du Scrum n’était pas gagné d’avance.
Je ne pense pas que le Scrum s’est imposé en entreprise parce que cela améliore la productivité et la collaboration interne.
Le succès du scrum est venu suite à la demande des clients.
Je m’explique:
Imaginez que vous êtes dans l’univers BtoB et que vous avez une commande client :
L’ancien modèle est plutòt à l’avantage de l’entreprise qui produit.
En effet, avec un cahier des charges à valider, l’entreprise s’assure un contrat pour plusieurs mois voire plusieurs années.
En cas de changement dans le cahier des charges, on re-facture un supplément. C’est tout bénéf.
Pareil, du côté développeurs.
Avoir un planning de développement pour plusieurs mois sans risque de changement, c’est plutôt rassurant.
Comparé au Scrum, on n’a pas besoin de réfléchir et de s’adapter en temps réel. il n’y a pas d’incertitude.
Un succès poussé par le client
En revanche, du côté client, avoir la possibilité d’avoir un truc en main (même béta), le plus vite possible c’est génial.
En plus, à chaque nouvelle version, on peut affiner ces idées et ajouter quelque chose dans le prochain planning de développement.
C’est je pense face à cette nouvelle demande clients et tirées par la concurrence des entreprises déjà agiles que la plupart des entreprises classiques se sont tournées vers le scrum.
Je ne pense pas que ça se soit fait de gaité de coeur comme on peut l’entendre souvent dans les discours de façade
Vous savez le fameux “Nous, on est une entreprise agile depuis le départ”.
Le scrum master, ce prophète moderne
Ainsi, pour commencer leurs fameuses transitions (ou transformations) agiles, bon nombres d’entreprises ont eu besoin d’aides d’experts, car elles ne savaient pas faire toutes seules.
Coïncidence (ou pas), le fondateur du Scrum avait tout prévu.
Le scrum est une méthodologie livrée avec ses prophètes : “Les Scrum Masters” (on y vient).
Pas besoin de lire un bouquin ou appliquer soit même les process.
Non, pour démarrer avec Scrum vous n’avez qu’à embaucher un super consultant certifié et celui ci va tout vous mettre en place dans votre organisation.
Formation, évangélisation, aide, facilitation… pas besoin de comprendre comment ca marche, le scrum master s’occupe de tout.
Le scrum master, le facteur X de la révolution agile
Je suis le premier à l’avouer, sans les scrum masters (ou coach agiles), le scrum n’aurait jamais pu se propager si largement.
Ça coule peut être de source pour les jeunes diplômés qui entrent dans le monde de l’entreprise aujourd’hui, mais pour ceux habitués aux anciennes méthodes, l’application du Scrum fut une révolution.
Sans les scrum masters à proximité les aidant au quotidien, l’application du Scrum aurait échouée dans 90% des cas.
En effet, il faut des mois avant d’observer les bienfaits d’une méthodologie agile sur le fonctionnement interne d’une organisation et sur son business.
Livrés seuls avec eux mêmes, beaucoup d’employés n’auraient pas eu la patience et auraient abandonnés en cours de route.
Pour tout ceci, je dis Merci les Scrum Masters et les coach agiles. Mission accomplie.
Que lui reproche t-on réellement ?
Le business scrum :
Il faut avouer que le scrum guide est un manuel qui est fourni avec un service après-vente.
Le scrum n’est pas qu’un process, c’est aussi un business.
Certifications, mission de consulting etc…
L’autre jour un de mes devs me fait la remarque :
“Imagines que l’on applique le même système dans l’univers du dev.
En passant toutes les certifications Java, je pourrais devenir Java Master et évangéliser les bonnes pratiques Java dans une organisation.
C’est cool comme job”
C’est un peu poussé comme raisonnement mais il faut avouer que ça a du sens.
On ne va pas se mentir, depuis quelques années, le milieu du coach agile est en pleine effervescence.
Encore une fois, je comprends complètement les raisons mais je ne peux pas contredire les gens pour qui ça pique les yeux.
Il n’y pas si longtemps, dans une autre branche de l’informatique il y avait les consultants en Cloud ou en sécurité qui occupaient l’espace à tous les étages pour donner des conseils aux vrais experts internes.
Ce genre de rôle est parfois vu comme une imposture pour les puristes.
La bureaucratie scrum :
L’idée première du scrum c’est de tout faire pour rapprocher l’équipe du client.
L’objectif final est de fluidifier le travail interne pour livrer quelque chose le plus vite possible dans les mains du client.
Seulement voilà, en appliquant le scrum à la lettre, on tombe parfois dans la contradiction de se concentrer plus sur le process que sur l’objectif final.
On n’est pas agile parce que l’on applique le scrum.
On n’applique le scrum pour devenir plus agile.
Il y a une grosse nuance ici.
Parmi tous les reproches fait au Scrum Master, celui ci est le plus populaire.
Dans certains cas, on a l’impression que le scrum master ralentit plus l’équipe avec ses nouveaux process, ces cérémonies etc… qu’il ne fluidifie son travail.
Faut bien avouer que quand un sprint s’est super bien passé, il est un peu lourd de se taper une rétrospective le vendredi après midi.
Parfois, on a l’impression que seul le Scrum Master est excité par la cérémonie.
Honnetement, je prefere donner l’après midi à mon équipe pour qu’ils aillent profiter d’un weekend prolongé.
Parfois un peu de bons sens à plus d’impact qu’un jeu de rôle dans un bureau entre collègues.
La scrum police :
Ce qui découle de la bureaucratie, c’est parfois la rigidité des règles du scrum.
L’impression que tout est obligatoire ou grave.
Beaucoup de gens en plaisante mais il est vrai que parfois à la moindre entorse à la règle, on a l’impression de commettre un crime abominable et d’être rattrapé par la police.
Cette intransigeance est perçu comme du micro-management pour certains ou de l’infantilisme pour d’autres.
Il parait que si cela se produit alors c’est la faute à une mauvaise implémentation.
- Ok, je veux bien mais à qui la faute ?
- Avez-vous déjà essayé de remettre en cause certains principes Scrum ?
Le scrum master est il devenu has been ?
Le scrum n’est plus nouveau
Après 10 ans passé à l’étranger, je suis le premier surpris de la démocratisation des méthodes agiles en entreprises en France.
Encore une fois, Big kudo à tous les coach agiles et scrum masters pour avoir facilité l’introduction de l’agilité en entreprise.
Je n’ai aucune idée du pourcentage des entreprises agiles Vs celles non agiles mais je ne pense pas que toutes ont forcément besoin de devenir agiles.
Pour celles qui le sont déjà et qui ont réussi à construire des équipes autonomes, ont-elles encore besoin d’évangélistes ?
Un job en CDD plutôt qu’en CDI
Le Scrum Master a pour mission de supprimer les obstacles (résoudre les problèmes).
Dès que les problèmes les plus visibles sont résolus et que l’équipe atteint un certain stade de maturité, elle devient autonome.
Dès lors, la mission du scrum master est terminée et c’est une excellente nouvelle pour tout le monde.
Si un scrum master travaille avec la même équipe depuis des années, c’est qu’il y a un problème quelque part.
Cela n’engage que moi mais je pense qu’une fois les fondations posées, l’équipe doit trouver son chemin seule.
Dans un groupe composé de gens intelligents, les choses se produisent spontanément sans avoir besoin de quelqu’un qui vous tient la main pour avancer.
Au départ, un peu de cadre et de rigidité, ça fait du bien mais à la longue cela peut devenir contre productif.
La fête est fini ?
Je n’ai pas de boule de cristal pour lire l’avenir mais en observant des faits, on peut constater quelques tendances :
- La pratique du scrum commence à être bien installé dans pas mal d’entreprises
- Cette méthodologie est déjà la norme pour les moins de 30 ans (ils ne connaissent même pas le Waterfall)
- On enseigne désormais les méthodes agiles dans les écoles d’ingénieurs.
En suivant ces tendances, il est logique d’imaginer que le rôle de scrum master, comme on l’entend aujourd’hui, va perdre de son aura.
En effet si tout le monde connaît déjà le scrum à la lettre…
- Pourquoi imposer un scrum master dans une équipe ?
- Cela risque plus d’etre perçu comme du flicage que comme du coaching
La dimension de guide du Scrum Master risque de perdre de sa valeur.
Ou peut être pas…
Si le scrum master n’est plus, d’autres méthodologies agiles telles que le Safe dans des grandes organisations émergent de plus en plus.
Nul doute que rendre agile les grands groupes est une autre paire de manche que rendre agile les startups.
Dans ces organisations, le rôle de Scrum Master prend plutôt le nom de Coach agile (cherchez pas à comprendre…)
Comparé au Scrum Master de base, le coach agile opère à un niveau supérieur à l’équipe.
Son domaine de coaching se situe au niveau du top et middle management (dans le domaine de la stratégie).
Le scrum master n’est pas mort, il migre vers de nouveaux horizons.
La semaine dernière, dans le podcast « Scrum life », on remettait en question la nécessité impérative d’avoir un Product Owner au sein des équipes Scrum, ce matin, je découvre cet article sur la nécessité impérative d’avoir un Scrum Master au sein des équipes Scrum…
Je m’interroge vraiment, étant moi même dans un contexte « pseudo-agile » et qui tend vers de l’Agilité à l’échelle alors même que les basiques ne sont pas là…
Je pense que chaque rôle a une vraie plus value, ne serait ce que pour accompagner aussi les turn over des équipiers (intégrer un nouveau développeur dans une équipe Scrum n’est pas aussi simple que ça…). Et puis, on peut très bien faire tourner le rôle de SM au sein d’une équipe (je l’ai vécu, ça fonctionne bien).
Aujourd’hui, beaucoup d’entreprises se disent « Agile »… mais à bien y regarder, j’ai davantage l’impressions qu’elles « font de l’agile » plutôt qu’elles « soient agiles ». Se mettre debout tous les matins devant un board ne prouve pas que les équipes sont agiles… c’est tout un état d’esprit à accompagner, des nouvelles façons de penser… en ce sens, chaque rôle me semble avoir une utilité… encore faut il « être » vraiment Agile et ne pas se cacher derrière une méthode…
Tout à fait d’accord avec vous Céline quand vous dites que beaucoup « font de l’agile » au lieu « d’être agile ».
C’est exactement ce que je souligne quand je parle de bureaucratie ou de scrum police. Trop de gens ont l’impression de bien faire leur travail parce que la méthode est appliquée à la lettre.
Au final l’utilisateur se fiche pas mal de savoir si le produit qu’il utilise ait été développé avec une méthode agile ou pas.
Dans ce post, j’ironise pas mal sur ça.
On à trop tendance à se concentrer sur le « comment » on fait les choses (les cérémonies, les bonnes pratiques…) et on oublie l’essentiel : Le « pourquoi » (l’utilisateur, le besoin, la valeur).
Hello Julien,
Alors pour ma part, j’interviens essentiellement dans un environnement industriel. Je te rejoins que la traduction littérale du « Maitre » n’est pas approprié (tout comme Chef dans Chef de projet ceci dit) je retiens plutot l’aspect Servant Leader du SM : ce coté facilitateur. Je suis assez convaincue que les équipes qui ont la tète dans le guidon ont justement besoin d’une ressource qui se concentre sur le processus et non le produit pour les aider à réguler les échanges. Avec Scrum on met l’Humain (client et équipe) au coeur du processus et qui dit Humain dit communication/quiproquo/tension/régulaton/production. Plus vite on peut atteindre le seuil de perfo , mieux ce sera pour optimiser la valeur du produit à livrer et pour le bien-être de l’équipe. Je vois le Scrum Master un peu comme un préparateur mental pour une équipe de sport co. Plus vite l’équipe remporte ses premières victoires, mieux ce sera pour sa perfo. Le SM est là pour « soulager » un équipier quand il est dans une phase down, préserver une équipe dont le PO tend à oublier le principe du rythme soutenable, préserver l’équipe qui fait partie d’une orga qui confond « Faire » agile et « Etre » agile , lutter contre le syndrome du « On peut tout faire, on est agile » ;-( . En effet, un SM comme le préparateur mental ne sont ni flic ni joueur, ils sont là pour optimiser les échanges et les pratiques, identifier des axes d’amélioration. Un sprint a été une réussite ? Génial ! pourquoi ? quelles ont été les bases que l’équipe a su mettre en place pour ce succès ? Et si on recommençait (plutôt que de compter sur la chance et rester sur nos acquis) Toute l’équipe est ok pour faire évoluer le cadre Scrum au contexte du projet et de l’équipe ? Alors Go allez-y les gars, c’est vous les experts , vous etes auto-organisés. En revanche, le SM veille à ce que 100% des membres de l’équipe soit du même avis.
J’interviens dans un Master Spé en Innovation Technologique, les promos sont constituées ( à 95 %) d’étudiants qui sortent d’écoles d’ingé (généraliste, méca, fluides…) et je t’assure qu’ils ont quasi pas vu ni le waterfall, ni le Scrum !
Je te rejoins les aspects certification : Etre certifié n’est pas un gage d’Etre agile, au mieux on saura Faire agile et encore, sans pratique, c’est pas gagner.
Egalement sur le fait qu’une fois que tous les réflexes acquis, le SM doit s’effacer sans quoi il y a un souci ,il fait probablement mal son job !
Comme tu vois, le sujet me passionne. Je suis assez convaincue que l’absence de SM compétent, passionné par l’Humain et non le code, sont des pratiques de plus en plus courantes. Je pense également c’est ce qui nous amènera dans quelques années à penser que l’Agile ca ne marche pas et on inventera d’autres méthodes alors qu’en fait, on aura juste zappé les bonnes pratiques !
Allez, l’entrainement va commencer! Je vais au bord du terrain 😉
Audrey
Etant Scrum Master de métier, cet article me fait forcément réagir. Il est un détail important, le rôle de scrum master dans une équipe est temporaire. L’objectif du scrum master, avant tout, est de rendre l’équipe scrum (dev + PO), autonome. Une fois chose faite, une fois que tout le monde a compris l’importance et l’intérêt de l’amélioration continue, des boucles de feedback et autres joyeusetés, il n’a plus son rôle. Il convient de trouver dans l’équipe un élément plus sensible à l’agilité et de le pousser à reprendre le flambeau.
Tout bon scrum master vous le dira, ce ne sont donc pas vos convictions, c’est tout simplement la fiche de poste !
Attention ceci dit, dans les contextes semi-agiles / peu agiles, le scrum master sert aussi à mettre en place le job de PO, à faire comprendre que ce n’est pas juste un/une secrétaire glorifié(e). J’ai rarement vu des PO réellement en charge du produit… ils ne sont en général qu’en charge de l’expression de besoin. A ce moment-là, le PO est lui-même inutile…
Alors oui le titre est pompeux, mais à peu près autant que Product Owner, mais au-delà de ça, l’utilité n’est plus à prouver.
Enfin, on assiste à une multiplication des métiers inutiles, chacun avec son petit bout du gros gâteau que sont les DSI. Je vous invite à rechercher les 8 postures du scrum master, qui regroupent ce que doit faire un scrum master, avec ou sans scrum, avec ou sans le titre.
Depuis plus de 10 ans nous sommes dans la hype de l’agilité. Maintenant que ca devient la norme on se demande si ça sert à quelque chose…