TL;DR

• Technique != Code, n’oublions pas POs, Fonctionnels, Architectes, UXs/UIs
• Oui, le Scrum Master peut ne pas être techniquement à jour car il est focus team
• Il y a des outils : DOD, VM, Sonar, livres de vulgarisation
• Tu codes : tu peux juger. Tu ne codes pas : tu ne juges pas. (The-ten-commandments-of-egoless-programming)

Le Scrum Master est un facilitateur. Ce n’est pas le point central de l’équipe, le hub, le chef, le dictateur éclairé, le Dieu. Il aide son équipe dans l'objectif de délivrer de la valeur dans les meilleures conditions.

Build Things Fast !

La question ici n'est pas de savoir si le SM peut cumuler les casquettes de développeur et Scrum Master. Sujet qui mérite son propre billet.

Non, non. Je vais essayer de rester S.O.L.I.D. dans la recherche d'une réponse qui obviously, n'est pas 42. Je vais tenter de partager mon point de vue. Mais avant de donner mes pistes de solution, observons cet étrange personnage.

Disons-le franchement, peut-on être Scrum Master et être dépassé par la technique?

Voire ne pas être technique du tout...

Scrum Master, un "manager" nouvelle génération ?

Si le Scrum Master est un manager, il se doit d’appliquer une des valeurs maîtresses d'un bon manager 3.0 : Trust. Sans confiance, il est inévitable de retomber dans le besoin de Command & Control aka "Je dis, vous faites".

Pire encore : "Faites ce que je dis et pas ce que je fais", situation classique qui décrédibilise rapidement et totalement le-dit manager.

Il faut avoir cette conviction d'accompagnateur de l'équipe pour obtenir l'alignement et l'autonomie suffisante pour ne pas sombrer dans le chaos.

Une confiance réciproque qui inspire l'équipe.

J'ai également la conviction que pour tenir le rôle d’un bon Scrum Master, cette personne ne doit pas coder sur le produit. Dans le simple respect d'une des valeurs de Scrum : FOCUS (concentrer).

Il y a aujourd’hui pléthore de raisons de se distraire (mail, téléphone, Slack, réunions, machine à café, Nerf, babyfoot, feuille de temps, LinkedIn, Facebook interne, etc…). Un >= peut rapidement devenir un simple > et c’est le bug en prod. Le Scrum Master doit favoriser la concentration de l’équipe.

Imaginez-moi, Scrum Master qui :

• Encourage
• Aide à rester focus sur la tâche que l’équipe s’est engagée à réaliser lors du Daily Meeting ou Sprint Planning
• À l’affût du moindre obstacle pour le faire disparaître,
• À observer et protéger d’éventuels risques internes ou externes,
• À rechercher LA nouvelle activité à la mode pour dynamiser le groupe,
• À améliorer le Visual Management,
• À accompagner l’Architecte à formuler un mail un peu trop chargé en vitriol
• Etc, etc....

Tout ça pour dire que je risque de passer du coq à l'âne pour le bien de l’équipe...

HEY MINUTE PAPILLON !! … mais je suis en plein dans le "Faites ce que je dis pas ce que je fais !" ...

Damn... Je suis mon propre impediment …

Le Scrum Master est déjà suffisamment girouette, il est préférable pour le produit et l'équipe de ne pas pousser le bouchon.

Mais c’est un mal pour un bien. Un sacrifice nécessaire pour que la prise de recul soit efficace et apporte les meilleurs clés pour dé-cadenasser les ralentisseurs de livraison de valeur.

En tant que Scrum Master, je ne suis plus le manager qui donne des ordres ni celui qui dit quoi faire en répartissant le travail entre les membres de l’équipe.

Je dois être ce Manager 3.0 qui accompagne les gens pour les faire grandir, qui recherche la moindre chose à améliorer, qui rend son équipe la plus autonome pour prendre les bonnes décisions et accompagne au changement le reste des acteurs du projet en faisant attention à ne surtout pas faire de micro-management.

Mais ça ne va pas se coder tout seul ...

OK admettons ce que je viens de dire, le Scrum Master ne code pas...

En tout cas, pas pour le produit.

C’est donc l’équipe de développement qui est en charge de le faire.

Mais qui peut mettre en question la qualité du travail fait ? Qui fait des remarques sur l’implémentation ? Qui pousse l’utilisation d’une technologie ?

Que fais-tu de l'honorable Chef de Projet technique ??

Il faut rendre à César ce qui appartient à César, le code c'est l’équipe de développement. Cette équipe étant multidisciplinaire et d’expérience hétérogène suffisante pour le développement du produit, elle fera les choix techniques.

Bon! On dit code, mais un produit ne se résume pas qu’au code.

Il est souvent fait le raccourcis qu’avec l’Agilité c’est moins de documentation. Trois idées sur un post-it et hop! on livre.

