Publié par

Il y a 7 ans -

Temps de lecture 3 minutes

Scrum Master Academy – Allez plus loin

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

 

Publié par

Publié par Gilles Mantel

J'ai 13 ans d’expérience professionelle. Je suis impliqué sur des projets itératifs et offshore depuis 2001 et j'y ai occupé tour à tour les postes d'ingénieur qualité, responsable des tests, analyste fonctionnel, et directeur de projet. Je forme et j'accompagne les clients de Xebia dans l’adoption de méthodes agiles (SCRUM, XP) et de pratiques d’ingénierie pilotées par les tests (TDR, ATDD). J'ai développé mon expertise au travers d’interventions dans des domaines métiers aussi variés que l’industrie, l’e-commerce, l’édition logiciel, le luxe, le public, les télécoms, ou les banques d’investissement. J'intervient régulièrement dans les conférences traitant de l'agilité et des tests depuis 2008.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.