Série - Le quiz Scrum

Fil des billets - Fil des commentaires

Résultats du quizz 1

La première question était la suivante :

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.

Je proposais ces 4 réponses :

  1. Le ScrumMaster interdit le ski à toute l’équipe jusqu’à la fin de la release
  2. L’équipe diminue sa capacité sur le sprint en enlevant des stories au périmètre
  3. On lui trouve un remplaçant
  4. On verra ce que ça donne et en attendant on lui achète une souris pour gaucher

La réponse 1 a été choisie par 3% des participants. Même si c'est tentant pour certains, un ScrumMaster n'est pas en mesure d'interdire, ce n'est pas dans l'esprit et donc ce n'était pas la réponse attendue.

La réponse 3 a recueilli 9% des suffrages. Ajouter une personne dans une équipe ne se fait pas facilement. Cela demande de passer du temps avec lui pour le former. Faire ça pour un remplacement de tout au plus quelques jours ne paraît pas être une bonne solution. Les personnes ne sont pas des ressources interchangeables.

Il restait les réponses 2 et 4.

Une large majorité (61,5%) des répondants a choisi la réponse 2, se disant qu'avec une personne de l'équipe en moins, il convient de diminuer la capacité de l'équipe. Cependant cela paraît prématuré d'enlever tout de suite des stories au plan de sprint. En effet puisqu'on est au début du sprint, il doit y avoir du mou dans le plan. Si on veut en rester aux chiffres, l'absence du skieur (maladroit ?) devrait porter sur moins de 10% du temps disponible de l'équipe. On reste dans la marge qu'une équipe doit prendre au début d'un sprint. A mon avis, il est donc prématuré de diminuer le périmètre du sprint dès maintenant.

C'est donc la réponse 4 "on verra ce que ça donne", choisie par 26,5% des participants, qui a ma préférence. Lors des réunions quotidiennes, l'équipe statuera sur son avancement par rapport aux objectifs du sprint. Peut-être que finalement il ne sera pas nécessaire d'enlever une story. On verra.

Merci aux 132 personnes qui ont participé en répondant à cette question. Je publie la deuxième question, pendant ce temps-là, la discussion peut continuer sur la première.

Retours sur la question 2 du quizz

La question portait le Product Owner :

Un sponsor important du projet tient beaucoup à une fonction mais ne sait pas bien de quelle façon elle pourrait être proposée aux futurs utilisateurs du produit. Vous êtes Product Owner, que faire ?

Il fallait choisir parmi les 4 réponses suivantes :

  1. Lui demander d’écrire la spécification
  2. Définir une story simple sans IHM définitive et la mettre prioritaire
  3. Mettre sa demande à la fin du backlog
  4. Attendre qu’il dise clairement ce qu’il veut

Merci aux 112 personnes qui ont répondu, en plein mois d'août.

La réponse 1 a été choisie par 10% des participants au QCM, la 2 par 51,5%, la 3 par 12,5% et la 4 par 26%. C'est un peu plus réparti que pour la première question et surtout, cette fois, une (petite) majorité a choisi la réponse qui a ma préférence.

Pourquoi ? Procédons par élimination.

Lui demander d'écrire la spécification

Si le sponsor ne sait pas bien comment une fonction peut être proposée, on peut penser qu'il sera encore moins capable d'écrire une spécification. Déjà quand un client sait à peu près ce qu'il veut, il ne sait pas pour autant l'écrire, alors ce n'est pas probablement pas une bonne idée de pousser ce sponsor à rédiger un document.

Mettre sa demande à la fin du backlog

Mettre à la fin du backlog, c'est dire "on verra plus tard". Ce plus tard, n'est pas connu, ça peut être beaucoup plus tard. Voire jamais si la story reste toujours à la fin. Comme c'est un sponsor important, on peut supposer que ce qu'il propose est important aussi et apporte de la valeur.

Attendre qu'il dise clairement ce qu'il veut

Cela paraît plus facile que de lui demander d'écrire la spécification. Cependant l'énoncé laisse entendre que c'est dans la mise en œuvre de la fonction que le sponsor ne sait pas dire avec précision. Il n'est pas en mesure de définir l'interface homme machine, par exemple. Il ne saura pas le dire clairement, même en insistant. Il vaut mieux lui montrer quelque chose et le faire réagir.

Définir une story simple sans IHM définitive et la mettre prioritaire

C'est pourquoi la réponse 2 est la plus adaptée. Elle permet de réduire le risque constitué par l'incertitude sur cette fonction.

Extrait de Scrum, le guide pratique etc... édition 2, page 63 :