La communication est prépondérante certes, mais la documentation reste à faire à bon escient.

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.— M. Conway

Alors, pour revenir à notre Scrum Master, la situation est que s’il est certain de ses compétences techniques ET qu’il participe activement à l'évolution du produit, alors qu’il partage son savoir et point de vue sur le sujet.

Sinon pour ne pas citer Big Lebowski :

"Shut the fuck up Donny you're out of your element !"

J'aime plus le voir comme le réflecteur du code du développeur et par bienveillance l'interroger sur l'intention de son code. En principe, le simple fait de faire le canard en plastique à côté de quelqu'un et de lui demander : "Pourquoi tu fais ça ?" permet de le faire s’interroger à haute voix et prendre conscience d'une éventuelle anomalie.

Néanmoins avant de diverger plus, ... verger plus... l'objectif ici c'est de répondre aux Scrum Master les moins (ou pas) techniques.

Pour être en mesure de challenger l’équipe à être de bons artisans du code, voici plusieurs pistes que j'utilise pour continuer à garder cette confiance de la team et le focus sur mes activités.

DOD (aka Definition Of Done)

Souvent un artefact vite oublié ou en tout cas le moins respecté dans des équipes juniors (ou pas). Le DOD. La Definition Of Done. Cette check-list que la team a construite au fil du temps pour s'assurer qu'un récit est Done à 100% et pas le :

- "J'ai terminé à 90%" .....

- "Hein ?? Mais c'est terminé ou pas ???? Tu veux un 'Ko Soto Gari' sur la moquette de l'open space ?"

Oui le DOD est un bon moyen de suivre la qualité technique. En quelques règles, il est facile de constater les bonnes normes de développement que l’équipe auto-organisée s’est imposée.

Par exemple, on peut retrouver dans la checklist des choses comme :

• Build CI/CD vert
• Mis à jour du board (Kanban, JIRA, GitLab, Obeya, Redmine, etc.)
• Indicateurs SonarQube constant ou en progression (Couverture des Tests Unitaires, Bugs, Code Smell, etc.)
• Automate de test : OK
• Revue de code par un sénior ou Pair-programming
• Mutation testing
• Documentation Technique, Wiki, Dossier d'Architecture Technique : OK
• etc, etc...
  

Du Done c’est TTC. Toute taxe comprise. Un récit Done, c’est le dev, les TU, la doc, les tests, l’installation, etc.

Mais en général les membres d'une équipe savent très vite rappeler un mouton qui se soustrait de la bergerie pour ne pas faire ses TUs.

… mouai, Back to reality, à croire que la faute est exclusivement celle des développeurs.

Le non-respect du DOD peut aussi être dû à la pression des stakeholders ou du PO qui ne comprennent pas toujours l’ensemble des éléments du DOD.

Éduquer ces personnes est du rôle du Scrum Master via des Serious Games, vie ma vie de développeur, visite régulière des locaux et de l'open space, venir aux review, etc.

SonarQube

SonarQube est un bon moyen de challenger l'équipe sans être trop technique.

Le plus fun dans l'histoire c'est que même si pour vous "Public methods should throw at most one checked exception" c'est du Mandarin, il suffit de cliquer sur le détail. SonarQube vous donne une courte explication ainsi qu'un exemple de code non-compliant et une solution de code compliant.

Si vraiment ça ne vous parle pas, reste à vous ensuite de demander “Est-ce vraiment critique pour le produit ?” à Google, StackOverflow ou un architecte hagard qui ne sais plus s’il est dans la team ou pas.

SonarQube est plein de bons indicateurs pour vous aider à communiquer et challenger votre équipe. Une fois que vous aurez trouvé les KPIs pertinents, libre à vous de crâner à la machine à café avec un tech lead.

Le SM doit être vigilant et rappeler l’importance de ces KPIs à la Dev même s'ils font peur ou mal. Team et PO doivent surveiller et réduire leur dette avec SonarQube.

Si personne ne le fait, vous devriez montrer à la team qu'elle court un risque si elle ne la prend pas en considération en écrivant du meilleur code ou en payant un peu la dette chaque itération sous peine un jour ... BIMMM c’est la crise des Subprimes !

Le PO doit comprendre qu’il doit octroyer du temps aux Dév. pour que son produit ne soit pas une bombe à retardement.

Dans le cas contraire, si la dette n’est pas prise au sérieux les conséquences peuvent être fâcheuses :

• L'estimation des Stories va vite grimper pour prendre en compte cette dette,
• Votre burnup ou burndown va commencer à faire le yoyo ou l'encéphalogramme plat,
• Pareil pour la vélocité de la team. C'est aussi pourquoi ON NE PILOTE PAS UN PRODUIT AVEC LA VÉLOCITÉ MAIS AVEC DE LA VALEUR MÉTIER pu§@$µ*#§!!!!!!! .... pardon
  

