Bonjour les agilistes ! Comme vous le savez, la demande crée l’offre et le marché du travail pour les praticiens agiles ne fait pas exception.
Scrum s’est avéré à maintes reprises être le framework le plus populaire pour le développement de logiciels. Étant donné que les logiciels dévorent le monde, les Scrum Master chevronnés sont aujourd’hui très demandés. Et cette demande provoque l’entrée sur le marché de nouveaux professionnels d’autres branches de la gestion de projet, pensant probablement que la lecture d’un ou deux livres Scrum sera suffisante. Ce qui fait de tout recrutement de Scrum Master une tâche difficile.

Supposons que vous cherchiez à pourvoir un poste de Scrum Master ou de coach agile dans votre organisation. Vous trouverez ici 73 questions d’entretien utiles pour identifier le bon candidat. Ils sont issus de mes seize années d’expérience pratique avec Scrum et XP, en tant que Product Owner, Scrum Master ou coach agile.

Comme vous le découvrirez, ce guide ne se contente pas de répertorier les questions, mais contient également des informations générales sur :

• Pourquoi les questions ces questions sont pertinentes et utiles.
• Une gamme de réponses potentielles.
• Deux à trois questions de chaque catégorie fourniront plus qu’assez de terrain pour une conversation engageante de 60 minutes avec les candidats.

Comment nous avons structuré le livre et organisé les questions et réponses

L’ebook fournit des questions et des conseils sur la gamme de réponses appropriées. Ceux-ci devraient permettre lors de l’échange de plonger profondément dans la compréhension d’un candidat de Scrum et de son état d’esprit agile. Cependant, veuillez noter que :

• Les réponses reflètent l’expérience personnelle de l’auteur et peuvent ne pas être valables pour toutes les organisations : ce qui fonctionne pour l’organisation A échoue probablement dans l’organisation B.
• Il n’existe pas de bonnes questions à choix multiples pour identifier l’état d’esprit agile d’un candidat, étant donné la complexité de l’application de l’agilité.
• L’auteur partage une vision holistique des méthodologies agiles : agile équivaut à la découverte du produit (ce qu’il faut construire) plus la livraison du produit (comment le construire).

Dans cette nouvelle version de l’ebook, nous avons ajouté une nouvelle série de questions permettant de parler avec subtilité de la planification de sprint :

Question 1 : Comment organiseriez-vous le Sprint Planning ?

Cette question ouverte permet au candidat de partager SON expérience. Celle qu’il a vécu dans les tranchées et son idée générale de la façon dont une équipe Scrum doit vivre un sprint planning.

Une façon possible d’organiser un Sprint Planning est :

• Le Product Owner présente l’objectif du nouveau Sprint. (Tiré du Scrum Guide : “Le Product Owner propose comment le produit pourrait augmenter sa valeur et son utilité dans le Sprint actuel.”)
• Toute l’équipe Scrum crée un Sprint Goal.
• Les développeurs s’engagent à respecter l’objectif du sprint puis ils identifient les éléments de travail nécessaires pour atteindre l’objectif de sprint, très probablement à partir du backlog de produit.
  • Alternativement, ils créent de nouveaux éléments de travail.
  • Probablement, les développeurs affinent également les éléments de travail, si nécessaire, et planifient comment les accomplir.

Question 2 : Quels facteurs une équipe Scrum doit-elle prendre en compte lors de la planification du sprint pour déterminer un objectif de sprint réalisable ?

Les critères typiques à prendre en compte par une équipe Scrum sont, par exemple :

• Qui sera présent lors du Sprint ; y a-t-il quelqu’un en vacances ou en congé de maladie?
  Les personnes quittant l’équipe ont-elles besoin d’un transfert de connaissances de dernière minute, ou les nouvelles personnes rejoignant l’équipe ont-elles besoin d’une bonne intégration ?
• Y aura-t-il des jours fériés pendant le Sprint ?
• Disposons-nous de tous les outils nécessaires et les connaissons-nous ?
• Connaissons-nous la partie de l’application sur laquelle nous allons travailler ? Ou est-ce une terra incognita ?
• Sommes-nous confrontés à des dépendances vis-à-vis d’autres équipes ?
• Quel niveau de dette technique devons-nous résoudre ?
• Quelles ont été les performances passées de l’équipe ?

Très probablement, les parties prenantes considéreront une équipe Scrum comme efficace lorsqu’elle parviendra à créer de la valeur pour les clients et l’organisation à chaque Sprint.

Par conséquent, du point de vue de l’équipe, l’établissement de relations et de confiance avec les parties prenantes nécessite une gestion des attentes plus semblable à celle de Wallstreet : les parties prenantes apprécient davantage une livraison fiable qu’une explosion sporadique de productivité. Cette compréhension devrait guider l’équipe Scrum dans la détermination des objectifs de sprint réalisables.

