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 :

20171012_163502

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 ?

Changement de paradigme : du déterminisme à l’empirisme, pourquoi la pilule rouge de doit pas nous empêcher de continuer à utiliser la matrice

« C’est quoi l’agilité ? » Je pense que nous avons tous un peu notre réponse à cette question. Pour ma part, je concentre ma réponse autour de 2 points :

  • Ce sont des valeurs et des principes, RTFM (Read The Fucking Manifesto ^^)
  • C’est un changement de paradigme, du déterminisme à l’empirisme

Pour présenter les valeurs et les principes c’est facile. J’utilise le manifeste agile bien sûr, j’essaye de donner au moins un exemple concret par valeur, et aussi par principe si j’ai un peu de temps.

C’est un peu moins « prémâché » pour présenter le changement de paradigme. Et souvent, j’ai cette question : « Mais si on adopte une approche empirique, ça veut dire qu’on ne planifie et qu’on n’anticipe plus rien ? C’est l’anarchie ? »
Non. Je pense que c’est beaucoup plus complexe que ça.

Je soumets donc cette petite réflexion sur le sujet à l’intelligence collective pour avoir votre feedback et si possible tenter de l’améliorer !

Introduction

En « mode waterfall / cycle en V », dans un monde déterministe, nous essayions d’accumuler des connaissances pour prévoir l’avenir (planification des projets), avant de nous lancer dans la réalisation.

En « mode agile », dans un monde empirique, nous commençons par expérimenter, faire, réaliser, et c’est ainsi que nous gagnons les connaissances. Ces connaissance sont à la fois les connaissances liées au produit (nous le découvrons et l’adaptons au fur et à mesure en fonction des feedbacks clients), et les connaissances liées à l’équipe (dont notre capacité à produire).

Support visuel et discours associé

Je représente ça en général grâces aux triangles (scope-time-cost) que les managers de projet/produit connaissent bien.

Fichier_002

Le discours associé à cette illustration :

Triangle de gauche :

En management de projet/produit classique, nous passons beaucoup de temps à essayer de déterminer très précisément le scope, ce afin d’en déduire un time (planning) et un cost (budget) précis et le plus fiable possible.
Nous commençons ensuite la réalisation. Et tout se passerait bien s’il n’y avait aucun changement, aucun risque, aucune incertitude sur le produit à réaliser, ni aucune incertitude sur la capacité de l’équipe à le produire. C’est impossible, à moins d’être dans une bulle étanche, d’avoir fait le produit une première fois pour être sûr que c’est le bon, et d’avoir des robots à la place d’humains dans les équipes… et encore !
Il y a donc des changements par rapport à ce qui a été planifié. C’est inévitable. Ces changements vont impacter les dimensions scope time et cost, et donc notre planification. Mais quand les trois dimensions sont fixées, par un contrat par exemple, ou par un engagement pris en comité de jalon ou de pilotage… comment faire ? Il reste une dimension dont nous n’avons pas parlé. La qualité. Et malheureusement… c’est souvent la qualité qui est impactée dans les projets « waterfall » quand une équipe est obligée de faire face à un changement tout en étant pieds et poings liés dans ce triangle figé.
Bien sûr ce n’est pas du management de projet « correct ». Il existe le mécanisme des « changes requests » et je suis convaincue que le rôle d’un bon project manager n’est pas de préserver coûte que coûte la planification, mais bien de gérer ces « change requests » de manière à faire évoluer le triangle scope-time-cost tout en le gardant sous contrôle. Mais cette « théorie » est peu compatible avec notre culture réfractaire au risque et qui cherche à tout prix l’engagement ferme et définitif (oh combien illusoire) pour se rassurer (à ce sujet, je renvoie à la théorie des dimensions culturelles de Geert Hofstede, c’est passionnant)… et parfois tout simplement inapplicable de par la dérive administrative qu’elle engendre face à des changements trop fréquents.
Bref. Ce n’est pas simple.

Triangle de droite :

En mode agile maintenant. Nous commençons par définir une vision. Une vision ce ne sont pas du tout des spécifications ! C’est ce que l’on a au lancement du projet/produit comme idée de ce que l’on veut réaliser. Elle peut se limiter à un elevator pitch par exemple.
Ensuite, on fixe les dimensions time et cost. C’est « facile » : pour quand voulons-nous une première version de notre produit, combien d’argent sommes-nous prêts à investir au regard de sa proposition de valeur (qui doit être claire dans la vision) ?
A partir de là, on commence à réaliser. Et pendant toute la réalisation, notre variable d’ajustement sera la dimension scope par les mécanismes de gestion du product backlog, alimenté par les boucles de feedback.
La contrepartie à cette flexibilité sur le scope est la rigueur sur la qualité : la qualité n’est plus une variable d’ajustement.
Cela signifie aussi avoir le courage d’arrêter un projet/produit si nous découvrons (toujours par les boucles de feedback) que nous faisons fausse route… Notion de droit à l’erreur etc etc.
Bref… ce n’est pas simple non plus !!! Mais peut-être plus adapté pour certains projets/produits et dans tous les cas plus réaliste et transparent. Nous reconnaissons les incertitudes, regardons les risques en face et c’est la seule manière de s’ouvrir également aux opportunités (la version « positive » des risques) .