La réduction de l’incertitude sur des besoins des utilisateurs est un critère de priorité. Quand un utilisateur désire une fonctionnalité mais ne sait pas de quelle façon le service doit être rendu, la solution est de lui montrer rapidement une version simple, pour obtenir son feedback. La connaissance apportée par le développement des stories relatives à cette fonctionnalité est une occasion d’améliorer le produit.

Quizz, la question 3 sur le ScrumMaster

La question était la suivante :

Une personne dans l’équipe perturbe les autres. Vous êtes ScrumMaster, comment réagissez-vous ?

Vous aviez le choix entre les réponses suivantes :

  1. Vous la virez de l'équipe, la majorité est d’accord
  2. Vous ne faites rien, il n’y a pas de chef avec Scrum
  3. Vous faites un rapport à la direction
  4. Vous l’invitez à prendre une bière pour lui proposer d’être le ScrumMaster du prochain sprint

Rappel : il s'agit de la 3ème question, sur les 15 qui sont proposées à la fin de l'édition 2 de mon livre et qui sont un extrait des 70 qui font l'objet d'un QCM suivi d'un débat mené le dernier après-midi de mes formations Scrum.

Cette fois, une large majorité parmi les 113 votants s'est dégagée sur la réponse que j'aurai aussi choisie. L

On pouvait procéder par élimination.

Ne rien faire

En fait cela dépend un peu de l'intensité et de la fréquence de la perturbation. Comme cela n'était pas précisé, on pouvait supposer que cela considérait un véritable obstacle. Or si le ScrumMaster n'est effectivement pas un chef, il a comme mission d'éliminer les obstacles qui bloquent ou simplement freinent l'équipe. Ne rien faire, comme l'ont proposé 6,19%, n'est pas dans l'esprit du rôle.

Rapport à la direction

Puisque le ScrumMaster doit faire quelque chose, pourquoi pas un rapport à la direction se sont dit 6,19% des participants au quizz. Mais le ScrumMaster doit d'abord chercher une solution avec l'équipe. Une de ses responsabilités est de l'amener vers plus d'auto-organisation et je doute qu'un rapport à la direction y contribue.

Le virer

Le ScrumMaster n'est pas un chef et l'équipe est autonome, alors comme 15,93% des votants, on pourrait se dire que l'équipe peut décider à la majorité. Mmmmh, avec ce genre de pratique d'exclusion, je pense qu'on est loin des valeurs préconisées. Le ScrumMaster est là pour aider à résoudre les conflits, qui ne manquent pas d'arriver dans les équipes. Il peut même essayer de les anticiper. Si le conflit est avéré, il doit mettre en place les discussions permettant d'en trouver les raisons profondes.

Réponse 4

Pendant longtemps, la réponse 4 de cette question était : le ScrumMaster tente de résoudre le conflit. Comme je trouvais que c'était un peu facile, j'ai changé le texte pour instiller un peu plus de doute. Cela n'a pas empêché 71.68 % de la choisir. La bière est un bon moyen d'établir le climat permettant de remonter aux causes profondes du problème. Lui proposer de devenir ScrumMaster est une façon subtile, mais qui peut être risquée s'il accepte, de responsabiliser le perturbateur. Une approche plus classique que la bière est la discussion franche avec toute l'équipe, lors de la rétrospective par exemple. Mais ce n'était pas parmi les réponses proposées.

Dans un billet récent, Emmanuel Chenu revient sur ses années d'expérience dans ce rôle, qu'il préfère maintenant appeler meneur d'équipe. Meneur, ça se discute, mais ça montre au moins que ce n'est pas un rôle passif.

Quizz, la question 4 sur la planification

L'énoncé était le suivant :

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

Les réponses proposées :

  1. La story est planifiée dans le prochain sprint
  2. La story ne peut pas être planifiée tant que le composant n’est pas fini
  3. La story est planifiée dans le sprint après le suivant et on prévient l’autre équipe
  4. L’équipe développe elle-même le composant

Tout juste 100 votants. C'est un peu moins que pour les autres questions, peut-être parce la réponse ne paraissait pas évidente. D'ailleurs les résultats montrent que c'est assez partagé entre les 4 réponses.

21% ont choisi de planifier la story pour le prochain sprint. C'est risqué, probablement trop.

21% pensent qu'il faut attendre que le composant soit fini pour planifier la story. C'est prudent, mais trop prudent.

Une majorité relative, 46%, est pour planifier la story, mais pas dans le sprint qui va commencer, dans celui d'après. C'est raisonnable et c'est ce que je choisis aussi. C'est à ça que servent les plans, à prévoir un point de synchronisation entre des équipes. Il subsiste un risque, mais plus limité et il restera possible, en cas d'obstacle avéré, d'adapter le plan pendant le sprint suivant.

