À 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
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
- 2h de temps
- un maximum de 10 personnes
- (30′) Complexité
- (30′) Principes Agile
- (30′) Les mauvaises pratiques Agile
- (30′) Construction d’un discours autour de l’Agilité
Complexité
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
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 ! 😛 |
Les 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. |
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
| 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 :
|
| 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é
- consolider des connaissances,
- structurer un message,
- et pratiquer la transmission à un interlocuteur cible.
| 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
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 🙂
