jeudi 2 avril 2009

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 ..."

6 commentaires:

  1. Je suis entièrement d'accord avec ta réaction par rapport à ce test.
    Ce qui m'a le plus choqué, c'est la question 3, sur les "spécifications". Je pense sincérement que la "meilleure" réponse proposée par ce test passe à côté d'une des valeurs fondamentales de l'agilité : la communication. Avoir des histoires utilisateurs mal détaillées me semble être bien plus bénéfique pour le projet car cela favorise la communication *pendant* l'itération et pas seulement avant, quand on prépare tout.
    La dérive actuelle que tu constates avec cette vague de certifications et de notations est inéluctable. C'est la rançon du succès mais je laisse la parole au Maître : http://martinfowler.com/bliki/SemanticDiffusion.html

    RépondreSupprimer
  2. Moi aussi ce test Scrum But m'a un peu troublé, et j'avais trouvé difficile de sélectionner mes réponses. J'ai du mal à voir la "progression" dans les réponses proposées, d'où une difficulté à voir où est la "note maximale". En effet autant éviter les notes dans ce genre de test.

    Bruno

    RépondreSupprimer
  3. Pour le "Certified Scrum Master" j'aime bien le dernier post de James Shore:
    Why I Don't Provide Agile Certification

    Concernant la qualité, j'ose même pas en parler tellement je trouve ça ridicule: déployer un logiciel c'est à la potrée de n'importe qui. Avoir un logiciel qui fait bien (TDD) ce qu'il doit faire (ATDD) déployé c'est ça le véritable but. D'ailleurs je pense, comme UncleBob, que Scrum sans les bonnes pratiques (de développement dans notre cas) ça peut vite tourner en eau de boudin.
    Emmanuel

    RépondreSupprimer
  4. Un tel test ne devrait pas être mis entre toutes les mains. En particulier celles de ceux qui ne sont pas en mesure de comprendre ce qu'implique chaque réponse.

    @ehsavoie,
    sur le caractère obligatoire des "bonnes pratiques" de développement, je reste plus réservé.
    D'après mon expérience, ce qui est important c'est la maitrise technique. Les pratiques issues de XP (par exemple) ne sont qu'un moyen pour mettre en place cette maitrise.

    RépondreSupprimer
  5. Attention, le "site suivant"(http://www.agilecertificationnow.com/) est un canular du 1er avril se moquant justement de la certification ... :-)

    RépondreSupprimer
  6. Oui, justement.
    Le fond du canular est très pertinent (àmha).

    RépondreSupprimer