Depuis que j’ai commencé à travailler en agilité, enfin, en Scrum, une question revient toujours et encore: Le Scrum Master est-il membre de l’équipe de développement?
Je ne donne jamais de réponse toute faite à cette question. Ca va sans doute vous surprendre, mais tout dépend du contexte. Voici cependant quelques retours sur des expériences que j’ai eu l’occasion de vivre ou de voir en direct.
Ma première expérience de Scrum Master
Lorsque je me suis lancé en agilité, avec mes collègues chez AOL Europe à Bristol, nous n’étions que des développeurs et nous avons tous suivi la formation Scrum en même temps.
A cette époque, nous nous cherchions sur le mode de fonctionnement et ce que nous avions décidé c’était de mettre en place le rôle de Scrum Master en tournant, afin que chacun puisse expérimenter cette responsabilité.
Ce mode de fonctionnement a porté de bons fruits. Au bout de quelques itérations, certains d’entre nous avaient compris que ce rôle n’était pas pour eux, d’autres y avaient pris gout.
Si on analyse bien, à postériori, ce qui s’est passé à ce moment là, je pense qu’on peut dire que nous étions, avant même de nous lancer en Scrum, dans une situation d’autonomie qui nous a permis de ne pas avoir à passer par le mode Scrum mom si souvent empreinté par les Scrum Masters au lancement des équipes.
Ensuite, j’ai eu la chance de rencontrer plusieurs types de situations:
-Un individu nommé Scrum Master au sein d’une équipe, mais sans rôle de développeur
-Un individu nommé Scrum Master pour une équipe mais volontairement externe à celle-ci (pour garder une prise de recul)
-Un développeur qui assume juste un rôle complémentaire
-Un individu dont la fonction officielle (et le titre de poste) est Scrum Master et qui prend en charge plusieurs équipes (jusqu’à 3 en même temps)
-…
Dans tous les cas, j’ai pu remarquer quelques dérives que je me propose de vous exposer.
Un Scrum Master non disponible
Quoi qu’il arrive, le Scrum Master se doit d’être disponible pour l’équipe. Il en est le servant leader selon le Scrum Guide, dans la pratique, il aide à identifier et à lever les freins, il produit un certain nombre d’indicateurs pour le produit…
Dans le cadre d’un Scrum Master qui ne soit pas dédié à l’équipe, il arrive souvent que les remontées de l’équipe lors des rétrospectives ou des gembas soient orientées autour du manque de disponibilité de celui-ci. Et ce manque de disponibilité entraine une gestion des freins plus lente, une production des indicateurs et/ou un suivi du management visuel à retardement…
De plus, l’aspect servant leader du Scrum Master non disponible est souvent difficile à cerner pour les interlocuteurs de l’équipe, surtout si on ne le voit pas durant les rituels ou lorsqu’on s’approche de l’équipe durant l’itération.
Ce manque de disponibilité du Scrum Master est alors souvent responsable d’un manque de transparence (à cause du délai) et éventuellement un défaut d’adaptation… Bref, 2 des piliers de l’empirisme et donc de Scrum….
Un Scrum Master non impliqué
Parfois, le Scrum Master a beau être disponible, lorsqu’il n’est pas dédié à l’équipe, il peut se sentir non impliqué. Forcément, au delà de l’aspect implication humaine, un individu qui passe de sujet en sujet, notamment dans le cas d’un Scrum Master sur plusieurs produits (équipes), aura du mal à se sentir 100% impliqué dans le travail d’une équipe.
Dois-je détailler ce qu’engendre un manque d’implication de la part d’un Scrum Master?
-Une animation de l’équipe qui laisse à désirer
-Un manque d’engagement dans la résolution des freins
-Un manque de communication avec le PO…
Un Scrum Master en mode Scrum Mom continu
J’ai également rencontré un certain nombre de Scrum Master qui restent en Scrum Mom malgré une équipe en fonctionnement sur le produit/projet depuis un grand nombre de cycles (itérations/sprint).
Cette situation est plus facilement rencontrée lorsque le titre « Scrum Master » est la fonction officielle de notre individu. Le fait d’avoir ce titre, induit alors une justification continuelle de sa fonction.
Pas que le mode « Scrum Mom » soit mauvais, mais s’il dure trop longtemps, l’équipe ne prend pas vraiment la main sur son fonctionnement et les aspects de prise d’autonomie et d’auto-organisation sont alors facilement mis de coté: « Notre Scrum Master le fait, donc on va pas chercher à le prendre en charge ».
Cette situation est compliquée d’un point de vue accompagnement car, même si en agilité le changement intervient aussi souvent que nécessaire, il faut alors commencer à faire changer les postures de tous les membres de l’équipe sans justification de changement de Framework/méthode…
Un Scrum Master de facade
A l’opposé, en dehors du manque d’implication, j’ai aussi parfois rencontré des Scrum Master de façade. Le Scrum Master ne fait rien pour l’équipe qui est totalement auto-organisée et autonome mais sert uniquement comme interface avec le management (l’organisation) ou les partie prenantes. Il n’est pas rare que ces personnes se remettent souvent en question voire, en perde en implication…
Des équipes sans Scrum Master?
J’ai l’habitude de dire en formation, que le rôle d’un Scrum Master c’est de se rendre non-indispensable. Lorsqu’il n’est pas là l’équipe tourne bien, lorsqu’il est là, elle tourne un peu plus facilement.
De mon point de vue, si on ne veut pas se retrouver avec un Scrum Master qui ne soit que de façade, ou qui se sente non impliqué… il est important que le Scrum Master fasse partie de l’équipe quoi qu’il arrive. Alors, s’il est développeur également, son positionnement dans l’équipe n’est pas remis en question et il peut passer de moins en moins de temps à faire le Scrum Master et de plus en plus à être le développeur.
Bien sur, comme dans toute expérience, j’ai également vu l’opposé, avec un Scrum Master externe à l’équipe, qui continue à être pertinent et impliqué tout en étant de moins en moins présent (demandé) pour l’équipe. Mais à chaque fois, celui-ci avait évolué dans un rôle plus transverse au niveau de l’organisation avec des aspects de coaching de l’intégralité des équipes et donc son implication dans l’équipe était liée à sa fonction officielle.
Lorsque le Scrum Master n’est pas lié à la transformation agile de l’organisation de par sa fonction officielle, sans exception jusqu’à maintenant, je l’ai vu se détacher de l’équipe qui s’autonomise. Cette équipe s’est alors retrouvée sans Scrum Master de fait.
Cette situation n’a jamais été un souci pour l’équipe en elle même, cependant, les organisations ont généralement du mal à accepter cet état. La solution qu’ils adoptent à chaque fois est de nommer un Scrum Master de façade au sein de l’équipe. Je ne pense pas que ce soit le meilleur choix, mais c’est alors sans doute le seul à leur disposition. C’est là, notamment, qu’il est urgent de retourner aux bases même de l’agilité, de l’équipe auto-organisée et de repenser la manière de fonctionner de l’équipe au sein de l’organisation.
Il est alors parfois indiqué d’envisager une sortie du modèle Scrum (officiellement) afin qu’une personne extérieure à l’équipe ne s’attende plus à rencontrer des rôles pré-établis. Ces rôles étant connus via un langage du marché, mais qui n’ayant plus de sens vu l’état de maturité agile de l’équipe.
PS: j’adorerais lire vos retours sur le sujet!
[…] Oui… et non en fait. Le Scrum Master est inhérent à Scrum, et même dans le meilleur des déploiements Scrum que j’ai pu voir mis en place, je n’ai jamais vu disparaitre totalement la notion de hiérarchie. Les équipes sont forcément liées à un manager, et je déconseille généralement d’avoir un Scrum Master également responsable hiérarchique des membres de l’équipe. J’ai en partie parlé de mon point de vue dans ce billet. […]