Scrum Master Academy – De l’efficacité des cérémonies Scrum

Suite de ma série de billets sur les règles de la Scrum Master Academy. Tout d’abord, j’ai une bonne nouvelle pour tous les amateurs de notre Academy et pour Christophe en particulier. Christophe m’avait fait une demande ouverte sur un article de son blog : nous allons créer prochainement la Xebia Academy qui déclinera une formation pour les Scrum Masters, les Product Owner, et également pour les coach agiles. L’ambition de Xebia pour les années à venir est de former des agilistes d’élites pour monter le niveau de notre domaine d’ingénierie. Je ne vous en dit pas plus pour l’instant, ne souhaitant pas dévoiler les coulisses de ce chantier ambitieux, mais sachez qu’il est déjà démarré et que ces nouvelles formations font partie de notre catalogue pour 2013.

Aujourd’hui je vais revenir aux bases de l’activité de Scrum Master. Vous avez adopté Scrum depuis quelques temps et cela a donné de bons résultats, mais progressivement les pratiques se sont diluées, le momentum du début est retombé, vos postits sont moches (si si, avouez le, et de toutes façon vous n’en avez plus), et votre tableau d’impediments n’est plus à jour depuis longtemps. Votre priorité n’est plus de faire du logiciel en Scrum mais de faire du logiciel tout court. Comme le disent souvent les rugbymen « no scrum no win » et pourtant vous êtes bien meilleurs que des rugbymen avec un clavier dans les mains. Alors que se passe-t-il ? C’est le moment de revenir aux fondamentaux (à prononcer avec l’accent du sud ouest).

Règle n°30 : Démos sans slides

La première dérive observée des cérémonies Scrum est souvent d’utiliser des présentations slides pendant la revue de sprint, dite démo. L’objectif de la démonstration est bien de montrer du logiciel opérationnel alors bannissez les slides et préparez des scenarii d’utilisation réels avec les données adéquates. N’hésitez pas à vous inspirer des techniques de « storytelling » pour mettre en scène votre incrément de code. Souvenez-vous qu’une belle démo, fluide et bien organisée, laissera une impression positive et un sentiment de sérieux qui vous servira dans les coups durs.

Règle n°31 : La démo commence à l’heure et avec tout le matériel adéquat  

Nous sous-estimons régulièrement les détails logistiques pour organiser la démonstration de fin de sprint. Une heure avant le début de la réunion, assurez-vous personnellement que tout est en place. Si vous prenez une salle de réunion, réservez-la 15 min avant l’heure et prévenez les éventuels occupants qui vous précèdent de libérer les lieux à l’heure dite. Envoyez un rappel de réunion aux participants, en leur indiquant que la démonstration commencera à l’heure. Rassemblez l’équipe 15 min avant la démo pour faire le point sur les rôles de chacun et revoir rapidement le contenu de la réunion. Branchez le matériel nécessaire et lancez les environnements. N’oubliez pas que, malgré l’effet de mode, l’agilité et Scrum ont encore mauvaise presse et sont souvent associés au vite-fait-mal-fait, tous les détails comptent pour laisser à vos interlocuteurs une impression de maîtrise et de sérénité.

Règle n°34 : Tu connais et tu lis les stories avant le sprint planning

Le sprint planning est une réunion clé qui nécessite également de la préparation. En tant que Scrum Master, vous avez un rôle d’accompagnement du Product Owner sur ses activités liées à Scrum. Bien connaître les stories en arrivant à cette réunion en permettra une animation efficace, même si le Scrum Master n’est pas le détenteur du savoir fonctionnel et technique. Vous pourrez rebondir lors des échanges, relancer les participants, et leur rappeler les décisions prises. Cela vous permettra aussi de vous assurez que les stories sont dans un état prêt pour être développées dans un sprint.

Règle n°15 : En rétrospective, varier les formats  

Parce qu’un format unique et systématique peut limiter la façon d’aborder les problèmes, varier de temps en temps les formats permettra de changer de perspective et renouvellera l’énergie de cette réunion. Éviter quand même de jouer avec tous les formats possibles et imaginables, vous n’êtes pas en train de faire une collection de timbres ou un tableaux de chasse. Ce n’est pas la variété et le nombre qui importent mais l’efficacité. Restez simple et n’essayez pas de résoudre la faim dans le monde.

Règle n°36 : Favorise les TIG pour gérer les retard en daily Scrum

Certains Scrum Master donnent des gages lorsqu’un membre de l’équipe enfreint une règle de comportement. Ces formes de gages sont le plus souvent utilisées pour gérer les retards au Daily Scrum. Je ne vois pas d’inconvénient majeur à cette pratique, en revanche il faut rester cohérent. Par exemple, si vous imposez de donner 1 euro par retard, n’utilisez pas cette cagnotte pour aller boire un verre avec l’équipe, cela n’est pas vraiment dissuasif pour les retards. Préférez le versement de la cagnotte à votre manager, cela aura tout de suite un effet plus marqué. En ce qui me concerne je préfère distribuer des travaux d’intérêt généraux (TIG) pour gérer les retards : s’occuper du build, écrire les comptes-rendus de réunions, s’occuper des commandes de post-its, ranger le bureau, ou vérifier la mise à jour de l’affichage visuel. Cela permet de délester un peu le Scrum Master de ces basses besognes néanmoins nécessaires et de sensibiliser tout le monde à leur intérêt.

Prochainement

• Règle n°14 : Ne te laisse pas enterrer sous les problèmes
• Règle n°20 : Il n’y a pas de « Eux », il y a « Nous »
• Règle n°22 : Connais tes ennemies
• Règle n°26 : Ne rien considérer comme allant de soi
• Règle n°27 : Il vaut mieux rechercher le pardon que demander la permission
• Règle n°28 : Ne croyez jamais ce qu’on vous dit, toujours vérifier
• Règle n°35 : Un Scrum Master sur le carreau est inutile