Insister sur la bascule

Ce n’est pas qu’un nouveau process, une nouvelle manière de gérer les projets. Et c’est pour ça que passer d’un processus jalonnés à l’application de Scrum ne suffit pas à être agile. Découper des spécifications détaillées pour les donner bouchée par bouchée à l’équipe au fur et à mesure des itérations tout en vérifiant qu’on respecte bien les engagements scope-time-cost, ce n’est pas être agile !

Passer d’un mode déterministe à un mode empirique, c’est un vrai changement culturel. Philosophique.

Petit tour sur la page wikipédia « Empirisme » :

L’empirisme désigne un ensemble de théories philosophiques qui font de l’expérience sensible l’origine de toute connaissance ou croyance et de tout plaisir esthétique. L’empirisme s’oppose en particulier à l’innéisme et plus généralement au rationalisme « nativiste » pour lesquels nous disposerions de connaissances, idées ou principes avant toute expérience.

… Et il peut être aussi difficile de « passer de l’autre côté » que de faire marche arrière.

pill

This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.

[Morpheus, Matrix]

Mixer les deux approches ?

Si ce changement de paradigme est une bascule, est-ce qu’il est possible d’avoir une approche « mixte » ?

Je pense que oui. En fait, je pense qu’il faut trouver le bon compromis entre le 100% déterministe qui paralyse (je veux absolument tout prévoir avant de faire le premier pas) et le 100% empirique qui peut être anxiogène (essayez de marchez les yeux bandés sans avoir préalablement visualisé votre parcours…)

Pour faire le lien avec les techniques de management de projet/produit, je rapproche ça du management des risques/opportunités : il faut trouver le bon compromis car sans prise de risque, rien de nouveau et un bon management des risques ne veut pas dire chercher à les éviter à tout prix !

Je pense que ce compromis dépend : du produit, de l’équipe, du contexte, et de la phase dans laquelle nous sommes.

Rapport aux méthodes (en tout cas celles que je connais un peu ^^)

  • Scrum est une proposition qui fait un compromis entre empirisme et déterminisme. L’approche est globalement empirique à l’échelle du développement du produit, mais les sprints sont déterministes.
  • XP serait un peu plus empirique que Scrum (itérations plus courtes, possibilité de prendre en compte des changements pendant les itérations).
  • Kanban (et le mode flux continu vs. itérations) serait le plus empirique

PS : un jour il faudra que je fasse un retour d’expérience complet sur un de mes anciens projets pour lequel nous avons fait la première release en mode « classique jalonné », la deuxième en Scrum et la troisième en Kanban…

Quand j’entends parler de mode « hybride », j’ai l’impression que l’on cherche une autre proposition de framework entre le « mode classique » et Scrum, donc a priori plus déterministe que Scrum mais en pouvant intégrer du changement en cours de réalisation… pourquoi pas.

Première valeur agile :

Les individus et leurs interactions plus que les processus et les outils

Nous devons adapter les process et des outils, du moment que c’est fait pour de bonnes raisons et en connaissance de cause (petit lien vers l’excellentissime conférence de Claude Aubry « Scrum ? mon scrotum ! » sur les dérives de Scrum, dont l’adaptation du process pour de mauvaises raisons (genre : « nan, mais on a arrêté les daily… trop contraignant… et puis l’agilité c’est d’adapter les process, non ? »).

Alors adaptons-nous (et faisons-le correctement) et trouvons le bon compromis entre empirisme et déterminisme en fonction du produit, de l’équipe, du contexte, du moment.

Nous avons pris conscience que notre ancien monde de prévisions et d’engagements n’est qu’une matrice fictive dans laquelle nous nous réfugions par peur du changement, des risques et de l’échec. Nous avons pris la pilule rouge, suivi le lapin blanc dans la réalité, le concret, l’expérimentation.
Et pourtant, ne nous interdisons pas d’utiliser les possibilités de la matrice quand celles-ci peuvent nous servir !

07202682-photo-matrix.jpg

La prise de conscience est indispensable et irréversible. Après le reste… ce ne sont que des processus et des outils ! 🙂