Quand un ScrumMaster a-t-il terminé ?

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Alexey Krivitsky (@alexeykri)
Source : When Is A ScrumMaster Done?
Date : 26/06/2015


Traducteur : Fabrice Aimetti
Date : 30/06/2015
Dédicace : Stéphanie, Gaëtan et Xavier


Traduction :

pr-seo-natural-digital-evolution.png

Image prise sur https://passion.digital/blog/2014/10/21/pr-seo-natural-digital-evolution/

  • Combien d'équipes un ScrumMaster peut-il accompagner ?
  • Comment un ScrumMaster peut-il savoir s'il fait un bon (mauvais) travail ?
  • Que pourrait-il ensuite y avoir dans l'agenda d'un ScrumMaster ?
  • Quand un ScrumMaster a-t-il terminé ?


Une fois que vous commencez à travailler en tant que coach d'équipe (ScrumMaster), ce genre de questions est fréquent. Je me les pose encore régulièrement. Parce qu'on dirait parfois que rien n'avance. Pendant que vos équipes développent, refactorent, écrivent des tests, automatisent le déploiement, packagent les fonctionnalités... vous êtes juste en train de faire ScrumMaster. Cela devient vraiment difficile de savoir si vous faites quelque chose de correct. Je sais ce que l'on ressent.
Une manière utile de regarder ce problème complexe consiste à envisager la maturité de l'équipe. Une fois, j'ai réalisé que mon travail de ScrumMaster était devenu beaucoup plus concret, planifiable, actionnable et satisfaisant !
La plupart d'entre vous a entendu parler du célèbre modèle de Tuckman qui décrit la dynamique de groupe du forming au performing en passant par le storming et le norming (il y a une 5è étape adjourning, sans intérêt pour le moment). Le modèle est connu depuis des dizaines d'années. Il est puissant tout en restant simple. Et comme tout modèle, il est faux, mais il peut néanmoins se révéler utile pour expliquer certains phénomènes complexes comme par exemple la formation d'une équipe :
tuckman-maturity-model_fr.png
Le modèle est tellement universel que l'on peut relativement bien expliquer toute dynamique de collaboration humaine avec. Par exemple : vous pouvez expliquer la raison pour laquelle les jeunes couples ont tendance à se taper dessus, comment des entreprises fonctionnent après une fusion, comment une équipe réagit au processus de changement. Il peut même expliquer à quoi peut ressembler l'adoption de Scrum au sein d'une équipe.
Je vais juste un peu modifier le modèle pour le rendre visuellement plus sexy et légèrement plus explicatif. C'est la façon dont j'ai appris à interpréter la dynamique d'adoption de Scrum par une équipe donnée :
scrum-adoption-dynamics_fr.png

