Dans un précédent billet je vous présentais quelques règles pour gagner des points de charisme. Sachant qu’il est difficile à évaluer le résultat n’est pas garanti. Je vais vous parler ici de ma vision de l’attitude du Scrum Master, et c’est beaucoup plus facile à mettre en oeuvre. Quoique …
Règle n°12 : On travaille toujours en équipe
L’équipe est l’élément de base de la réussite d’un projet agile. Assurez-vous que les décisions sont partagées et que personne ne part en franc tireur pour "aller plus vite". Cette unité d’équipe est difficile à maintenir au cours du temps. Les plus cultivés d’entre vous doivent connaître le modèle de Tuckman qui décrit les différents états par lesquels passe une équipe: forming, norming, storming, performing. L’idée n’est pas ici de vous distiller la théorie, mais de vous donner des éléments concrets.
Il existe de nombreuses façons de créer un esprit d’équipe. Je commence généralement mes interventions d’accompagnement en allant boire un verre avec toute l’équipe (donc y compris le PO) à la fin du premier sprint, c’est bête mais ça forme des liens. On discute dans un environnement différent et les informations ne sont pas les mêmes, on parle de nos enfants, de nos expériences similaires, on développe une sympathie pour l’autre qui sera un atout non négligeable dans les coups durs. Avant même ce verre, j’organise un déjeuner commun si les membres de l’équipe n’ont pas l’habitude de se retrouver pour manger. Ce n’est pas tout, je constate souvent qu’une équipe qui démarre avec Scrum passe par un état d’euphorie lors de son premier sprint. Je vois souvent des post-its fleurir à la première rétrospective expliquant combien il est agréable de travailler avec cette équipe.
Il y a quelques années, je disais "Bravo" et nous passions ensuite aux problèmes pour essayer de trouver des points d’action. Je constate avec l’expérience que cette belle euphorie est fragile et qu’elle a tendance à voler en éclat avec les premières difficultés (c’est à dire le sprint 2).
Aujourd’hui je passe un peu de temps à la première rétrospective pour creuser les raisons de cette euphorie: pourquoi avez-vous apprécié de travailler avec cette équipe ? Je recueille généralement quelques regards vides ou des réponses triviales du type "Ben, parce que c’est bien". Il faut généralement prendre quelques exemples concrets pour commencer à avoir des éléments intéressants: à quel moment as-tu le plus senti cette osmose ? Pourquoi ? On commence alors à identifier les raisons: "On n’a pas hésité à s’aider", "On a dépassé le cadre de notre rôle", "Il n’y avait pas de responsabilités individuelles", "Bruno a ramené les croissants", "On a mangé ensemble", "Je n’ai pas eu peur de demander de l’aide", "on est au courant de ce que font les autres", "Estelle a passé du temps à m’expliquer le schéma de la base" etc, etc. Je note soigneusement ces éléments sur des post-its que j’affiche ostensiblement dans le bureau, ce sera la "Charte d’Equipe" pour les sprints à venir.
Règle n°19 : No broken window
La théorie de la fenêtre cassée est issue d’expérimentations sociales datant du milieu du XXè siècle.
Ce principe fût utilisé par le Maire de New York dans les années 90 pour améliorer les conditions de sécurité dans les quartiers difficiles. Bien que les conclusions de ces expérimentations soient parfois remise en cause, l’application de ce principe possède des vertus indiscutables. Parce qu’un écart toléré, ou un bug non corrigé entérine le comportement, assurez-vous de toujours recadrer les pratiques ou corriger immédiatement les anomalies qui trainent.
Règle n°21: Evalue régulièrement où l’équipe en est de sa maîtrise de l’agile
Ce n’est pas parce qu’on applique Scrum que l’on a fini sa progression vers l’agilité. L’agilité est un chemin plus qu’un but, alors regardez le chemin parcouru et évaluez régulièrement celui qui reste à parcourir. Il existe de nombreux modèles d’évaluation de sa maturité agile qui vous permettront de vous situer sur ce chemin.
Le plus simple est le site abetterteam.org qui propose un questionnaire appelant des réponses binaires et qui propose à l’issue de la saisie un niveau de sécurité rouge, orange, ou vert. Vous allez voir qu’il est difficile d’obtenir le niveau vert. Le formulaire est basé sur les écrits de James Shore très orienté XP. Vous avez aussi une checklist plus orienté Scrum mise au point par Henrik Kniberg et utilisée par Jeff Sutherland lui-même, ou encore un questionnaire d’enquête mis au point par Dean Leffingwell. L’idée ici n’est pas d’utiliser un seul support mais de les varier pour avoir différents points de vue. Il n’y a pas une seule agilité, mais toutes les agilités peuvent vous apprendre des choses.
Règle n°24 : Veille à la pluralité des compétences de l’équipe
Pour assurer un travail en autonomie et livrer un incrément opérationnel du produit final, l’équipe Scrum doit-être pluridisciplinaire. Le Scrum Master doit veiller à évaluer régulièrement que les compétences de l’équipe couvrent les compétences requises pour livrer du logiciel opérationnel en fin de sprint. Dans le cas contraire, ajoutez un obstacle à votre liste et agissez dessus.
Règle n°25 : Toujours avoir des post-its sur soi
Outil emblématique de l’agilité, il n’est pas seulement un attribut folklorique du Scrum Master mais sert en toute occasion (planning, réunion de travail, retrospective, …). Ils existent en de nombreuses formes et couleurs pour diversifier votre utilisation, éviter de vous cantonner aux post-its standards. J’ai découvert cette année les post-it électrostatique Stattys grâce à @elpedromajor, j’ai découvert il y a quelques années les post-its flèches grâce à @jcgrosjean. Vous pouvez même faire imprimer vos propres post-its à votre goût et selon votre gabarit. Prenez les commandes avant de vous retrouver nu !
Règle n°16 : La transparence c’est toi qui la porte
Contribuez et vérifiez que les informations visuelles, écrites, et orales permettent aux parties-prenantes de comprendre ce qu’il se passe: affichage physique, diffusion de synthèses de sprint, CR de réunion, etc. La propreté et l’organisation du tableau d’affichage est souvent laissé pour compte et l’accent est mis sur le reporting papier. Pourtant un tableau d’affichage qui ressemble à une envolée de post-its de toutes les couleurs ne donne ni une impression de sérieux, ni un sentiment de confiance. Je préfère de loin confier un projet à une équipe qui a un tableau agréable et lisible, où les post-its suivent le même format et sont correctement alignés. Pour paraphraser Jurgen Appelo dans l’un de ses articles, si votre tableau d’affichage donne l’impression qu’un tas de feuilles a fait une soirée disco, ça ne va pas vous aider à être pris au sérieux.
Prochainement :
- Règle n°9 : Tu n’estimeras pas en jour/homme
- Règle n°11 : Ne deviens pas un garagiste
- Règle n°13 : Reste à la page
- Règle n°23 : Ecoute et tais toi
- Règle n°33 : Tu déploies tous les jours en environnement de tests