Je vous parlais la semaine dernière du livre de Claude Aubry : SCRUM, pour une pratique vivante de l’agilité. Si vous n’avez pas lu l’article, c’est par ici. Et si vous n’avez pas encore lu le livre, alors procurez-le vous et faites vous-même le quiz avant de lire les réponses que je vous propose.

Si seules les réponses officielles de l’auteur vous intéressent, vous pouvez aller les consulter ici. Mais comme le dit si bien son auteur : le but de ce quiz est de provoquer des réflexions et des discussions, comme on le faisait au Raid Agile avec Pablo, pas de donner une note. C’est donc dans cet esprit que je vous livre ma vision des choses.

Je ne vous livre ici que les réponses pour lesquelles ma réponse diverge de celle de l’auteur. Il y en a en tout 13.

3 : Le Product Owner veut livrer une version dans laquelle il subsiste un bug d’affichage

Image par testbytes de Pixabay

Ma réponse : A – C’est l’équipe qui décide
La réponse de l’auteur : C – On livre, c’est lui qui décide

Même si je suis d’accord sur le fait que c’est le PO qui doit avoir le mot final, la consultation de l’équipe reste importante. Si par exemple le bug d’affichage contribue à induire l’utilisateur en erreur ou entrer des données erronées qui nécessiteront par la suite du rattrapage de données, il me semble légitime que l’équipe puisse exprimer son avis sur la question.


7 : Le sprint de 3 semaines a commencé vendredi, avec une équipe de 10 personnes. Le lundi lors du scrum du matin, on apprend qu’un développeur s’est cassé le bras droit au ski, il est plâtré pour une semaine.

Image par Hans Braxmeier de Pixabay

Ma réponse : B – L’équipe diminue sa capacité sur  le sprint en enlevant des stories au périmètre
La réponse de l’auteur : D – On verra ce que ça donne et en attendant on lui achète une souris pour gaucher.

Çà nécessite quand même d’en parler avec l’équipe, cela pourrait remettre en jeu l’objectif de sprint. Après lecture de l’explication, je rejoins le fait que l’équipe est grande et devrait normalement avoir assez de mou pour pallier à cette absence temporaire.

8 : Le Product Owner ne vient pas à la mêlée depuis plus d’une semaine.

Ma réponse : C – On continue sans lui et on en parle à la rétrospective
La réponse de l’auteur : D – On insiste pour qu’il vienne au moins 2 fois par semaine.

Cela fait parti des points que j’ai relevés à la lecture du livre et qui me dérangent un petit peu. la mêlée est un moment privilégié pour l’équipe de développement. J’en déjà eu un échange sur le sujet ici.

13 : Une personne dans l’équipe ne fait rien et perturbe les autres. Vous êtes Scrum Master, comment réagissez-vous ?

Image par Alex S. de Pixabay

Ma réponse : D – Vous l’invitez à prendre une bière pour lui proposer d’être le Scrum Master du prochain sprint.
La réponse de l’auteur : D – Vous l’invitez à prendre une bière pour lui proposer d’être le Scrum Master du prochain sprint.

J’ai choisi la réponse D comme l’auteur, mais plutôt par élimination. En discuter avec lui autour d’une bière semble être une bonne option dans un premier temps. Mais ensuite, si la personne ne fait rien, lui proposer le rôle de SM va changer les choses ? En a t’elle la capacité ? Et du coup, le SM il fait quoi pendant ce temps ? Je pense qu’il faut savoir envisager les différentes options proposées en fonction du contexte, et en allant graduellement jusqu’à résolution du conflit. Plus de détails par ici.

14 : Pour réaliser la story « tableau de bord », il faut que le composant qui envoie les données fonctionne. Il doit être développé par une autre équipe. Vous êtes en train de mettre à jour le plan de saison, à quelques jours du démarrage du prochain sprint.

Ma réponse : A – La story ne peut pas être planifiée tant que le composant n’est pas fini
La réponse de l’auteur : C – La story est planifiée dans le sprint après le sprint suivant et on prévient l’autre équipe

Il faudrait plus d’infos du contexte. L’équipe peut-elle mocker le composant ? Quand l’autre équipe a t’elle prévu de faire ce dev ? Si on le planifie dans le sprint d’après, cela veut dire que l’on contraint la deuxième équipe de réaliser ce composant ? Les explications par là.

15 : Une story actuellement en plein développement est finalement jugée inutile par le Product Owner.

Ma réponse : A – On arrête tout de suite de travailler dessus et on passe à autre chose
La réponse de l’auteur : B – On fait le minimum pour garder le logiciel stable

