Liste de contrôle pour Scrum Master
Un bon Scrum Master peut s'occuper de deux ou trois équipes en même temps. Si tu te contentes de limiter ton rôle à l'organisation des réunions, au respect des délais et à la résolution des problèmes de l'équipe, le rôle de Scrum Master peut fonctionner à temps partiel. L'équipe dépassera certainement les attentes qu'avait ton organisation avant Scrum, et il n'y aura probablement pas de catastrophes majeures.
Mais si tu peux imaginer une équipe qui prend plaisir à créer des choses qu'on n'aurait jamais crues possibles auparavant, alors tu dois aussi avoir la volonté d'être un excellent Scrum Master.
Un excellent Scrum Master ne peut s'occuper que d'une seule équipe à la fois.
C'est pourquoi nous recommandons, surtout pour la phase de démarrage, un Scrum Master motivé et engagé pour une équipe d'environ sept personnes.
Si tu n'as pas encore de vue d'ensemble sur tout le travail à accomplir, essaie d'en apprendre davantage sur le Product Owner, l'équipe, les méthodes de développement de l'équipe et l'organisation dans son ensemble. Même s'il n'existe pas de recette miracle, voici quelques points auxquels un Scrum Master devrait prêter attention :
Checklist Scrum Master pour le Product Owner
Tu peux augmenter l'efficacité du Product Owner en l'aidant à s'occuper du Product Backlog et du plan de release. (Garde toutefois à l'esprit que seul le Product Owner devrait prioriser le Backlog.)
La priorisation du Product Backlog correspond-elle aux réflexions et aux visions les plus récentes du Product Owner ?
Toutes les exigences et souhaits de toutes les parties prenantes ont-ils été intégrés au backlog ? N'oublie pas que le backlog peut constamment évoluer.
Le Product Backlog a-t-il une taille facilement gérable ? Pour conserver un nombre d'items que l'on peut bien maîtriser, les items détaillés devraient se trouver tout en haut du backlog et les sujets plus généraux plutôt à la fin. Il est contre-productif d'entrer trop dans les détails pour plus que les items du sommet, car les exigences vont constamment évoluer avec le développement du produit et les échanges permanents avec les clients/parties prenantes.
Y a-t-il des exigences (particulièrement celles tout en haut du backlog) qui pourraient être mieux rédigées sous forme de User Stories indépendantes, négociables, ayant de la valeur, estimables, petites et testables (critères INVEST) ?
As-tu informé ton Product Owner sur la dette technique et comment l'éviter ? Il peut être utile d'ajouter des tests automatisés et du refactoring à la Definition of Done de chaque item du backlog.
Le backlog est-il facilement consultable comme source d'information pour toutes les parties prenantes ?
Disposes-tu d'un outil automatisé pour gérer le backlog ? Et si oui, t'apporte-t-il réellement quelque chose ? Ces outils présentent en effet le risque de rendre difficile la recherche des informations si le Scrum Master ne communique pas activement ces informations.
Peux-tu aider à communiquer les informations en les imprimant et en les distribuant à toutes les personnes impliquées ?
Peux-tu aider à communiquer ces informations en créant de grands schémas et diagrammes bien visibles ?
As-tu aidé le Product Owner à répartir les items du backlog en releases appropriées ? (Par ex. en travaux en cours (Front Burner), travaux à venir (Back Burner) et éléments qui ont été ajoutés au backlog mais pas encore préparés davantage (Fridge).)
Toutes les parties prenantes (y compris l'équipe) savent-elles si le plan de release – mesuré par rapport à la vélocité actuelle (par ex. Story Points par Sprint) – correspond toujours à la réalité ?
Le Product Owner a-t-il mis à jour le plan de release après la dernière Sprint Review ? Peu de Product Owners qui livrent à temps des produits suffisamment testés mettent à jour le plan de release à chaque Sprint. Souvent, ils reportent certains travaux sur des releases futures dès que des travaux plus importants apparaissent. Essaie donc les Product/Release Burndown Charts selon Mike Cohn, que tu peux présenter à toutes les personnes impliquées après que les items ont été confirmés « done » lors des Sprint Review. Cela permet de détecter facilement les changements de périmètre ou de planning à un stade précoce.
Checklist du Scrum Master pour l'équipe
1.) Les membres de l'équipe sont-ils la plupart du temps dans le « flow » ? Voici quelques caractéristiques de cet état : des objectifs clairs (les attentes et les règles sont identifiables ; les objectifs sont atteignables et correspondent aux compétences de chaque personne) ; concentration et focus (focalisation sur un point précis) ; incertitude réduite (les actions et la conscience fusionnent) ; perte de la notion du temps (la perception subjective du temps change) ; feedback direct et immédiat (les succès et les échecs pendant l'action sont clairement identifiables, ce qui permet d'adapter le comportement si nécessaire) ; équilibre entre compétences et défi (ce n'est ni trop difficile ni trop facile) ; sentiment de contrôle personnel sur la situation/l'action (l'action est une tâche intrinsèquement gratifiante et donc sans effort).
1.) Les membres de l'équipe semblent-ils bien s'entendre ? Font-ils des choses ensemble ? Célèbrent-ils les succès de leurs collègues ensemble ?
2.) Les membres de l'équipe veillent-ils à ce que chacun respecte les standards élevés ? S'encouragent-ils mutuellement à s'améliorer ?
3.) Y a-t-il des problèmes ou des opportunités dont l'équipe ne parle pas parce qu'elle ne se sent pas assez à l'aise ? Tu peux faire appel à un professionnel qui peut t'aider à rendre les conversations difficiles plus faciles. (Ou lis-en plus sur le sujet dans le livre Crucial Conversations: Tools for Talking When Stakes are High)
4.) As-tu déjà essayé différents formats et lieux pour tes Sprint Review Meetings ? Tu trouveras quelques idées dans le livre Agile Retrospectives: Making Good Teams Great d'Esther Derby et Diana Larsen.
5.) L'équipe a-t-elle respecté les critères d'acceptation ? Tu devras peut-être revoir les critères d'acceptation des Product Backlog Items de ce Sprint pendant le Sprint.
6.) Le Sprint Backlog reflète-t-il vraiment ce sur quoi l'équipe travaille actuellement ? Les interruptions et distractions qui ne contribuent pas à l'atteinte de l'objectif du Sprint sont des obstacles.
7.) Les estimations des tâches et le taskboard sont-ils à jour ?
8.) Les artefacts pour l'autogestion de l'équipe (taskboard, Sprint Burndown Chart, etc.) sont-ils bien visibles, pratiques et utiles pour toute l'équipe ?
9.) Ces artefacts sont-ils suffisamment protégés contre le micromanagement ?
10.) Les membres de l'équipe se portent-ils volontaires pour certaines tâches ?
11.) Des items pour rembourser la dette technique ont-ils été ajoutés au backlog (pour résoudre les problèmes qui nuisent à la vélocité) ou au moins discutés avec le Product Owner ?
12.) Les membres de l'équipe laissent-ils leurs titres de poste en dehors de la salle d'équipe ?
13.) L'équipe entière se sent-elle responsable des tests, de la documentation utilisateur, etc. ?
Liste de contrôle pour le développement du produit
1.) Votre système dispose-t-il d'un bouton « push-to-test » en développement, permettant à n'importe qui (dans la même équipe ou une autre) de découvrir facilement s'il a cassé quelque chose ? Cela se fait généralement avec le framework xUnit (JUnit, NUnit, etc.).
2.) Avez-vous un équilibre approprié entre les tests système automatisés de bout en bout (tests fonctionnels) et les tests unitaires automatisés ?
3.) L'équipe écrit-elle à la fois les « tests fonctionnels » et les tests unitaires dans le langage du système qu'elle développe (plutôt que des langages de script propriétaires ou des outils de capture et relecture que seule une petite partie de l'équipe sait utiliser) ? C'est tout à fait possible !
4.) Votre équipe a-t-elle découvert la zone grise extrêmement utile entre les tests système et les tests unitaires ?
5.) Un serveur d'intégration continue déclenche-t-il automatiquement une alerte en moins d'une heure (ou quelques minutes) lorsque quelqu'un provoque une régression ?
6.) Tous les tests sont-ils agrégés dans les résultats du serveur d'intégration continue ?
7.) Les membres de l'équipe ont-ils découvert les avantages du design évolutif (Continuous Design) et du « refactoring sans pitié » comme alternative au Big Design Upfront (BDUF) ? Le refactoring a une définition précise : modifier la structure interne d'un système sans changer son comportement observable de l'extérieur. En cas de code redondant, de logique complexe, de mauvaises conventions de nommage, de couplage excessif entre objets, etc., le refactoring devrait être effectué plusieurs fois par heure. Une couverture de tests automatisés constitue un excellent filet de sécurité pour le refactoring. Les lacunes dans la couverture de tests et le refactoring reporté sont des maladies qu'on appelle aussi dette technique.
8.) Votre Definition of Done inclut-elle pour chaque Product Backlog Item fonctionnel une couverture de tests entièrement automatisée ainsi que du refactoring ? Il est peu probable que vous puissiez développer un produit potentiellement livrable à chaque sprint sans apprendre les méthodes d'eXtreme Programming (telles que décrites par Kent Beck, Ron Jeffries, etc.).
9.) Les membres de l'équipe travaillent-ils principalement en pair-programming ? Le pair-programming peut améliorer considérablement la maintenabilité du code et réduire le nombre de bugs. Cependant, cela peut être éprouvant et parfois sembler prendre un peu plus de temps (quand on privilégie la quantité à la qualité). Plutôt que de forcer les membres de l'équipe, montrez l'exemple et proposez de travailler en binôme certains jours de la semaine. Certains membres de l'équipe préféreront bientôt cette façon de travailler.
Checklist du Scrum Master pour le développement organisationnel
1.) Existe-t-il une coordination suffisante entre les différentes équipes ? Un Scrum of Scrums est la seule façon d'y parvenir. De plus, tu peux envoyer des représentants de ton équipe aux Daily Standup-Meetings d'autres équipes.
2.) La coordination au sein de l'équipe est-elle vraiment – comme recommandé – assurée par ceux qui effectuent le travail au quotidien ?
3.) Les différents Scrum Masters se réunissent-ils pour travailler sur la liste des obstacles organisationnels ?
4.) Les obstacles sont-ils communiqués au responsable du développement lorsque c'est approprié ? Le coût peut-il être mesuré en termes monétaires ou en temps de mise sur le marché perdu, en qualité perdue ou en opportunités perdues pour le client ?
5.) Ton organisation fait-elle partie des rares dont les possibilités de carrière sont compatibles avec les objectifs collectifs des équipes ? Ce n'est pas le cas s'il existe des incitations qui poussent à programmer ou à travailler sur l'architecture au détriment des tests, de l'automatisation des tests ou de la documentation utilisateur.
6.) Contribues-tu à créer une organisation apprenante ?
7.) Ton organisation est-elle reconnue dans la presse spécialisée ou par d'autres sources indépendantes comme un lieu de travail attractif ou un leader du marché ?
La peur est ton amie
Dès que tu réalises tout ce que tu peux faire pour changer les choses, tu auras peut-être peur. Mais c'est simplement un signe que tu es sur la bonne voie.
Ce texte provient du blog de la Scrum Alliance et a été traduit par nos soins.
