Ce billet va clore la série des règles "standards" qui constituent le corps de nos règles du Scrum Master. Vous allez trouver ici des règles qui peuvent être difficiles à mettre en oeuvre et qui nécessitent quelques trophées sur le tableau de chasse de votre expérience.
Règle n°9: Tu n’estimeras pas en jour/homme
Utilisez les story points ou tout autre échelle relative pour vos estimations sur les éléments du Product Backlog. Evitez autant que faire se peut l’utilisation des jours-hommes pour les estimations, ils sont trop rapidement mal interprétés et amènent à des erreurs souvent bien plus importantes. Au delà des stories, évitez le chiffrage des tâches en heure, ce travail n’apporte que peu de valeur et dérape trop souvent dans la durée.
Règle n°11: Ne deviens pas un garagiste
La gestion de la dette technique doit se faire en accord avec le Product Owner en évitant les opérations obscures et "indispensables au risque de provoquer une catastrophe nucléaire". Personne n’apprécie de ne pas comprendre où passe son argent. Scrum nous vient des US, même si ses racines sont japonaises. J’ai donné cette année quelques cours certifiants avec un CST américain et j’ai été frappé de voir l’angle très financier qu’il donnait à sa formation. Pour les stagiaires peu habitués à manier les chiffres, certaines questions ou exercices étaient tout à fait déroutants: "combien coûte une équipe de 6 ETP sur un an ?" personne n’était capable de répondre, moi y compris (enfin le premier cours, le deuxième j’avais la réponse) . Et pourtant Scrum, ce n’est que de l’argent: Le PO investit dans un sprint et obtient une valeur tangible à la fin du sprint. Si vous voulez être un bon Scrum Master vous devez maîtriser les aspects financiers pour vendre les plans d’action sur la dette technique ou sur des opérations de maintenance à votre PO.
Règle n°13: Reste à la page
Une formation Scrum Master ne saurait donner toutes les informations pour réussir dans votre rôle. Lisez des livres, des blogs (celui de Xebia est un très bon choix 
), regardez des videos, venez participez aux conférences agiles, échangez avec vos pairs, créez des groupes d’intérêt dans votre organisation. En résumé, ne vous contentez pas du contenu du cours et de votre expérience.
Règle n°23: Ecoute et tais toi
Quand on vous expose un problème, ne sautez pas trop vite aux conclusions et prenez le temps d’écouter jusqu’au bout votre interlocuteur. Laissez un temps de silence lorsqu’il a fini et reformulez ses propos. Il est peut être en train de vous donner la solution. Cette règle s’applique bien sûr en rétrospective, mais également en toute occasion: rencontre en tête à tête avec les membres de l’équipe,
Règle n°33: Tu déploies tous les jours en environnement de tests
La seule mesure d’avancement en agile est le logiciel opérationnel. Avoir la discipline de livrer régulièrement en Test vous poussera à renforcer vos pratiques de tests et lever les problèmes au plus tôt. Livrer régulièrement en Production vous fera mettre la barre encore plus haut en termes de qualité et vous obligera à considérer tous les aspects insoupçonnés de votre produit (déploiement, migration, configuration, sécurité, performance).
Prochainement: les règles de crise
Règle n°17 : Transparence et pas indécence
Règle n°40 : Les points de story sont une fourchette de jours/hommes et un % de certitude
Règle n°41 : Gère les pollueurs en démo
Règle n°42 : Range ton désordre
Règle n°43 : Pas de sprint entier de refactoring
Règle n°44 : Si vous êtes en Scrum distribué, tout le monde sur le même site
Règle n°45 : A la rétrospective, 2 actions d’amélioration maximum