Vous portez le bouclier de l'équipe. Si la team exprime en rétrospective qu'elle peine à prendre de nouvelles histoires sur tel sujet car une classe controller est un “Cauchemar en Openspace”, vous devez le faire entendre au PO.

Sensibilisez-le s'il n'a pas compris. Il doit optimiser son attendu pour le prochain sprint pour que l'équipe éponge un peu la dette en s'attaquant au refacto de la classe.

Attention néanmoins à l’infobésité. Sonar est riche, mais n’explique pas tout. Surtout si l’information est prise de manière statique. Le bon sens et l'expérience de l'équipe doivent prévaloir sur les metrics rapportées.

Mutation Testing

Le DOD peut exiger un seuil minimal de couverture de test (Quality Gate dans Sonar).

Enough is not good Enough.

L’effet pervers dans ce cas est qu’une méthode peut être soumise à un test, mais y a-t-il vraiment une assertion ? Couvre-t-il tous les cas de figure ? Doit-il couvrir tous les cas de figure ? Ce test n’est-il pas un test d’intégration ?

Il y a un truc magique pour ça ! Le Mutation Testing.

Pour faire simple, le Mutation Testing est une opération qui va modifier des choses dans le code (opérateurs, suppression de blocs, etc.), afin de vérifier que les tests associés ne passent plus. En faisant cela, vous vous assurez que le code est bien testé, pertinent, et non simplement couvert. (Cf. annexe pour plus de détails)

Comme le jeu c'est l'apprentissage, en voilà un très drôle à manier avec bienveillance : demander à l'équipe si elle est 100% confiante dans ses Tests Unitaires. (Et qu’elle n’est pas au fait du Mutation Testing évidemment 😆).

Etape 1 Prendre une équipe (qui fait des Tests Unitaires) et poser la question

En principe, il va être tellement simple répondre au SM (surtout s'il n'est pas trop technique) :

" - Dude! On est la dream team, des Hot Shots !! Nos TU c'est ceinture et bretelles ! En plus on fait du TDD"

Traduction : "On est des experts, tu nous fais pas confiance ? Tiens en plus cadeau, je te balance un mot dans ton jargon du parfait Dev Agile, ça va passer crème :)"

Etape 2 Prendre le code en local et mettre en place le Mutation Testing

Regarder le rapport et vraisemblablement... vous aurez de quoi rigoler lorsque vous reposerez la question candidement le lendemain.

Une fois l'expérience faite, il est évident qu'il faut le prendre avec humour. Tu me troll, je te troll. Reste maintenant à comprendre la raison du manque de qualité du TU. (Temps, expérience, formation, périmètre, outillage, etc.)

Le mutation testing va rapidement pouvoir aider l’équipe à se challenger sur la couverture de test, mais surtout savoir si elle est efficace. #Sérénité

À ajouter d’urgence dans votre boite à outil ou à votre DOD si ce n'est pas encore le cas !

Acceptance Test

Après tout, une des valeurs de l'agilité c'est bien "Working Software over comprehensive documentation".

Tester c'est douter. Dans le doute, reboot.
Tester c'est rebooter ?

Une story devrait être autant que possible I.N.V.E.S.T. et répondre à la convention 3C (Card, Conversation, Confirmation). Confirmation pour dire qu'il doit y avoir un minimum d'information pour valider que l'objectif est bien atteint.

Cette confirmation dans une story peut prendre diverses formes. Un scénario de test fonctionnel dans HPALM ou Xray ou même Excel. Pour les plus adeptes de pratiques Agiles, il y a le Behaviour-Driven-Development.

Le BDD propose de mieux conduire le développement sur la base de la conversation et des exemples concrets. Une autre forme plus stricte comme l'ATDD propose une surcouche à la pratique TDD – pratique hautement reconnue pour assurer une bonne qualité de code.

En enseignant et challengeant l'équipe sur des pratiques BDD ou l'ATDD, vous ajouterez une couche supplémentaire vers l'excellence technique en couvrant des aspects aussi bien fonctionnels que techniques. Et en bonus de la non-regression.

C’est ceinture, bretelle et parachute !

Tester, présenter, vulgariser l’utilisation de ces pratiques dans sa team est aussi dans la mission du Scrum Master. Faire adopter ces techniques, c’est aussi challenger l'équipe sur le chemin de la production à haute valeur ajoutée.

Visual Management

Suivre le kanban, le burnup ou burndown est un bon moyen également de humer les odeurs du code.

En effet, si ce n'est qu'au dernier moment, en fin de sprint que la courbe du Done rencontre enfin l'objectif alors que tout le long du sprint l'encéphalogramme était plat.

