Un Scrum Master a-t-il besoin de connaître quelque chose en développement logiciel ?

Moi.

Publicité

Aujourd’hui, j’essaie de trouver une réponse à la question. « Est-ce qu’un Scrum Master doit avoir des connaissances en développement logiciel ? »

Vu la façon dont la question est posée, ma réponse est : non. Mais premièrement, cela ne fait pas de mal s’il en sait quelque chose, et deuxièmement, cela dépend de ce que vous considérez comme le développement logiciel. Je vais l’expliquer avec un exemple.

La communication interne est essentielle pour une collaboration d’équipe réussie. Ainsi, un Scrum Master fait du bon travail lorsqu’il prête attention à la communication et, si nécessaire, y travaille avec l’équipe. Je suppose que cette affirmation est suffisamment générale pour que tous les lecteurs soient d’accord.

Ce qui devient passionnant, c’est la question de savoir où se déroule la communication dans une équipe logicielle. Les réponses triviales incluent des réunions comme Daily Scrum, Review, Retrospective, Refinement, etc.

Et qu’en est-il des pull request ?

Les demandes de tirage sont une partie importante de la communication d’équipe. J’ai travaillé avec des équipes pacifiques et dociles lors des réunions, mais qui ont mené de véritables batailles lors des pull request ; un seul coup de poing et un seul coup de couteau. Les « bons » programmeurs contre les « mauvais » programmeurs. Blâmer et pointer du doigt comme dans le manuel. Rien de ce qui était encore moins que « parfait » n’était accepté. (Le fait que le perfectionnisme soit l’un des étonnamment nombreux chemins vers l’enfer fait l’objet d’un autre article de blog.) Les demandes de tirage traînaient parfois pendant des semaines.

Le résultat? Les membres de l’équipe étaient réduits au silence et ne pouvaient plus se déplacer de manière autonome. Ils se sont concentrés sur leur propre protection et non plus sur un travail productif. Des engagements en matière de planification ? C’était extrêmement rare.

Qu’est-ce que cela a à voir avec le Scrum Master ?

Si le Scrum Master estime qu’il doit éviter le code source du logiciel comme le diable évite l’eau bénite, il passe à côté de cette partie de la communication d’équipe. Comme il est plus facile de rabaisser quelqu’un dans l’espace un peu plus protégé de la pull request (écrire au lieu de parler, asynchrone au lieu de synchrone, pas en face-à-face) que dans les réunions d’équipe, ce comportement négatif peut se développer comme un feu couvant pendant une longue période. temps. Lorsque les flammes apparaissent, il est (trop) tard et la cabane brûle littéralement ; et le Scrum Master est surpris.

Lorsque je travaille avec une équipe logicielle, je regarde aussi occasionnellement quelques pull request. Récemment, j’ai voulu faire cela pour un client et j’ai été étonné de ne pas y avoir accès. Il n’y avait qu’un nombre limité de licences pour le système utilisé et aucune licence n’avait été achetée pour le Scrum Master. Pensé trop court.

Que puis-je faire en tant que développeur ?

Une solution est simple : inviter le Scrum Master à (quelques) pull request. Si vous travaillez dans une entreprise qui a peur des coûts de licence, vous devez vous engager à dépenser de l’argent. Tout ce qui fonctionne : traitez les pull request avec le Scrum Master comme dans la programmation par les pairs.

Au revoir. Stéphane

(moi)