TOUCHE PAS A MON SCRUM!

J'écris ce billet en réaction à un test paru en ligne, intitulé Scrum But, dont les questions et réponses auraient été proposées par Jeff Sutherland. Je n'en veux pas à la personne qui a mis en ligne ce test, mais plutôt à celle qui l'a inspiré. (quel parricide! ;o)

QUESTIONS & RÉPONSES

Reprenons certaines questions et réponses qui m'ont chagriné. D'abord, il faut savoir que le score maximum de 8/8 est obtenu en répondant à la dernière réponse de chaque question.

Question 2 : Pratique des test

Pas d'Assurance Qualité (QA)
Le code est testé unitairement
Les fonctionnalités sont testées
Les fonctionnalités sont testées dès qu'elles sont finies
Le logiciel passe des tests d'acceptation
Le logiciel est déployé

Personnellement, je préfère un logiciel testé unitairement ET qui passe ses tests d'acceptation ET qui est déployé à un logiciel déployé. Il est peut-être sous-entendu qu'un logiciel déployé est aussi testé unitairement et passe aussi ses tests d'acceptation. Ceci dit, ce sous entendu est dangereux: Je connais des équipes qui périodiquement déploient "de la merde".
Si nous prenons le raccourci du sous-entendu, alors la meilleure réponse n'est qu'une interprétation de Scrum. En effet, le produit doit être potentiellement mis en production avec son incrément à la fin de chaque itération. Le déploiement systématique me semble être une interprétation dogmatique.

Question 3 : Spécifications

Pas de requirements
De lourds documents de requirements
Des user stories mal détaillées
De bons requirements
De bonnes user stories
Des spécifications Agile
De bonnes user stories couplées à des spécifications Agile si nécessaire

Les pratiques de Scrum incluent pas "De bonnes user stories couplées à des spécifications Agile si nécessaire". Il s'agit d'une bonne pratique - parmi d'autres. Là, on confond modèle et implémentation. Je connais des contextes où Scrum est appliqué avec succès et où "de bons requirements" sont absolument nécessaires à la réussite du projet.

Question 4 : Product Owner

Pas de Product Owner
Un Product Owner qui ne comprend pas Scrum
Un Product Owner qui dérange l'équipe
Un Product Owner qui n'est pas impliqué avec l'équipe
Un Product Owner avec un product backlog
Un Product Owner qui construit sa roadmap de release en se basant sur la vélocité de l'équipe
Un Product Owner qui motive l'équipe

Désolé, je vais pinailler, mais où avez-vous lu que le Product Owner doit motiver son équipe? Il me semble qu'il doit maximiser le retour sur investissement du projet. Motiver l'équipe est une manière agréable et louable d'y parvenir mais cela n'est pas l'objectif.

Question 6 : Estimation

Le Backlog de produit n'est pas estimé
Les estimations ne sont pas faites par l'équipe
Les estimations ne sont pas faites en utilisant le planning poker
Les estimations sont faites par l'équipe en utilisant le planning poker
L'erreur sur les estimations est <>

Il me semble que le planning poker est une bonne pratique d'estimation - sans être la meilleure. Pour moi, la meilleure pratique d'estimation est la plus adaptée au contexte du projet. De plus, le planning poker n'est pas une pratique Scrum. Il s'agit d'une bonne pratique compatible avec Scrum. Là encore, on confond modèle et implémentation.

Question 8 : Dérangement de l'équipe

Le manager ou le chef de projet dérange l'équipe
Le Product Owner dérange l'équipe
Le manager, chef de projet ou chef d'équipe assigne les tâches
Présence de chefs de projet en plus des rôles Scrum
Personne ne dérange l'équipe, uniquement des rôles Scrum

Les rôles Scrum sont très pertinents mais affirmer que seuls le PO et le SM peuvent "déranger" l'équipe me semble dogmatique. D'autres rôles peuvent apparaitre dans certains contextes.

EN CONCLUSION

En synthèse, il me semble que ce questionnaire confond modèle et implémentation. Je regrette que la note maximale soit obtenue par conformité à l'implémentation suggérée dans les réponses et non par conformité au modèle. Je rigole doucement, car c'est l'excellent argument mis en avant par le SEI pour défendre le CMMi. De plus, je peux affirmer que l'application des pratiques suggérées peut faire échouer certains projets!

Aussi, cela me dérange que le questionnaire soit sanctionné par une note - comme une évaluation ou une certification. Cela me rappelle l'autre modèle souvent confondu avec des implémentations ;o)

Bref, personnellement, je préfère encore le test Nokia. Il teste la conformité de votre implémentation de Scrum par rapport au modèle et non par rapport à une implémentation suggérée. Relisez-le, vous constaterez que les questions ont un niveau d'abstraction supérieur. Aussi, le test Nokia ne sanctionne pas par une note. Il ne vous permet que de réfléchir à votre implémentation de Scrum. N'est-ce pas l'essentiel?

Ces deux derniers jours, le test Scrum But et le site suivant m'ont tout deux troublé. Attention à la dérive de l'évaluation et de la certification! Ai-je bien fait de mettre le logo Certified ScrumMaster sur mon blog? Scrum saura t-il rester humble? Je me considère praticien de Scrum et pourtant je ne me reconnais pas dans ce test.
Je suis sûr qu'une collègue me dira: "Bôf, c'est pas grave ..."