Selon mon expérience de démarrage des équipes Scrum (6 années de consulting dans ce domaine), je peux vous affirmer que l'étape 'jaune' dure 1 à 5 sprints. Si cela dure plus longtemps, l'équipe fait juste semblant d'appliquer les règles Scrum (ce qui arrive malheureusement assez souvent et c'est pourquoi un coach intolérant à toute tentative de torsion de Scrum est très utile dans cette étape).
Si une équipe continue à mettre en oeuvre le noyau Scrum correctement, alors après l'étape 'jaune' heureuse (les ignorants sont bénis !), elle passe dans l'étape 'rouge'. C'est lorsque la transparence fournie par Scrum permet aux personnes de voir des choses qu'elles ne sont pas prêtes à voir.
- Quelle est la meilleure chose qu'un ScrumMaster puisse réaliser dans l'étape 'jaune' ?- Amener l'équipe dans l'étape 'rouge' dès que possible en les aidant à faire correctement du Scrum.- Comment ça se passe pour qu'une équipe qui fait un Scrum 'propre' atteigne l'étape 'rouge' ?- Scrum peut-être vu comme un super ensemble de boucles de feedbacks (produit, processus, équipe), chaque activité de Scrum contribue à l'une des boucles de feedback. Donc, en pratiquant Scrum, les équipes génèrent un nombre incroyable de feedbacks sur la manière dont elles fonctionnent. Le système commence à se regarder. C'est pourquoi on compare parfois Scrum à un miroir.- Comment un ScrumMaster peut-il aider l'équipe à faire du Scrum correctement à l'étape 'jaune' ?- En étant simplement avec l'équipe : ce qui inclut le fait de binômer avec un Product Owner, faciliter les réunions Scrum, aider chacun à ressentir le rythme cardiaque des sprints, célébrer souvent les petites victoires... Faire des modifications dans le bureau (en réarrangeant les bureaux) peut également amplifier la sensation de "vent du changement".- Alors pourquoi est-ce aussi important d'amener l'équipe dans le 'rouge' ?- Parce que c'est uniquement après l'étape 'rouge' que les changements réels dans l'organisation vont réellement pouvoir commencer à apparaître. Même si traverser l'étape 'rouge' peut-être vraiment houleux.
En fait, rien ne prépare une équipe à constater combien son processus de livraison est boiteux, combien elle peut être si mauvaise à prendre des décisions, combien les personnes du métier connaît aussi mal le marché, combien les développeurs peuvent être inefficaces à maintenir le code (bon, ça, elle l'a probablement déjà appris depuis un long moment), ...
Bien sûr, ces choses peuvent générer un sentiment de honte. Les visages vont rougir. Et si nous faisons confiance à un autre puissant modèle sur la façon dont les personnes acceptent (ou plutôt évitent) la responsabilité, alors nous pouvons apprendre ceci : lorsque nous avons honte, nous sommes également sur le point de nous justifier ou d'accuser les autres. C'est de cette manière que vous pouvez savoir que votre équipe est toujours dans l'étape 'rouge'. Parce qu'il est si facile de commencer à accuser le processus : "Scrum n'est pas compatible avec notre culture... Scrum ne fonctionne pas... Faisons des sprints de 6 semaines... Essayons Kanban !"
Avez-vous entendu ce type de déclarations ? Si oui, vous savez alors ce que je veux dire par l'étape 'rouge'. C'est la raison pour laquelle je pense que cette étape est la plus dangereuse dans l'adoption de Scrum. C'est à ce moment-là que le canari peut mourir dans la mine de charbon.

  • Disclaimer : Je n'ai rien contre la méthode Kanban. En fait, je respecte et j'aime sa philosophie. Je n'apprécie tout simplement pas lorsque le fait de basculer à Kanban est utilisé comme une excuse pour ne pas résoudre les problèmes de l'organisation. En fait, une fois que vous commencez à appliquer correctement la méthode Kanban, vous rencontrez probablement les mêmes dysfonctionnements que Scrum avait préalablement mis en reflet. C'est simplement parce qu'ils concernent l'organisation (à moins qu'une méthode soit faite pour les masquer, mais c'est une autre histoire).


- Que fait un ScrumMaster pendant l'étape 'rouge' ?- Un bon ScrumMaster fait preuve d'empathie vis-à-vis de l'équipe. Il sait que c'est difficile : il a déjà accompagné d'autres équipes et les a déjà aidé à traverser le fossé. Il n'arrête pas de les encourager. Une facilitation correcte des rétrospectives devient vital puisque l'équipe commence à faire émerger des problèmes difficiles. Se concentrer sur le positif, aider à le percevoir en utilisant des outils comme l'appreciative inquiry est ce que peut faire de mieux un ScrumMaster.- Comment un ScrumMaster sait-il que l'équipe est sortie de la zone 'rouge' ?- Et bien c'est généralement assez évident. Puisque le ScrumMaster est un observateur doué, il remarque un jour que les membres de l'équipe discutent du problème suivant à traiter. Mais cette fois, au lieu d'accuser les autres équipes, les managers, leur Product Owner, le processus, ils acceptent le fait que le seul moyen de changer la situation est de commencer par prendre des actions.
C'est un très grand changement. Je l'ai mis en évidence sur le modèle avec une ligne rouge verticale qui divise le modèle en deux parties. Il s'agit d'un moment critique qui, une fois traversé par l'équipe, ne réapparaît plus (à moins que vous changiez la composition de l'équipe en ajoutant / supprimant des personnes). Cela sépare bien les choses entre "Faire de l'agile" et "Etre agile". C'est un changement culturel.
Une fois que vous en êtes là, tout semble plus facile et devient fluide. Cela peut même être ressenti comme ennuyeux, la manière dont les choses sont détendues comparées au sprint précédent. C'est généralement à ce moment que le ScrumMaster arrête de voir les bénéfices qu'il peut apporter à l'équipe.
- Donc, que fait un ScrumMaster une fois que l'équipe a atteint la zone 'bleue' ?- Et bien, il peut maintenant se reposer sur ses lauriers et écrire des articles sur la qualité de son Scrum et... Non ! Evidemment, le travail ne s'arrête pas là. Sincèrement, ce n'est jamais terminé. Mais désormais le ScrumMaster a du temps pour se concentrer sur un spectre plus large : le recrutement, la rémunération, l'évaluation, le style de leadership, les communautés de pratiques, la livraison continue, ... Il voit maintenant le monde extérieur à l'équipe, qu'il faut l'accompagner et qu'il faut un meilleur management.- Est-ce que cela signifie que le ScrumMaster peut quitter l'équipe ?- Non, pas vraiment. Mais il n'est plus un élément central sur lequel tout repose. Si un jour, il se rend chez son dentiste et qu'il ne se montre pas à la mêlée quotidienne, la réunion se passe comme les précédentes, parce que l'équipe comprend les valeurs essentielles des pratiques. Faire émerger et mentorer des facilitateurs au sein de l'équipe peut être très utile à ce stade. Cela libère encore plus de temps pour le ScrumMaster et (plus important encore) cela aide l'équipe à s'approprier encore plus le processus. Maintenant, le ScrumMaster peut penser à accompagner une seconde équipe qui en est à l'étape 'jaune'.
---
J'ai déjà vu plusieurs équipes à l'étape 'verte'. Et c'est vraiment très inspirant et ressourçant. C'est l'une des plus belles choses qu'en tant que coach d'équipe, vous pouvez observer pendant votre carrière.
J'ai malheureusement aussi vu des équipes régresser sur ce modèle. Le modèle n'est pas linéaire. L'Agilité est fragile. Tout nouveau membre de l'équipe avec un fort charisme et souhaitant tout régenter peut tirer l'équipe vers le bas. C'est pourquoi même les équipes 'vertes' ont besoin de coachs d'équipe qui jouent le rôle de facilitateurs et de challengers du processus.
Le monde est en fait bien plus compliqué que tous les modèles disponibles... Ca m'intéresse quand même de savoir si vous trouvez que le modèle de Dynamique d'Adoption de Scrum est aussi utile que je le pense.
Si vous avez aimé ce sujet et mon style, vous aimerez sans doute aussi les billets suivants :