Et quand personne n’a envie d’être ScrumMaster ?

Vous avez peut-être déjà été confronté à cette situation… De ma courte expérience de coaching agile j’ai l’impression que ça peut arriver assez souvent finalement.

Vous avez une bonne équipe, tous les « team members » (au sens de Scrum, toutes spécialités confondues) sont compétents et motivés… Et personne n’a envie d’être le Scrum Master.

Bien sûr tout ça dépend du contexte, mais j’ai l’impression que les causes sont souvent un peu les mêmes :

• Le rôle n’intéresse pas : quand ma passion c’est le dev, le design, l’ergonomie… je veux avant tout faire, pas être en support
• Le rôle paraît rébarbatif : trop souvent on confond « être au service de l’équipe » avec « faire tout ce que les autres n’ont pas envie de faire et qu’il faut faire quand même ».
• Le rôle n’est pas reconnu dans l’entreprise : méconnu, pas valorisé, voire même complètement ignoré

Romain Couturier explique ça très bien dans sa conférence « Qu’est-ce qu’un ScrumMaster » : quand Scrum arrive dans l’entreprise, il est logique de se demander comment s’en sortir avec ces nouveaux rôles et l’organisation existante.

• Team Members, c’est facile
• Product Owner… entre responsable produit, chef de projet, marketing, c’est pas super simple mais on devrait quand même arriver à trouver quelqu’un pour ce rôle (et souvent on se plante, mais je ferais peut-être un autre article à ce sujet ^^)
• Mais Scrum Master ? Qui est-ce que ça peut bien être ? C’est complètement nouveau.

Ce n’est pas une fonction de production, ni une fonction décisionnaire. C’est une plutôt une fonction support. On pourrait penser aux managers, mais le changement de posture est tellement radical que j’ai du mal à l’envisager (et même avec un manager qui renonce complètement à tout pouvoir et tout contrôle sur l’équipe, encore faut-il que TOUS les membres de l’équipe le perçoivent ainsi… car les relations c’est dans les deux sens !).

Alors du coup on se retrouve avec des Scrum Masters tournants. Personnellement je n’aime pas vraiment cette pratique, tout simplement parce que se passer la patate chaude ça n’aide pas à monter en compétence sur le rôle et donc à avoir de bons Scrum Master. Forcément, quand on n’a pas envie et qu’en plus on a autre chose à faire…

Et quand ça va mal parce que on n’a pas investit le temps l’énergie et la compétence dans ce rôle, on appelle un coach agile 🙂

L’équipe en a marre. Personne ne voulait faire Scrum Master, un rôle tournant a été mis en place (par exemple), mais ça se passe mal, il y a de plus en plus de tensions, et du coup plus personne ne veut être Scrum Master.

Ce n’est qu’une proposition, mais voilà ce que j’ai tenté et qui s’est bien passé dans ce type de situation.

On suppose que l’équipe veut continuer à travailler en Scrum, ce qui dans les situations auxquelles je pense était le cas.

1. Recadrer Scrum

C’est souvent l’urgence. Alors oui, ce n’est pas du coaching agile et c’est plutôt prendre temporairement (et malheureusement partiellement si je ne suis pas à temps plein dans l’équipe) le rôle de Scrum Master.

Mais pour désamorcer les tensions, je pense qu’il faut souvent passer par là : re-clarifier les rôles, redonner du sens aux cérémonies…

2. Animer une décision collective par consentement sur un mode de fonctionnement autonome pour la suite

Ça doit être clair dès le début : en tant que coach agile, je ne resterai pas dans l’équipe, mon premier objectif est qu’on n’ait plus besoin de moi ! Je ne peux donc pas rester en tant que Scrum Master, mais je peux les aider à trouver un mode de fonctionnement autonome.

Pour cela, quand Scrum a été recadré et les tensions liées à ce rôle désamorcées, je leur propose un atelier spécifique.

Déjà, on clarifie les attentes de l’équipe vis à vis du rôle de Scrum Master.
En mode brainstorming, chacun note sur de post-its ses attentes. Pour le regroupement, j’utilise ce type de paperboard :

Remarque : la première fois que je l’ai animé, je n’avais que l’axe vertical sur la criticité du besoin. Mais j’ai eu des attentes qui ne faisaient pas vraiment partie du rôle de Scrum Master… du coup je pose maintenant deux questions à l’équipe :

• Est-ce que cette activité fait vraiment partie du rôle de Scrum Master ? (et j’en profite pour rappeler un peu ce qu’est le rôle, vis à vis de l’équipe de réalisation, du PO, et de l’organisation)
• A quel point est-ce que vous en avez besoin ?

Une fois ce paperboard réalisé, je le laisse de côté pour le moment. Il a servi à aligner les membres de l’équipe sur leurs attentes, mais on devra peut-être y revenir…

Ensuite, je leur demande de lister les différentes possibilités d’organisation. J’avoue que là je les aide un peu avec ce que j’ai pu observer dans d’autres équipes. En gros ça donne :

• Une personne de l’équipe prend le rôle –> –> je précise tout de suite que si cette option est sélectionnée, on continuera avec une élection sans candidats
• Rôle tournant
• L’équipe recrute un Scrum Master (si c’est envisageable)
• L’équipe se réparti les tâches du Scrum Master
• L’équipe fait appel ponctuellement à un facilitateur pour l’animation des rétros, mais se réparti les autres tâches

Ensuite, j’anime une prise de décision collective par consentement, on retient l’option pour laquelle il reste le moins d’objections (sachant bien sûr que j’insiste sur le côté expérimental, quelle que soit la décision prise il faudra en discuter aux prochaines rétros pour la valider ou non).

Dans le cas où l’équipe se réparti les tâches (dernière et avant-dernière option), on reprend alors le paperboard précédent pour décider de qui fait quoi.

Au final, je ne l’aurais pas cru au premier abord, mais cette option de se répartir les tâches a l’air de plutôt bien fonctionner…  Je pense qu’il y a trois raisons à ça :

• ça limite la charge de travail : on peut prendre la tâche de l’animation des rétros uniquement par exemple et se concentrer la plus grande partie de son temps sur son rôle de Team Member ou Product Owner
• c’est issu d’une réflexion collective et chacun a eu l’occasion de se positionner sur les tâches qui lui plaisaient le plus
• ça permet quand même la montée en compétence, même partielle : celui ou celle qui a pris l’animation du sprint planning par exemple va être de plus en plus à l’aise d’itération en itération dans ce rôle. Et c’est pareil pour tous les autres rôles (animation, organisation logistique des cérémonies, gardien des règles Scrum et des valeurs agiles… c’est en général ce type de tâches qui ressortent)

Pour moi c’est une vraie surprise mais pour les deux équipes que je connais et qui ont choisi cette option ça a l’air de leur convenir et de bien fonctionner… alors pourquoi pas !

Et vous, comment gérez-vous cette situation ?