Une session de Communauté de Scrum Masters

Photo by JESHOOTS.COM on Unsplash

À l’approche de ces fêtes de fin d’année, j’ai proposé à la communauté de Scrum Masters de mon client actuel d’animer la session pour eux. C’était un peu comme mon cadeau de Noël ! En effet, la plupart du temps nous partions plutôt sur une co-construction de 2 Scrum Masters et moi en support mais je me disais qu’ils avaient bien le droit à un break ! 😛

Je vous propose dans cet article une description de la session proposée et comme à mon habitude, une explication de sa mécanique de construction.

Intention

Photo by Nick Fewings on Unsplash

En échangeant avec différents Scrum Masters ici et là, je me suis rendu compte que le coeur de leur métier, “être garant de la méthode” comme je peux l’entendre souvent, était souvent réduit à la connaissance théorique de Scrum et à l’accumulation de telle ou telle pratique, pour ne pas dire la réflexion autour de tel ou tel format de rétrospective.

Un des points qui m’est apparu important à approfondir était la capacité de transmettre, de communiquer autour de ce qu’est l’Agilité et de ce que l’on cherche à atteindre par ce biais.

En effet, il y a pour moi une grande différence entre connaître /  savoir et transmettre / sensibiliser et j’ai l’impression que l’on ne donne jamais vraiment le temps à la pratique de ce second élément.

C’est donc dans cet objectif que j’ai souhaité construire cette session :

Accompagner les Scrum Masters à structurer un discours autour de l’Agilité, en s’adaptant au mieux à leur interlocuteur.

Et pour cela, je vais leur proposer quelques briques de contenu qui m’apparaissent importantes à avoir en tête pour ce genre d’exercice.

Structure

Photo by Christian Fregnan on Unsplash
Dans chaque session de communauté, nous avons droit à :
  • 2h de temps
  • un maximum de 10 personnes
J’ai donc décidé de découper ma session en 4 blocs de 30′ en gardant en tête que plus je pourrai gagner du temps au début, mieux cela sera. La structure sera la suivante :
  • (30′) Complexité
  • (30′) Principes Agile
  • (30′) Les mauvaises pratiques Agile
  • (30′) Construction d’un discours autour de l’Agilité

Complexité

Photo by Ahmad Dirini on Unsplash

L’objectif de cette séquence est de sensibiliser au fait qu’il existe différents domaines de contexte et donc différentes manières d’adresser des problématiques. En effet, une des erreurs que l’on peut souvent retrouver dans les organisations est l’utilisation d’une même stratégie pour des problèmes différents.

Si notre seul outil est un marteau, alors tous les problèmes vont ressembler à des clous

Étant la première séquence d’animation, je voulais pouvoir mettre en mouvement les participants et me suis donc basé sur cet atelier rapide pour introduire la notion de complexité.

Après avoir débriefé l’exercice, nous avons pris un peu de temps pour de la contextualisation afin de concrétiser un peu plus cette notion qui a tendance à rester très théorique pour la plupart.

Je demanda donc à chacun de trouver des situations / problématiques de leur quotidien pour les 3 domaines étudiés :

  • Évident : Sentir, Catégoriser, Répondre
  • Compliqué : Sentir, Analyser, Répondre
  • Complexe : Sonder, Sentir, Répondre

Note : Pour une description plus précise de ces différents domaines, je vous invite à aller voir cet article.

Après quelques minutes de réflexion en sous-groupes, nous avons partagé tous ensemble autour des divers résultats.

Note : il est important de préciser que chaque élément était positionné selon la perception du porteur et que cet exercice est loin d’être simple !

Quelque chose qui apparaît Compliqué pour une personne pourrait apparaitre Complexe pour une autre et les 2 auraient probablement raison, chacune chez elle ! 🙂

Notre point de focalisation était donc plus sur la pratique de la réflexion autour du contexte du problème (et de la démarche de résolution associée) que sur la justesse du positionnement.

Principes Agile

Photo by Glenn Carstens-Peters on Unsplash

