Retour d’expérience : un Scrum Master passionné par son métier

J’ai la chance aujourd’hui de pouvoir discuter avec Jean-Pierre Lambert qui a bien voulu nous faire un retour d’expérience de son rôle de Scrum Master chez France Télévision en tant que consultant Wemanity. J’ai voulu faire cette interview pour vous faire profiter de la passion qu’il a pour son poste ; il pourrait bien vous donner envie de devenir Scrum Master.

Article : Le rôle de Scrum Master

Bonjour Jean-Pierre, je te propose de te présenter pour qu’on en sache un peu plus sur toi.

Bonjour, je suis avant tout un ingénieur. C’est ainsi que j’ai démarré ma carrière, en tant qu’ingénieur logiciel, `l’air de rien plus de dix ans à ne faire que ça ! Et cela reste ancré dans mes manières de penser et dans mon attitude.

Aujourd’hui, je me positionne comme coach technique. J’aide les équipes à mettre en place une stratégie de test automatisée, efficace, utile et maintenable. À un moment, ma punchline sur LinkedIn était “Agile Test Evangelist”. C’était un peu pompeux, mais c’est l’idée : aider les équipes à avoir une pratique des tests en environnements Agile. Les tests, ça fait partie des gros sujets super importants sur lesquels tout le monde se casse le nez pour bien le faire en Agile, et où les coach Agile et autres boîtes de consulting sont souvent de peu d’aide. Après, tout est question de profil de coach Agile, hein ! 🙂

Et à côté de ça, donc, je fais aussi Scrum Master. Suite à la réorganisation de l’équipe que j’occupais, qui grandissait en taille, France Télévisions m’a proposé cette opportunité. J’ai accepté, car j’affectionne tout particulièrement ce rôle. Mais bon, ça commence à faire pas mal de boulot !

Qu’est-ce qui t’a amené à te diriger vers l’univers Agile ? Et plus spécialement en Scrum Master ?

Et bien… Le hasard ?

En sortie de ma première expérience professionnelle, 6 bonnes années dans une start-up, l’Agilité je ne connaissais pas vraiment. Pas pratiqué, le peu dont j’en avais entendu parlé faisait l’amalgame avec XP, le TDD et compagnie. En gros, on m’avait dit “l’agile il faut en faire mais juste ce qu’il faut, c’est ce qu’on essaie de faire ici” mais en parlant en fait des tests unitaires. J’ai fait un sacré bout de chemin depuis, aussi bien du côté de l’Agilité que du côté des tests unitaires ! Passons… 🙂

Deuxième expérience professionnelle, me voilà consultant en régie. Chez le client, ils pratiquaient quelque chose qu’ils appelaient “Scrum”. À ce moment-là je n’avais pas de référentiel sur le sujet, alors je ne me posais pas trop de questions. Mais on en était loin, du Scrum. En particulier, chaque développeur avançait sur ses propres tâches, pas d’équipe au sens Scrum. Ah, et aucune rétrospective.

Et puis, après un an chez ce client, ils démarrent un nouveau projet phare et me proposent d’être Scrum Master. La raison ? Mon attitude… Ils trouvent que j’anime littéralement l’open-space, quelque chose émane de moi. Ils pensent qu’en tant que Scrum Master je vais réellement aider à faire que ça fonctionne mieux. Petit détail important : on me donne le mot d’ordre “cette fois, on fait du vrai Scrum”.

S’ensuit une formation minimaliste en interne à JIRA et Confluence, c’est quoi des User Stories, à quoi sert un Product Owner. Mais surtout, beaucoup, beaucoup de lecture en solo. À commencer par le Scrum Guide, tout simplement.

Et là, c’est la révélation. Bien entendu qu’il faut mener les projets informatiques de cette manière ! Je tombe en amour avec ce rôle de Scrum Master. J’ai l’impression d’avoir trouvé ma vocation.

En tous cas, merci à eux de m’avoir donné cette fantastique opportunité !

Pour toi, peux-tu nous expliquer à quoi ressemblent tes journées de Scrum Master ?

Si mes journées de Scrum Master vous intéressent, figurez-vous que j’ai rédigé un article où je parcours tout cela dans le détail ! Ca se passe ici : https://jp-lambert.me/dis-cest-quoi-un-scrum-master-1246c25c78da

En gros, je compense le fait que l’organisation ne soit pas Agile.

Alistair Cockburn a donné cette définition de l’Agilité :

“Agile is early delivery of business value and less bureaucracy.”

Ainsi j’évolue dans une organisation qui a un certain niveau de bureaucratie. L’achat de fournitures, par exemple, est trop compliqué pour que cela se fasse naturellement et sans délai par l’équipe.

Je fais aussi en sorte de mettre de l’huile dans les rouages de l’équipe. Par exemple en facilitant les réunions afin qu’elles soient productives et efficaces.

Mais aussi, ce qui peut sembler contre-intuitif, en protégeant l’équipe d’elle-même. En rappelant à tout moment à l’équipe l’objectif de l’itération, en les forçant à respecter les règles de fonctionnement qui ont été fixées. Règles fixées par l’équipe elle-même !

L’Agilité requiert une extrême rigueur. On a rarement envie d’admettre qu’on n’est pas assez rigoureux, mais c’est un fait : c’est difficile. Très difficile. Et à moins d’avoir une petite équipe avec des membres très matures, le Scrum Master sera d’une grande aide pour atteindre, pratiquer et entretenir cette rigueur.

En fait, on pourrait résumer mes journées à ceci : je fais en sorte de construire un environnement dans lequel je serais heureux d’être moi-même développeur. Ce qui est un peu paradoxal, mais très motivant. Par exemple, sur le sujet d’essayer de limiter les interruptions de l’équipe : mon focus ne vas pas être sur comment améliorer la productivité de l’équipe, mais sur comment limiter la frustration de l’équipe.

Parce que soyons clair, quand on est développeur, c’est relou les interruptions. Tout comme c’est gonflant de ne pas être aussi productif qu’on voudrait. Il n’y a rien de pire, en fin de journée, de se rendre compte qu’on n’a pas atteint les objectifs qu’on s’était donné le matin. Quand cela devient la routine… Quand on précise systématiquement “pour une fois” quand on se dit “waouh, aujourd’hui j’ai pu faire ce que je voulais faire”… Alors la démission n’est souvent pas très loin.

Car un dev, ça bosse quand même beaucoup à la passion. Voire uniquement. Ceux dont ce n’est pas le cas, ils bifurquent sur autre chose, comme Chef de Projet par exemple. Donc avoir un environnement qui minimise les interruptions pour l’équipe de développement, c’est crucial. Et cet environnement, le Scrum Master devra le créer artificiellement si l’organisation n’a pas cette culture.

As-tu des exemples d’amélioration que tu as pu mettre en place avec cette équipe pour justement limiter ces interruptions ?

Un des exemples les plus parlant, c’est ce qu’on a appelé Le Forum Hors du Guidon.

L’idée, elle est simple, plutôt que d’avoir plein de petites réunions de-ci de-là durant l’itération pour préparer les itérations à venir (refinements mais aussi parfois des POC, des investigations techniques…), nous dédions une journée par itération à tous ces sujets. Une journée entière par itération peut sembler beaucoup, mais dans notre cas cela représente moins que le temps cumulé des réunions et des tâches informelles que cela remplace. Et en plus c’est timeboxé à pas plus d’une journée par itération ! En soi, il n’est pas anormal qu’une équipe puisse consacrer 20% de son temps à préparer l’itération suivante, du coup avec cette journée on est plutôt pas mal : nos itérations faisant deux semaines cette journée n’équivaut qu’à 10% !

Si vous voulez plus d’informations, j’ai détaillé ce rituel de l’équipe sur mon blog : https://jp-lambert.me/l%C3%A9quipe-ne-trouve-pas-le-temps-de-pr%C3%A9parer-les-sujets-%C3%A0-venir-1e31614863eb

Nous avons depuis effectué la deuxième occurrence du Forum Hors du Guidon et c’est toujours un succès. Par contre plus d’axes d’amélioration ont été identifiés pour la prochaine fois ; la troisième édition risque d’être un peu différente dans son organisation, cela méritera un nouvel article de blog ! 🙂

Un autre exemple de ce que j’ai mis en place pour limiter les interruptions, c’est le DEFCON de l’équipe. Directement inspiré du DEFCON de l’armée américaine, le but est d’indiquer le niveau de réaction aux urgences que doit avoir l’équipe. Très concrètement, cela définit quelles sont les libertés que l’on peut se donner vis-à-vis de « Scrum by the book » et notamment via les interruptions.

L’idée est de se forcer à minimiser les interruptions de l’équipe lorsque la situation n’exige pas une réponse immédiate, et à l’inverse de matérialiser les situations qui justifient de telles interruptions en l’affichant clairement. Et bien sûr, c’est fun 🙂

Dernier exemple, une affichette que nous avons placardé à plusieurs endroits stratégiques de l’open space, qui rappelle et explique que pour toute requête, il faut aller voir le PO ou le SM – et non pas l’équipe. Cela s’accompagne également d’un rappel de toutes les informations dont nous avons besoin lorsqu’on nous soumet un problème… Mais ceci est une autre histoire !

Je te remercie sincèrement du temps que tu as pu nous consacrer et de ce retour d’expérience complet. Je ne doute pas que tu viens de donner envie à de nombreuses personnes de devenir Scrum Master, car on sent cette passion que tu as en toi.