Un des rôles principaux du ScrumMaster est de faire en sorte qu'en fin d'itération, ce qui va être démontré est terminé; vraiment terminé. « Done is Done ». On parle d’incrément potentiellement livrable au client ; il est donc hors de question de livrer quelque chose qui ne soit pas terminé car c’est tromper le Product Owner qui naturellement pense que ce qu’il voit est acquis. Il ne comprendra pas qu’il faille retravailler sur une fonctionnalité. De plus, le burndown, qui est son seul outil de planification, ne serait que peu pertinent et c’est toute la méthode qui tombe à l’eau car la visibilité est faussée! C’est comme évaluer une distance avec un oeil caché!
Quand tout va bien, être ScrumMaster, ce n’est pas difficile … mais tout n’est pas toujours tout rose.
C’est en exerçant une pression sur la vélocité ou suite à une prise de retard qu’un processus inconscient, quasi câblé dans nos gènes, de prise de raccourcis dans la qualité apparaît. (cf Ken Schwaber : http://www.youtube.com/watch?v=IyNPeTn8fpo). Ken Schwaber, après une étude, parle de seulement 120 personnes sur 5000 qui ne voudraient pas réduire la qualité pour atteindre l’objectif dans le temps prévu! Autant dire que vous et moi en faisons probablement partie!
Le ScumMaster doit s'appuyer sur la définition de « terminé » car il n'a pas d'autorité. Les qualités et outils de communication sont donc nécessaires pour, sous forme de questionnement, faire comprendre à l’équipe les bais qui font que telle ou telle fonctionnalité n’est pas terminée. Il est vital de rester factuel et il faut garder en tête que même les équipes les mieux intentionnées comme le dit si bien la «Prime Directive» ont ce réflexe très difficilement contrôlable de diminution de la qualité quand le temps vient à manquer. Un peu moins de tests par ici, un petit refactoring nécessaire non fait ou un bug par là, … et terminé n’est plus terminé !
Les discussions sont parfois difficiles car le ScrumMaster peut être en opposition avec l’équipe qui à beaucoup travaillé pour arriver à un bon résultat … mais pas toujours terminé ! Les explications et les exemples sont de rigueur pour faire accepter ce qui est difficile à accepter car c’est l’amour propre qui peut être touché. En effet, très vite, certaines personnes peuvent se sentir jugées or c'est bien le logiciel qu'on évalue et la responsabilité de fournir des fonctionnalités terminées appartient à toute l'équipe, ScrumMaster y compris. Donc tout le monde porte les succès et les échecs. Par chance, les échecs peuvent-être analysés grâce à la retrospective afin de continuellement progresser.
Le but est que l’équipe auto évalue objectivement le travail accompli car si c’est elle qui prend la décision de ne pas montrer une fonctionnalité alors un grand pas a été franchi et tout devient plus simple en terme de communication à tous les niveaux. Plus besoin de justifier l'injustifiable à qui que ce soit car c'est la méthodologie SCRUM qui est respectée! Une première étape au terminé, c’est d’avoir confiance en le logiciel alors pour évaluer ce sentiment subjectif, nous pouvons utiliser l’analogie de la voiture : Est-ce que tout le monde monte dans la voiture si notre logiciel concerne le régulateur de vitesse? Cette question est particulièrement utile lorsque qu’un bug non compris, non reproduit reste dans une version. Si la réponse est non, alors CQFD et si c’est oui alors il faut réexpliquer ce que le vrai terminé veut dire et quelles peuvent être les conséquences pour le client.
Du coup, le ScrumMaster n'est pas toujours très aimé et encore moins si sa communication n'est pas parfaite! Pas très aimé de l’équipe car il n'est pas toujours très plaisant ("The prick" : cf Ken Schwaber) en remettant en question ce que l'équipe estime terminé et tiraillé par le ProductOwner pour que le projet avance plus vite. Les ScrumMasters peuvent devenir les personnes les plus détestées de l’entreprise ; c’est parfois inévitable car si ils font bien leur boulot ils sont intransigeant sur le terminé ; d’ailleurs Ken Schwaber rappel aussi que le gens de la QA sont les personnes idéales pour faire ce boulot car eux savent ce qu’est un vrai terminé!
En fin de compte, ce sont les émotions qui nous trompent, nous font nous raconter des histoires à partir des faits eux bien réels. Elles sont l’essence de l’accomplissement mais aussi le centre de bien des discussions peu constructives et hors sujet. Alors rester factuel est indispensable ainsi que de juger un résultat plutôt qu’une quantité de travaille !
Pour conclure, la manière d'arriver au meilleur résultat est de s'entendre sur la notion de terminé avec l'Equipe et les représentants de la QA et de ne jamais y déroger. La tentation est souvent forte de contourner certains points mais très très rarement pour de bonnes raisons. Alors dans un tel cas, le SCRUM master doit s’accrocher pour obtenir une justification valable. Les contournements sont des dettes que l’équipe accumule et que l’on fini par payer en perte de confiance avec le ProductOwner et le client.
Tout est dans "Done is Done".
2 commentaires:
Voici un truc que nous appliquons: le scrummaster est aussi et avant tout un membre de l'équipe.
Il teste, code, intègre et fait TOUT comme TOUT le monde. L'activité de ScrumMaster ne prend pas plus que 10 à 15% du temps pour une équipe de 10 de développeurs. Au delà, il vaut mieux découper l'équipe en 2 de toute façon.
Le fait d'être un équipier comme tous lui donne davantage de légitimité. Il impose un niveau de qualité par l'exemple. Il n'impose rien qu'il n'applique déjà lui-même.
Pour diffuser cet exemple, il fait comme un coach XP: il binôme (comme tout le monde, encore une fois).
Comme cela, il passe du "prick" de Scrum au "guide" de XP. Il ne propose pas ce que d'autres peuvent faire, il démontre par son propre exemple.
Merci Emmanuel pour ton retour.
Être "prick" n'est de toute façon pas très satisfaisant alors mieux privilégier d'autres canaux de communication pour éclairer les points nécessaires et conduire l'équipe à prendre les bonnes décisions ... dans la bonne humeur !
Je suis convaincu que montrer les bonnes pratiques en étant dans l'équipe est très efficace ; je m'en suis rendu compte, en tant que développeur cette fois-ci, avec par exemple le pair-programming qui semble acquis aujourd'hui.
Ce qui me semble plus difficile, c'est de mêler les rôles de ScrumMaster et coach Agile. Le recul du ScrumMaster qui ne développe pas sur le même projet peut être intéressant (c'est l'équipe elle-même qui le dit). Il faut aussi tenir compte qu'il y a de très bon ScrumMaster facilitateur "non développeur" (QA - Représentant utilisateur).
Au bout du compte, je pense que les rôles de ScrumMaster et de coach Agile sont capitaux mais pas nécessairement joués par la même personne. Le coach Agile peut montrer par l'exemple les bonnes pratiques XP et le ScrumMaster peut/doit poser les bonnes questions afin que l'équipe puisse prendre les meilleurs décisions d'elle même sans être "the prick".
Luc
Enregistrer un commentaire