L’objectif de cette séquence est de redonner des basiques sur lesquels s’appuyer lors d’un échange, d’une réflexion. Je me suis donc naturellement appuyé sur les principes Agile, que j’aime qualifier de “vaguement précis”, dans le sens où je les trouve plus facilement actionnables que les valeurs Agile – qui elles sont plutôt “précisément vagues”. 🙂

Plutôt que de simplement les lister et de discuter autour, je voulais donner les moyens aux participants d’ancrer un peu plus les idées principales afin de pouvoir les retransmettre plus facilement.

Nous sommes donc partis sur les Pocket-Sized Principles.

Le concept est simple : résumer chaque principe Agile en maximum 3 mots.

Pour cela, j’avais préparé chaque principe Agile individuellement plastifié, que j’ai disposé au sol pour être visibles de tous et un support simple afin de permettre à chacun de mettre ses propres résultats et de les garder sur son bureau après coup.

Note : Le faire en petit sous-groupe peut avoir un intérêt pour stimuler l’échange mais surtout pour se rendre compte que l’on ne voit pas toujours les mêmes choses en premier. La formulation devient alors importante pour ancrer et cristalliser les notions que l’on va garder : et en même temps, il n’y a que 3 mots ! 😛
Cela a donné des résultats du type :

Les mauvaises pratiques

Photo by Maria Teneva on Unsplash
L’objectif de cette séquence est de sensibiliser les participants à quelques mauvaises pratiques.

Maintenant, plutôt que de leur dire simplement que telle ou telle façon de faire n’est pas la bonne, il m’apparaissait bien plus intéressant de les faire réfléchir tout d’abord sur Pourquoi cela était considéré comme une mauvaise pratique (dit autrement quel impact cette pratique peut avoir) et ensuite sur Comment on pouvait faire autrement.

Note : C’est une manière de ne pas focaliser notre attention uniquement sur les pratiques mais également sur les intentions et donc le mindset associé. Nous travaillons donc à la fois sur le “Être Agile” et le “Faire Agile” qui selon moi sont indissociables pour être véritablement pertinents.
Pour l’animation de la séquence, je me suis basé sur un extrait de 10 cartes Agile Smells que m’a gentiment partagé Robin Béraud-Sudreau.

Choix des cartes

Plus que la phrase spécifique intitulant la carte, c’est surtout le thème adressé autour de la phrase qui a été un critère de choix pour moi. Après avoir affiché les différentes cartes sur le tableau, j’ai demandé aux participants :
  • dans un premier temps de définir sur des Post-it oranges la raison pour laquelle cette situation pouvait être considérée comme problématique
  • dans un second temps de définir sur des Post-it jaunes comment ils pourraient faire autrement
L’important pour moi était de ne pas s’atteler à définir des solutions si l’on n’avait pas réussi à définir en quoi la situation était problématique. Le tout étant effectué seul ou en petits groupes pendant une dizaine de minutes pour laisser ensuite place à l’échange et à la prise de recul. Les résultats obtenus sont les suivants : Pour ma part, voici quelques idées de messages que j’avais en tête dans la sélection de ces différentes thématiques :
Bashingomètre Messages
10

Si on se focalise sur “le plus possible, le plus vite possible”, on risque de porter notre attention sur la quantité plus que sur la qualité, sur le coût engendré plus que sur la valeur produite.

Cela ne nous emmène pas forcément à prendre le temps de définir quelle est la bonne chose à produire à quel moment pour avoir le maximum d’impact. Note : La tendance étant plus à faire moins pour faire bien que de produire plus pour augmenter les chances de toucher juste.
20 Plus il y a d’intervenants, plus l’organisation et les responsabilités sont floues. Il y a donc plus de risques d’y avoir des jeux d’égo, des zones d’activités non adressées et des zones de chevauchement.C’est une des raisons pour lesquelles dans une équipe Scrum il n’y a que 3 rôles définis :
  • Un Product Owner : garant de la direction
  • Un Scrum Master : garant du cadre
  • Une équipe qui produit : garante du contenu
36

Il y a ici une problématique d’intention et de mise en oeuvre.