Ce genre de situation doit être extrêmement rare (il faut peut être se poser la question de la durée du sprint si on en arrive à ce point-là). Mais pourquoi s’attarder à finir quelque chose qui sera inutile. Cela représente une perte de temps et induit un risque (régression, dette technique, …). Cela me renvoie au concept des coûts irrécupérables très bien expliqué par David Louapre sur sa chaine Youtube Science Etonnante.

21 : Vous êtes Scrum Master. Lors de la rétrospective, Jeff dit que c’est la faute à Alice si la story S1 n’a pas été finie pendant le sprint.

Image par planet_fox de Pixabay

Ma réponse : A – Vous donnez un carton jaune à Jeff
La réponse de l’auteur : C – Vous dessinez un diagramme en arête de poisson pour identifier les raisons du problème sur S1

Je ne connaissais pas le diagramme en arête de poisson, donc je n’ai pas choisi la réponse C. Mais j’ai aussi choisi la réponse A, car il faut éviter en rétro de désigner une personne en particulier pour parler des problèmes. Cela favorise la sûreté psychologique. On en parle ici.

22 : Dans une équipe de 10 personnes, la mêlée quotidienne est à 9h15. A l’heure prévue, deux membres de l’équipe ne sont pas là. Que fait le Scrum Master ?

Ma réponse : A – C’est le quart d’heure toulousain montpelliérain, il raconte une blague en attendant
La réponse de l’auteur : C – Il commence normalement

Tout dépend le contexte : ça arrive tous les jours ? Ils ont prévenu (problème de transport, accident, …) Il y a d’autres rituels après, des réunions, qui empêchent de repousser ? Ces 2 ont -ils quelque chose d’indispensable à dire pendant cette mêlée ? Selon la situation, cela nécessite effectivement la réponse C. Le billet de l’auteur qui en parle.

23 La définition de fini inclut de vérifier 5 règles de codage ; une ne passe pas à la fin du sprint. Quelle est votre réaction ?

Ma réponse : D – Le reporter au prochain sprint
La réponse de l’auteur : B – Ajouter une story de « cleanup »

Je ne suis pas du tout fan de cette option. Selon moi, une DoD se doit d’être inflexible. Elle est élaborée par l’équipe et l’équipe s’engage à la respecter.

24 : Le sprint de 3 semaines se termine demain et vous avez déjà fini tout ce qui était prévu. Que faites-vous ?

Ma réponse : B – Demander une nouvelle story au Product Owner
La réponse de l’auteur : D – En profiter pour améliorer la qualité

Améliorer la qualité sur ce qui a été produit pendant le sprint ? Parce que la qualité de ce qui a été produit n’est pas jugée suffisante ? Prendre un jour de RTT pourrait aussi être une bonne option, après tout, ça fait du bien aussi de décompresser si on en a l’occasion.

30 : Vous devez livrer pour la fin de saison dans 4 sprints, votre vélocité est de 22. Un travail technique vous permettant de gagner 3 en vélocité est estimé à 5 points. Que faire avec ce travail ?

Ma réponse : D – Çà dépend
La réponse de l’auteur : A – Le faire dans le prochain sprint

La réponse D est facile, elle permet de ne pas trop se mouiller, j’ai choisi la facilité 😙. Bon après, je ne suis pas contre embarquer ce travail puisque l’effort est faible face au bénéfice, mais le risque est-il mesuré ?

33 : Une équipe travaille sur plusieurs projets en même temps. Que vaut-il mieux ?

Ma réponse : D – Ne pas faire du Scrum dans ces conditions, une équipe ne doit travailler que sur un seul projet
La réponse de l’auteur : C – Un seul backlog et un seul SM pour l’équipe

On arrive a tenir un objectif de sprint dans ces conditions ? Quel est l’intérêt de faire ainsi ? Ne vaut-il pas mieux partir sur une approche Kanban ?

36 : Une formation générale à un outil de gestion de projet pour le suivi du temps (timetracking) tombe dans le prochain sprint. Comment l’équipe réagit ?

Ma réponse : B – Le Scrum Master y va pour troller la formation
La réponse de l’auteur : D – Non, on n’a pas besoin de ce genre d’outils avec Scrum

Non sérieusement, même si ça pourrait être tentant de troller le formateur, la direction, des gens que vous n’appréciez pas dans votre boîte, vous êtes là pour travailler. Sur cette question, je suis bien  d’accord avec la réponse de l’auteur.

Pour aller plus loin :

Le blog de Claude Aubry : http://www.aubryconseil.com/

Les réponses de Claude Aubry à son propre quiz : http://www.aubryconseil.com/post/Quiz-Scrum-edition-5