Alerte Capitaine !

Il est facile d'imaginer comment les stories ont été bouclées. Si en plus l'équipe ne cache pas sous le tapis quelques TU au passage.

Savoir interpréter les courbes c'est important. Mais ça reste de l'interprétation.

La lecture de vulgarisation

Des livres comme "Clean Code", "The Software Craftman" ou “The Clean Coder” sont de bonnes référence pour s'initier aux bonnes pratiques de développement. Faut dire qu’un des auteurs n’est autre que “l'oncle” Bob C. Martin, l'un des signataires de l'Agile Manifesto.

Des acronymes comme KISS, YAGNI, DRY, test FIRST doivent être dans votre vocabulaire.

Voila un petit Cheat Sheet

Autres outils

More Tooooooools ! (Plus d'outils)

J'ai eu la chance d’avoir une présentation sur la solution de Promyze qui se plug sur le Sonar et apporte une dose supplémentaire d’analyse du code statique, des objectifs de groupe et de la gamification.

De quoi ajouter du fun à la correction de violations Sonar.

Attention néanmoins à ne pas en faire un outil de flicage de la team. C'est un outil pour la team et rien d'autre.

La puissance du groupe

Honte à toi si tu donnes des objectifs pour l'évaluation de fin d'année !

Utiliser la force du groupe lors de MOB programming (Séance coding de groupe) ou de randori coding dojo. En facilitant, la session et en déléguant.

La bonne vieille rétrospective

Enfin en tendant l'oreille plus souvent dans l'open space, vous pourrez capter le son caverneux d'un développeur hurlant dans sa barbe après le commit de 600 lignes de code sans commentaire et indentation.

Challengez le à challenger son collègue sinon pourquoi ne pas concocter une retrospective qui va faire jaillir ce genre de problème.

Passe ça au PO...

Pas d’US, pas de code. Pas de code, pas de produit. Pas de produit,  ... pas de produit.

Et du coup, qui se charge de faire des US ? … Et bien notre bon PO.

Écrire du Français, ce n’est pas technique. Ah bon ? Si le développeur reçoit une documentation torchon, malgré tout l’effort et la bonne volonté, inévitablement, il va coder un torchon.

Une technique (du grec τέχνη ou technè) est une méthode ou un ensemble de méthodes, notamment dans les métiers manuels (menuiserie, art de la forge, etc.), où elle est souvent associée à un savoir-faire professionnel.
— Wikipedia

Si votre PO écrit des stories en utilisant des méthodes comme :

• 3C (Card, Conversation, Confirmation)
• Simple matrix(As a …, I want … In order to …)
• INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
• Gherkin (Given, When, Then)
• ...
  

                       System.out.print(!technique.equals(code))

Sorry not sorry. C’est en somme, de la technique.

Lorsque votre PO n’est pas issu du monde de l’informatique et qu’il est du métier, détaché dans le département informatique, vous, Scrum Master, vous devez l’aider à survivre dans la jungle des développeurs.

Le PO est dans la team. Il n’y a pas que la Dev Team dans un projet. Connaître ou même maîtriser les techniques de rédaction de Stories est nécessaire pour un bon Scrum Master.

Dans le cadre de certains projets, il peut être nécessaire d’avoir un Business Analyst (un fonctionnel) pour aider le travail de raffinage. Il faudra l’accompagner lui aussi.

C’est encore plus vrai lors d’un passage à l'échelle. Votre PO ne sera plus en mesure d’assumer seul le travail de rédaction des histoires. Le SM aura pour mission d’assurer l'alignement de tout ce beau monde.

Un Scrum Master devrait donc connaître les techniques du PO. Idem pour l’UX/UI, Architecte, Ops, team support, etc...

J'l'avais dit ... girouette.

Pour conclure

Il existe encore bien d'autres moyens pour pallier la non-expertise technique. Mais il ne faut pas oublier de faire confiance à l'équipe.

Vous êtes Scrum Master et vous n'arrivez pas à challenger la technique, n'essayez pas !

Sauf si vous prenez part au développement.

Demandez de l'aide à un Senior/Lead Développeur. Une équipe, surtout avec de jeunes pioupiou, doit être accompagnée d'un senior.

Surtout n'oublions pas que le Manifest Agile a été rédigé par des développeurs :)

Les 12 principes s'appliquent si déjà on écrit et run correctement un print("Hello world").

The experience of pain or loss can be a formidably motivating force.
— John C. Maxwell

Comprendre le quotidien et les problématiques d’une Team sera un avantage considérable pour anticiper les points de blocage.

Mon avis pour passer d'un bon Scrum Master à un très bon Scrum Master est de manier un minimum la langue de la team : la technique.

Annexe

• Mutation testing

https://www.guru99.com/mutation-testing.html & http://pitest.org/