Intention : La rétrospective amène effectivement les personnes à exprimer ce qui peut les avoir gêné dans l’atteinte des objectifs qu’ils se sont fixés mais ce n’est en aucun cas un bureau des pleurs. Ces différents éléments sont à prendre en compte comme base de discussion pour ensemble, en tant qu’équipe, apprendre de son mode de fonctionnement et tenter de faire mieux la prochaine fois.

Dit autrement : avoir plus de ce que l’on veut et moins de ce que l’on veut pas. cf Processus de Responsabilité

Mise en oeuvre : Si la rétrospective est ressentie de cette manière par les participants, c’est probablement que la structure de l’événement est à revoir ! 🙂

Souvent, c’est la difficulté non pas à faire émerger des pistes de solution mais à leur mise en oeuvre effective qui peut générer ce genre de sentiment. C’est un axe important à prendre en considération lors du suivi post Rétrospective.

Une autre raison peut être la difficulté à s’approprier les problèmes et donc à ne traiter que des symptômes sans pour autant en traiter la cause racine.

39

La notion de M.V.P. Cible n’a pour moi simplement pas de sens. Si c’est un M.V.P. ce n’est pas une cible au sens version finale de ce que je souhaite obtenir.

Le M.V.P. est un moyen d’apprendre sur sa proposition de valeur en mettant sur le marché sa version minimale pouvant apporter de la valeur à ses utilisateurs.

Il y a donc de manière intrinsèque un droit à l’erreur accepté et assumé. C’est principalement ce que l’on va ôter aux équipes en parlant de M.V.P. Cible.

40

Imaginez que vous êtes un sprinter sur la ligne de départ de 2 courses simultanées n’allant bien évidemment pas dans la même direction. Lorsque le coup de départ retentit, où courrez-vous ?

D’une autre manière, le fait d’avoir des développeurs membres de plusieurs équipes c’est créer des dépendances dans la structure même de son organisation et donc d’augmenter les probabilités de situations d’indisponibilité et de retard.

43

Le Gemba-Walk est principalement destiné à des rôles de Management qui plutôt que d’attendre de l’information des équipes par du reporting vont plutôt aller voir ce qu’il se passe sur le terrain afin d’écouter les vraies conversations et donc de voir les vrais problèmes.

Le risque principal dans les organisations (et d’autant plus à l’échelle) est de voir une couche de management qui se détache encore plus des équipes opérationnelles plutôt que d’adapter sa posture pour se donner les moyens d’être en support.

51 La situation décrite précise le Daily mais je l’extrapolerai à tout mécanisme du même type comme le Scrum of Scrum voire le PO Sync sous certains aspects. On parle ici à nouveau de 2 choses : l’intention et la mise en oeuvre. L’intention principale des mécanismes de feedback n’est pas de faire un reporting à qui que ce soit mais plutôt de faire acte de la situation actuelle ensemble pour décider ensemble de la meilleure stratégie à venir. Dans la mise en oeuvre, c’est permettre à chacun d’exprimer ses difficultés
52

On parle ici de testeurs mais l’intention est bien de parler plus généralement d’avoir un incrément de produit potentiellement livrable en sortie de sprint.

Cela explique la volonté d’avoir des équipes pluridisciplinaires et d’aller davantage dans du découpage fin de production de valeur.

66 Lorsque l’on entend ce discours, c’est que la revue (abusément appelée “démo”) est considérée comme l’événement résultant de ce que l’on a réussit à produire plutôt que l’événement au coeur de la boucle de feedback sur le produit. La revue n’est qu’un prétexte pour prendre du recul sur le produit et un moyen de créer du lien avec les parties prenantes si elles n’ont pas la possibilité d’interagir plus souvent. C’est un exercice malgré tout difficile dans beaucoup d’équipes qui n’arrivent pas toujours à avoir une vision fonctionnelle de ce qu’ils produisent.
92

Se focaliser sur les heures consommées c’est considérer les coûts plus que la valeur produite.

Les discussions risquent donc de tourner beaucoup plus sur comment réduire les coûts plutôt que sur comment identifier la valeur produite et l’augmenter.

Note : je n’ai pas utilisé les scores de Bashingomètre comme proposé dans la mécanique de jeu original. Je les ai juste utilisés ci-dessus par souci de simplicité de lecture 🙂