Question 3 : Est-il acceptable pour le Product Owner d’introduire un objectif pour le prochain Sprint qui ressemble à une liste d’éléments de travail ?

Scrum est à son meilleur lorsque l’équipe peut travailler comme une unité pour atteindre un objectif unique. Scrum ne sera pas efficient si l’équipe doit travailler sur une liste interminable d’éléments de travail sans rapport entre eux.

Bien qu’une telle liste aléatoire de “trucs” puisse être une nécessité occasionnelle pour chaque équipe Scrum, la situation devrait faire soulever les sourcils lorsqu’elle persiste. Si chaque Sprint ressemble à ceci, l’équipe doit se demander si Scrum est la bonne pratique à suivre en général ou ce qu’elle peut faire pour améliorer sa façon de travailler.

Question 4 : Est-il acceptable d’utiliser une « définition de prêt ? »

L’utilisation d’une “Definition of Ready” dépend de la situation, du contexte, de l’équipe Scrum. Par exemple, supposons qu’il s’agisse d’une équipe junior qui lutte toujours avec les mécanismes de Scrum. Dans ce cas, cela pourrait être un moyen temporairement utile de soulager une partie de la pression sur l’équipe lors de l’affinement du Product Backlog et de la planification du sprint.

Cependant, supposons que la “Definition of Ready” soit utilisée de manière dogmatique comme une liste de contrôle, rejetant tous les éléments de travail lors de la planification du sprint qui ne sont pas couverts à 100 % par cette nouvelle norme. Dans ce cas, vous réintroduisez du cycle en V par la porte dérobée…Pire encore serait l’utilisation par l’organisation d’une “Definition of Ready” comme métrique pour suivre l’équipe.

D.O.R KARDS version 2

Question 5 : Est-ce une idée utile pour les développeurs de planifier tout le travail pour toute la durée du sprint lors de la planification du sprint ?

Tout planifier à l’avance implique le risque que les développeurs ne tiennent pas compte des apprentissages et des nouvelles connaissances acquises au cours du Sprint. Cette façon de faire ressemble à l’introduction d’une planification en cascade par la porte dérobée, mettant inutilement en danger la réalisation de l’objectif du sprint en ignorant les boucles de rétroaction.

Scrum résout ce problème avec le Daily Scrum qui répond à une question : Sommes-nous toujours sur la bonne voie pour atteindre l’objectif du sprint ? Ou avons-nous appris quelque chose depuis le dernier Daily Scrum qui nous encourage à reconsidérer notre plan actuel ?

Question 6 : Votre organisation accorde une grande importance au fait que les livraisons correspondent aux prévisions. Est-ce quelque chose d’inquiétant ?

Absolument. Si votre organisation ne voit pas cela du bon œil, les équipes préféreront avancer en toute sécurité. En conséquence, les équipes Scrum choisiront régulièrement des objectifs de sprint plus petits, peu ambitieux et fourniront moins de valeur qu’elles ne pourraient le faire dans un environnement plus sûr et plus confiant.

Question 7 : Un Scrum Master doit-il se préoccuper du taux d’occupation des Développeurs ?

Absolument pas. Scrum n’est pas une autre approche enracinée dans le paradigme industriel avec un “rouge à lèvres agile” sur le dessus, mettant l’accent sur l’autogestion uniquement pour micro-gérer les membres de l’équipe.

A l’inverse, Scrum, consiste à se focaliser l’objectif du sprint. Ici, le Scrum Master est le coach de l’équipe, pas le garant des « quotas de production ». En parlant de cela : lors de la résolution de problèmes complexes et adaptatifs, il est inutile de se concentrer sur les mesures de sortie, telles que le taux d’utilisation de vos employés. Ajouter plus de code, par exemple, ne crée pas de valeur en soi.

Comment utiliser ces questions ?

Un bon scrum master doit etre passionné et ne pas avoir peur de se salir les mains. Bien que les règles de base soient triviales, que Scrum paraisse simple,  faire en sorte qu’un groupe d’individus ayant des antécédents, des niveaux d’engagement et des agendas personnels différents se forme et fonctionne en équipe est une tâche complexe. Comme toujours, vous pourriez dire lorsque les humains sont impliqués. Plus l’organisation est grande, plus il y a de niveaux de gestion, plus l’échec est probable.

Les questions ne sont pas nécessairement adaptées pour transformer un recruteur inexpérimenté en un expert agile. Mais entre les mains d’un praticien agile, ils aident à déterminer quel candidat a réellement travaillé dans un contexte agile dans le passé.

Mon conseil : Optez pour un vétéran pragmatique qui a déjà connu l’échec dans d’autres projets et porte les cicatrices pour le prouver.