Les 11% restants sont pour que l'équipe développe elle-même le composant. Cela élimine les dépendances sur une autre équipe, mais c'est sûrement prématuré de prendre une telle décision tout de suite.

Quizz, la question 5 sur le backlog

La question était la suivante :

Une story planifiée pour le prochain sprint est jugée finalement inutile par le Product Owner.

Pour ce quizz, je proposais de choisir entre les 4 réponses suivantes :

  1. On la supprime
  2. On la fait quand même car elle est dans le plan de release
  3. On la remplace par une autre de même taille et on la garde en fin de backlog
  4. On diminue sa priorité

152 personnes ont répondu, c'est plus que pour les quizz précédents. C'est peut-être parce que la question paraissait facile, ou tout simplement parce que c'est la rentrée, et que j'ai plus de visiteurs.

Longtemps j'ai cru que pour la première fois une des réponses proposées ne serait choisie par personne. Finalement, juste avant que je ferme le sondage, quelqu'un a voté pour la réponse 2. Bien sûr ce n'est pas la bonne réponse. Faire quelque chose d'inutile, c'est à éviter. Cependant je pouvais m'attendre à avoir plus de votants pour cette réponse. En effet, il y a encore pas mal de visiteurs de mon blog qui y arrivent par les mots clés "cycle en V" [1]. Et si cela semble naturel pour les praticiens de l'agilité de ne pas faire quelque chose qui est jugé inutile, il est usuel pour d'autres de faire ce qui est planifié. On ne se pose même pas la question de savoir si c'est utile : c'est dans le plan initial, c'est probablement dans le cahier des charges ou la spécification, alors on le fait.

Un peu plus de 10% préconisent de diminuer la priorité de la story inutile. Et plus de 53% suggèrent de la garder à la fin de backlog. Ce qui revient à peu près au même. On ne sait jamais, se disent-ils, le Product Owner peut -une nouvelle fois- changer d'avis ? L'idée de conserver une trace doit aussi en avoir poussé quelques-uns à choisir la réponse 3[2].Je comprends parce qu'en tant que Product Owner, j'ai eu, dans le passé, un doute au moment de supprimer une story. Mais si elle est vraiment inutile, il ne sert à rien de faire du stock dans le backlog.

Donc on la supprime, comme ont répondu 35,54% des participants.

Notes

[1] J'ai écrit il y a plus de 4 ans un billet "Le cycle en V n'existe pas."

[2] la première partie de la réponse "On la remplace par une autre de même taille" a pu troubler certains. Mais le backlog étant une liste ordonnée, quand on supprime un élément, les suivants remontent automatiquement.

Quizz, la question 6 sur la planification de sprint

La question était la suivante :

La vélocité des 2 sprints passés est 13 puis 11. A la fin de la planification de sprint, l’équipe est prête à mettre 20 points dans le sprint. Vous êtes Product Owner, quelle est votre réaction ?

C'est un QCM avec 4 choix possibles, comme les questions précédentes. Il fallait choisir parmi les réponses que je proposais[1] :

  1. Voyant l’équipe motivée, vous essayez d’ajouter une autre story.
  2. Aucune, c’est la responsabilité de l’équipe.
  3. Vous demandez ce qui justifie une telle accélération de vélocité.
  4. Vous leur promettez le champagne à la fin du sprint s’ils y arrivent.

152 personnes ont participé, exactement le chiffre du quizz précédent.

Nous sommes donc vers la fin de la réunion de planification de sprint(article de 2007) et nous jouons le rôle de Product Owner.

  • La réponse 1 (2,63%) est tentante, dans l'idée d'avoir encore plus de choses finies à la fin du sprint. Mais ce n'est pas très raisonnable.
  • Ne rien dire (réponse 2, 23,03%) paraît plus correct, c'est vrai que c'est la responsabilité de l'équipe de définir ce qu'elle est capable[2] de faire dans un sprint. Mais le Product Owner fait aussi partie de l'équipe et s'il a des doutes, il est normal qu'il les exprime en demandant quelques explications.
  • C'est donc la réponse 3, choisie par 61,84% des participants, qui décrit le mieux ce qu'il faut faire en premier.
  • Après avoir obtenu quelques justifications, on peut aussi leur promettre le champagne (réponse 4 choisie par 12,5%), ça change de la bière.

Notes

[1] Vous pouvez certes avoir envie de donner une autre réponse, qui ne figure pas dans ce que je propose et qui vous semble meilleure. Mais, pour que cela ne soit pas trop facile et favorise la réflexion et la discussion, je me suis efforcé de ne pas mettre de réponse trop évidente.