Expliquer l’Agilité

Photo by Priscilla Du Preez on Unsplash
Dans cette dernière séquence, nous arrivons à l’étape finale de la session :
  • consolider des connaissances,
  • structurer un message,
  • et pratiquer la transmission à un interlocuteur cible.
Les différents interlocuteurs pouvaient être : manager, sponsor, métier, membre d’équipe (Product Owner, Développeur…).
Note : L’idée était d’adresser des rôles et des positionnements suffisamment différents pour avoir des messages adaptés suffisamment différents ! 🙂

J’ai demandé aux participants, individuellement ou en groupe, d’écrire sur une feuille A3 l’argumentaire de leur discours en se basant sur les éléments de contenu vu précédemment et les besoins de l’interlocuteur choisi.

Cela pouvait prendre la forme de bullet points, de tableaux, d’une facilitation graphique… ce qui pouvait les aider à construire leur message.

Après quelques minutes de travail, chacun s’est entrainé à transmettre son message devant le groupe avant notre débriefing final ! 🙂

Conclusion

Photo by Les routes sans fin(s) on Unsplash

Cette structure semble avoir été appréciée par les participants tant au niveau du fond que de la forme :

  • L’enchaînement des blocs de 30 minutes fait que l’on ne reste pas trop longtemps sur chaque sujet mais au vu de la mécanique de contextualisation, on tente au mieux de rendre à minima concrète chaque notion.
  • Le contenu est assez dense et le rythme assez soutenu donc en terme de facilitation.

Si j’avais à le refaire, je pense que je me débrouillerais pour garder un peu plus de temps pour la dernière séquence afin de consolider et jouer un peu plus sur les différences entre les messages pour un interlocuteur et un autre.

N’hésitez pas à tester et à me faire vos retours 🙂

Partager

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur pinterest
Partager sur email
Partager sur whatsapp
Olivier MY

Olivier MY

Issu d'un cursus ingénieur, je me suis vite rendu compte que mes appétences et compétences tournaient plus autour de l'humain que de la technique. Je suis alors devenu Coach Agile et Coach Professionnel car j'ai toujours voulu contribuer à rendre le monde meilleur. J'accompagne aujourd'hui des individus, des équipes et des organisations vers une meilleure compréhension d'eux-mêmes afin de bâtir ensemble le futur qui leur correspond.

Commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles récents

Thalassagile

Thalass’Agile : une expérience réflexive hors du commun

Il y a des périodes où l’on a besoin de prendre du temps pour soi. Pour faire acte de ce que l’on a vécu, prendre …

LIRE PLUS
Teamwork

Team Building et Matrice Give and Take

Au cours d’une discussion avec Guy Lerat Jr qui me partageait ses aventures d’accompagnement, j’apprends qu’il va devoir organiser un Team Building important pour une …

LIRE PLUS
Photo by Jamie Templeton on Unsplash

Workshop : Améliorer sa posture de conseil

Dans le domaine du coaching Agile se pose souvent la question de la posture de coach. Dois-je être plutôt en posture basse (questionnement, prise de …

LIRE PLUS
Photo by Irina Iriser on Unsplash

L’échec du modèle Spotify

Il y a des articles comme cela qui chamboulent un peu les idées reçues et qui permettent de prendre un peu de recul. C’est le …

LIRE PLUS

Une expérience de facilitation à distance

Dans cette période de confinement où les interactions physiques sont limitées, nous sommes dans l’obligation d’animer nos ateliers à distance à l’aide d’une multitude d’outils. …

LIRE PLUS

Un atelier de clarification de rôle

Transformation Agile petite ou grande échelle, la question des rôles est une problématique assez commune. Pas qu’elle m’apparaisse comme normale, mais souvent car c’est la …

LIRE PLUS
Retour haut de page

Confidentialité et cookies : ce site utilise des cookies. En continuant à naviguer sur ce site, vous acceptez que nous en utilisions. Pour en savoir plus, y compris sur la façon de contrôler les cookies, reportez-vous à ce qui suit : Politique relative aux cookies.

Prenons contact