Lorsque vous regardez votre équipe, pensez-vous qu'elle progresse? Est-ce que vous sentez que vous vous dirigez vers une haute performance de livraison dans votre projet? Il y a peut-être quelqu’un qui joue le rôle de Scrum Master, ou vous n’en avez pas encore dans l’équipe. Je vous partage, par mon expérience, des éléments clés à avoir chez un bon Scrum Master.
Le développement logiciel est complexe, ce n’est pas une surprise pour personne (du moins, je l’espère!). Par contre, le processus du développement logiciel est beaucoup plus compliqué que de simplement suivre les quatre événements Scrum à la lettre.
Il y a plusieurs variables qui améliorent la performance de livraison de logiciels. Les meilleures équipes livrent 106 x plus vite que les équipes les moins performantes, ont un taux d’échec 7 x plus bas, et lorsqu’il y a un échec, elles sont 2 604 x plus rapides à rétablir la situation.
Instaurer les capacités qui améliorent la performance n’est pas chose facile, et cela demande une compréhension poussée du DevOps et du Lean (minimiser les pertes). Ici, on est loin de l’image clichée du Scrum Master qui fait seulement mettre des post-its sur un mur pendant une rétrospective!
La culture de votre organisation a un impact direct sur les performances de vos équipes. Je sais que je pointe l’évidence, mais c’est important. Ce n’est pas tout le monde dans l’équipe qui a la même expérience ou le même niveau de souci du détail. Des conflits arrivent souvent entre des développeurs puisque certains ont la qualité plus à cœur alors que d’autres ont «le pouce facile» sur les merge requests. Un autre exemple est de dénoncer le Product Owner quand «les tâches ne sont pas assez claires».
La personne qui joue le rôle de Scrum Master doit exceller dans l’art de créer un climat de confiance et de transparence, que l’on appelle la sécurité psychologique. C’est ce facteur qui va booster l’amélioration en continu dans votre équipe, et donc qui mène à une meilleure performance de livraison.
Ce choix n’est pas complètement fou à première vue. Plutôt que d’engager quelqu’un, on va prendre une personne de l’équipe. Je l’ai essayé, je suis coupable! Aujourd’hui, je ne le recommande plus. Peut-être temporairement, mais c’est un pansement sur une plaie ouverte. Quand on prend un développeur de l’équipe, généralement cela se traduit par quelqu’un qui va seulement animer les rencontres. Et ensuite, c’est fini!
Après les cérémonies, il va retourner travailler sur ses tâches. Sa charge mentale n’est pas réellement d’améliorer la performance de l’équipe, mais plutôt d’effectuer son vrai rôle, soit de développer le produit. Ses réflexions le soir sont plutôt orientées sur comment régler son bogue, et non comprendre la cause racine des bottlenecks qui nuit à la performance de l’équipe.
Et j’ajouterais même que, souvent, ce développeur est la cause même de plusieurs goulots d'étranglement dans l’équipe, car il est généralement impliqué dans plusieurs rôles et rencontres d’entreprises et il est «trop occupé».
De plus, le développeur est nécessairement biaisé dans son jugement et sa compréhension de la situation. Le Scrum Master est au service de l’équipe de développement et du Product Owner. Le développeur, quant à lui, n’est pas nécessairement au centre de toutes les discussions et il aura plusieurs angles morts. Le développeur ne voudra pas être au centre de ces discussions, car son vrai travail est de développer un produit de qualité, pas de coacher le Product Owner.
Choisir une nouvelle personne à chaque cérémonie qui «joue le rôle» de Scrum Master est souvent un syndrome du point précédent. C’est un scénario que je recommande encore moins. Pour que l’équipe atteigne une haute performance de livraison, le Scrum Master doit servir et influencer son équipe vers de meilleures pratiques.
Pour réussir à influencer les gens vers de nouveaux comportements, ça passe par avoir gagné la confiance de ses pairs. Bâtir une relation demande du temps. Ça passe par des one-on-one, des célébrations, des appels, des conversations difficiles, des déjeuners, etc.
Ultimement, le Scrum Master a un plan de match pour amener l’équipe à adopter un meilleur processus de travail. Parfois, ce sont les gens de l’externe qui nuisent à la performance de l’équipe, par exemple en les interrompant ou avec des meetings. Alors dans ce cas, si le rôle de Scrum Master change de mains régulièrement, qui aura véritablement l’incitatif de le résoudre?
Au final, il est quand même difficile de trouver un bon Scrum Master. Les gens qui cochent toutes les cases sont plutôt rares ou dispendieux. Cela reste que l’investissement est primordial pour atteindre une haute performance de livraison logicielle. Il faut juste rester conscient des impacts de la décision que l’on prend!
N’hésitez pas à me contacter au awalsh@nexapp.ca si vous avez des questions, ou laissez des commentaires! Je vous serais aussi très reconnaissant si vous partagiez cet article!
Au plaisir de vous voir dans la communauté!