[2] c'est pour ça que j'emploie vélocité pour la mesure et capacité pour la prévision.

Quizz, la question 7 sur le scrum quotidien

La question était la suivante :

Dans une équipe de 10 personnes, le scrum quotidien est à 9h15. A l’heure prévue, deux membres de l’équipe ne sont pas là. Que fait le ScrumMaster ?

Les réponses :

  1. C’est le quart d’heure toulousain, il raconte une blague en attendant : 11.89 %
  2. Il repousse la réunion à 10h : 16.78 %
  3. Il commence normalement : 71.33 %
  4. Il annule le scrum du jour, on verra demain : 0 %

Nombre de votes : 143

Si je savais raconter des blagues (ou si j'aimais en écouter), j'aurais peut-être choisi la réponse 1. S'il n'y avait pas 8 personnes qui attendaient à 9h, j'aurais envisagé la 2. Si j'avais l'esprit de contradiction, je choisirai la réponse 4, pour laquelle personne n'a voté. 0.

Finalement je pense qu'il vaut mieux commencer le scrum quotidien normalement, à l'heure prévue. Si les retards se poursuivent les jours suivants, on en parlera à la rétrospective.

Quizz, la question 8 sur la revue de sprint

La question était la suivante :

Une heure avant la revue, un développeur trouve un défaut dans l’interface utilisateur d’une story qui doit être présentée. Que faire ?

Ce quizz a obtenu beaucoup plus de réponses que les précédents : 239. Il faut dire qu'il a duré plus longtemps, pendant que j'étais en vacances chez mes cousins grecs :

plage à Tinos

Les réponses, en pourcentage :

  1. Retirer la story de la démo 22.59 %
  2. Corriger le défaut en vitesse 2.09 %
  3. Faire la démo de la story en passant par le raccourci clavier et en expliquant pourquoi 74.06 %
  4. Montrer la story à toute vitesse en espérant que le public n’y voit que du feu 1.26 %

Il n'y a pas de deuxième tour, c'est la réponse 3 qui gagne.

Quizz, la question 9 sur la rétrospective

La question était :

Vous êtes ScrumMaster. Lors de la rétrospective, Thierry dit que c’est la faute à Olivier si la story S1 n’a pas été finie pendant le sprint.

Voici les résultats du quizz, sur 154 votants :

  1. Vous donnez un carton jaune à Thierry : 13.64 %
  2. Vous donnez un carton jaune à Olivier et à Thierry : 7.79 %
  3. Vous dessinez un diagramme en arête de poisson pour identifier les raisons du problème sur S1 : 62.34 %
  4. Vous organisez un duel aux fléchettes : 16.23 %

En raison d'une actualité chargée, je ne commente pas les résultats pour l'instant, si ce n'est pour dire que je choisis la réponse 3. J'y reviendrai plus tard, ainsi que sur les commentaires qui m'ont déjà été faits sur les différents quizz, comme ceux que pouvez continuer à ajouter.

Quizz, la question 10 sur la signification de fini

La question était la suivante :

La signification de fini dit que les tests de performance doivent être passés à chaque sprint. L’équipe n’y arrive pas. Que faire ?

La signification de fini est une pratique qui vise à obtenir un résultat (l'incrément de produit) de qualité à la fin du sprint. La qualité souhaitée est définie par l'équipe et clairement affichée, pour que fini signifie la même chose pour tout le monde et que cela guide les travaux du sprint.

Cette pratique est complémentaire à celles du cérémonial (planification du sprint, scrum quotidien, revue, rétrospective). Son importance est reconnue, ce qui m'a poussé à en faire un chapitre de mon livre, le chapitre 11.

Vous avez été 136 à participer à ce quizz.

Je rappelle les 4 réponses entre lesquelles il fallait choisir :

  1. Noter le problème sur un post-it rouge
  2. Ajouter une story technique pour la prise en mains de l’outil pour tester les performances
  3. Changer la signification de fini
  4. Demander à l’équipe de faire de son mieux sur les perfs, on testera plus tard

Vous êtes 14% à avoir choisi la réponse 1, 76,5% ont préféré la 2, plus de 6,5% la 3, et le reste (3%) la réponse 4.

Changer la signification de fini à la baisse va dégrader la qualité à la fin du sprint. Repousser le passage des tests de performance présente des risques. Noter le problème ne suffit pas. Sensibiliser l'équipe est une bonne chose, mais sur un sujet comme celui-là, cela n'est pas suffisant.

Il est préférable d'investir dans la prise en mains de l'outil. C'est une story technique, elle apparait dans le backlog. Elle demande des efforts et apporte de la valeur (indirecte).

Je rejoins donc la majorité sur la réponse 2.

page 1 de 2 -