UN EXEMPLE DE CHECKLIST POUR SCRUM MASTERS

Michael James
(mj4scrum@gmail.com)
14 septembre 2007, rvis le 24 juillet 2012
Traduction du 12 aot 2015 par Maxime Sinclair

Un Facilitateur Temps Complet ?

Un Scrum Master correct peut grer deux ou trois quipes en mme temps. Si vous vous contentez
dorganiser des runions, de vrifier le respect des dlais impartis (timebox NdT), et de supprimer
les obstacles explicitement rapports, vous pourrez remplir ce rle temps partiel. Lquipe pourra
quand mme dpasser les attentes habituelles, pre-Scrum de votre organisation, et il narrivera
probablement rien de catastrophique.

Mais si vous pouvez imaginer une quipe qui prend du plaisir accomplir des choses que personne
ne pensait possible auparavant, au sein dune organisation transforme, alors considrez-vous
comme un grand Scrum Master.

Un grand Scrum Master ne peut grer quune quipe la fois.

Nous recommandons un Scrum Master ddi par quipe denviron sept personnes, particulirement
au dmarrage.

Si vous navez pas dcouvert tout le travail quil y a faire, mettez-vous lcoute de votre Product
Owner, de votre quipe, des pratiques de dveloppement de votre quipe, et de lorganisation externe
votre quipe. Bien quil ny ait pas une recette unique pour tout le monde, jai relev des points
typiques que les Scrum Masters ngligent. Remplissez chaque case avec , , ?, ou N/A, comme
dcrit en dernire page.

Partie I - Quelle est lefficacit de mon PO ?

Les Scrum Masters amliorent lefficacit des Product Owners en les aidants trouver les moyens de
grer le Backlog et le plan de livraison. (A noter : seul le Product Owner peut prioriser le backlog.)

Est-ce que le Backlog est prioris selon ses dernires rflexions ?

Est-ce que toutes les exigences et les dsirs de toutes les parties prenantes sont prsents dans le
Backlog ? Rappel : le backlog est mergent.
La taille du backlog est-elle raisonnable ? Pour garder un nombre ditems raisonnable, conserver
les items dtaills vers le haut, et les ides gnrales (epics NdT) vers le bas. Il est contre-
productif danalyser trop en profondeur ce qui nest pas au sommet du Backlog. Vos exigences
vont voluer tout le long des discussions rgulires que vous aurez avec les parties prenantes /
clients propos du produit en cours de dveloppement.
Les fonctionnalits (spcialement celles proche du sommet du Backlog) pourraient-elles tre
mieux exprimes sous la forme de user stories indpendantes, ngociables, ayant de la valeur,
estimables, suffisamment petites, et testables ?
Avez-vous expliqu votre PO ce quest la dette technique et comment lviter ? Une pice du
puzzle peut consister ajouter le test automatis et le refactoring la dfinition du "fini" pour
chaque item du backlog.
Le backlog est-il un radiateur d'information, clairement visible pour l'ensemble des parties
prenantes ?

Copyright 2007-2012 Michael James. All Rights Reserved 1

 Si vous utilisez un outil lectronique de gestion du backlog, tout le monde sait-il l'utiliser
facilement ? Les outils de gestion lectroniques peuvent se transformer en rfrigrateurs
d'information privs du rayonnement actif du Scrum Master.
Aidez-vous diffuser l'information en affichant la vue de tous des rapports imprims ?
Aidez-vous diffuser l'information en crant de grands graphiques bien visibles ?
Avez-vous aid votre Product Owner grouper les items du backlog par livraisons ou par
priorits ?
Est-ce que tout le monde sait si le plan de livraison est toujours raliste ? Pendant les runions de
revue de Sprint, vous pourriez montrer tous le graphique de Product/Release Burndown
indiquant les items qui ont t certifis "finis". Les graphiques montrant le taux de ralisation des
items du Backlog et celui dajout des nouveaux items permettent de rvler au plus tt les drives
de primtre/planning.
Est-ce que votre Product Owner ajuste le plan de livraison aprs la dernire revue de sprint ? La
minorit des Product Owners qui livrent des produits correctement tests temps re-planifient la
version chaque Sprint. Ceci implique probablement de reporter certains items des versions
futures au profit ditems plus importants dcouverts en cours de route.

Partie II - Quelle est lefficacit de mon Equipe ?

Mme si vous tes encourag montrer lexemple en collaborant avec les membres de lquipe dans
leur travail, il y a un risque que vous vous perdiez dans les tches techniques. Rflchissez vos
principales responsabilits envers lquipe:

Est-ce que votre quipe est en tat dexprience optimale1 ? Voici quelques signes qui ne
trompent pas :
Des objectifs clairs (les attentes et les rgles sont correctement perues et les objectifs sont
atteignables, aligns avec les comptences et capacits de chacun).
Concentration et ciblage, un haut niveau de concentration sur un primtre limit.
La perte de la conscience de soi, rsultat de la fusion entre l'action et la rflexion.
Des retours directs et immdiats (les succs et les checs sont immdiatement reprs, ainsi
le comportement de l'quipe peut tre ajust en fonction).
Equilibre entre capacit faire et dfi (lactivit nest ni trop facile, ni trop difficile).
Un sentiment de contrle de soi et de lenvironnement.
Lactivit est en soi gratifiante, le travail se fait sans effort.
Est-ce que les membres de lquipe semblent sapprcier, plaisantent entre eux, et ftent les
succs de chacun ?
Est-ce que chaque membre de lquipe se sent responsable dun haut niveau de qualit, et
stimule les autres pour progresser ?
Y a-t-ils des risques/opportunits que lquipe ne discute pas car ses membres ne se sentent pas
l'aise ?
Avez-vous essay diffrentes formes et diffrents lieux pour raliser vos Rtrospectives de
Sprint ?
Lquipe est-elle encore concentre sur les objectifs du Sprint ? Vous pourriez organiser un point
de mi-Sprint pour re-revoir les critres dacceptation des items du backlog de litration.
Le tableau des tches reflte-t-il ce que lquipe fait rellement ? Mfiez-vous de la "matire noire"
des tches caches et des tches suprieures un jour de travail. Les tches qui ne sont pas
lies aux objectifs du Sprint sont des obstacles la ralisation de ces objectifs.

1Aussi nomme exprience du flow, https://fr.wikipedia.org/wiki/Flow_%28psychologie%29

Copyright 2007-2012 Michael James. All Rights Reserved 2

 Votre quipe est-elle compose de 3 9 personnes avec un ventail suffisant de comptences
pour dvelopper un incrment du produit potentiellement livrable ?
Le tableau des tches de votre quipe est-il jour ?
Les outils dautogestion de lquipe (tableau des tches, Sprint Burndown Chart, listes des
obstacles, etc) sont-ils bien visibles, pratiques utiliser pour lquipe ?
Ces outils sont-ils correctement protgs des fouineurs ? Une attention excessive porte sur
lactivit quotidienne de lquipe par des personnes externes peut nuire la transparence interne
et lautogestion.
Les membres de lquipe se portent-ils volontaires pour raliser les tches ?
Le remboursement de la dette technique se traduit-il explicitement sous forme ditems du backlog,
rendant progressivement le code plus agrable maintenir ?
Les membres de lquipe abandonnent-t-ils leur intitul de poste la porte du bureau, prfrant
tre collectivement responsables de tous les types de travaux engags (test, documentation
utilisateur, etc) ?

Partie III - Que valent vos pratiques dingnierie ?

Le systme que vous dveloppez possde-t-il un bouton "Lancer les tests" permettant nimporte
qui (de lquipe ou dune autre quipe) de dtecter simplement sil a caus une rgression (cass
une fonctionnalit qui marchait) ? Gnralement, ceci est ralis en utilisant un framework xUnit
(JUnit, NUnit, etc).
Vos tests automatiss prsentent-ils un juste quilibre entre les tests systmes de bout en bout
(ou "tests fonctionnels") et les tests unitaires ?
Lquipe crit-elle les tests systmes et unitaires dans le mme langage de dveloppement que
celui utilis pour dvelopper le systme ? Les langages de script propritaires et les outils de
capture de transactions que seule une partie de lquipe sait maintenir sont un frein la
collaboration.
Lquipe a-t-elle dcouvert la zone grise mais bien utile situe entre les tests systmes et les tests
unitaires ?
Votre serveur dintgration continue met-il une alarme sonore lorsque quelquun provoque une
rgression ? Le dlai dapparition de cette alarme peut-il tre rduit quelques heures ou
minutes ? ("Les builds de nuit sont pour les mauviettes." Kent Beck)
Tous les tests sont-ils bien inclus dans le rsultat du serveur dintgration continue ?
Les membres de lquipe ont-ils dcouvert les joies de la conception continue et du refactoring
permanent, en remplacement du document de Conception Gnrale et Dtaille ? Le refactoring
a une dfinition stricte : modifier la structure interne du systme sans changer son comportement
externe. Le refactoring doit avoir lieu plusieurs fois par jour, chaque fois quil y a du code
dupliqu, une logique conditionnelle complexe (dtectable par des indentations excessives ou des
mthodes trop longues), des identifiants mal nomms, un couplage excessif entre objets, etc. Le
refactoring se peut se faire en toute confiance que grce aux tests automatiss. Ngliger le
refactoring rend le produit difficile faire voluer, notamment parce quil est difficile de trouver des
bons dveloppeurs qui veulent travailler sur du mauvais code.
La dfinition du "fini" pour les items du backlog intgre-t-elle la couverture complte des tests
automatiss et le refactoring du code ? Apprendre le dveloppement pilot par les tests (TDD)
vous y aidera.

Copyright 2007-2012 Michael James. All Rights Reserved 3

 Lquipe pratique-t-elle la programmation en binme ? La programmation en binme peut
amliorer la maintenabilit du code et rduire fortement le nombre danomalies. Cette
collaboration troite peut gnrer des rticences et sembler parfois moins productive (si on
mesure en nombre de lignes de code plutt que par fonctionnalits livres). Montrez lexemple en
initiant des journes de travail en binme avec les membres de lquipe. Certains dentre eux
commenceront prfrer cette mthode de travail.

Partie IV Quelle est lefficacit de mon Organisation ?

Les quipes communiquent-elles suffisamment entre elles ? Le "Scrum de Scrums" nest quune
faon dy parvenir, et pas forcment la meilleure.
Les quipes peuvent-elles produire de manire autonome des fonctionnalits livrables, qui
ventuellement traversent diffrents blocs de larchitecture du systme.
Vos Scrum Masters se rencontrent-ils pour travailler sur la liste des obstacles ?
Quand cela est ncessaire, les obstacles organisationnels sont-ils placards dans le bureau du
directeur des dveloppements ? Le cot peut-il tre quantifi en dollars, en dlai de livraison, en
perte de qualit, en perte de clients ? (Mais apprenez des erreurs de Ken Schwaber : "Un Scrum
Master mort est un Scrum Master inutile.")
Votre socit est-elle une des rares qui encouragent des volutions de carrires compatibles avec
les objectifs de vos quipes ? Rpondez "non" sil y a des incitations faire de la programmation
ou de larchitecture au dtriment des tests, de lautomatisation des tests ou de la documentation
utilisateur.
Votre socit a-t-elle t reconnue par la presse ou une organisation indpendante comme lune
des meilleures o travailler, ou comme un leader dans votre domaine ?
Travaillez-vous crer une organisation apprenante ?

Conclusion
Si vous pouvez cocher la plupart de ces points et quil vous reste du temps libre dans la journe,
nhsitez pas me contacter.

Il ny a pas de recette toute faite pour susciter le gnie humain. Cette liste peut, ou pas, vous aider
dans votre contexte.

Quand vous commencez raliser que vous pouvez faire la diffrence, vous pouvez avoir peur de le
faire. Cest le signe que vous tes sur la bonne voie.

Copyright 2007-2012 Michael James. All Rights Reserved 4

 FICHE DOBSTACLE ORGANISATIONNEL

PROBLME APPARENT :

CAUSE RACINE (UTILISEZ 5 FOIS POURQUOI ? ) :

CONSQUENCE MTIER :

CONSQUENCE MOTIONNELLE :

DEMANDE CLAIRE ET RALISABLE :

--------------------------------------------------------------------------

FICHE DOBSTACLE ORGANISATIONNEL

PROBLME APPARENT :

CAUSE RACINE (UTILISEZ 5 FOIS POURQUOI ? ) :

CONSQUENCE MTIER :

CONSQUENCE MOTIONNELLE :

DEMANDE CLAIRE ET RALISABLE :

Copyright 2007-2012 Michael James. All Rights Reserved 5

 INSTRUCTIONS

Si vous avez rcupr cette checklist en tant quoutil de formation et que votre
organisation tente de mettre en uvre quelque chose ressemblant Scrum,
appliquez-la ce que vous observez. Cochez chacun des points avec lun des
symboles suivants :
(pour dj fait correctement )
(pour pourrait tre amlior et je sais par o commencer )
? (pour pourrait tre amlior, mais comment ? )
N/A (pour non-applicable ou napporterait pas de bnfice )
Ou, si votre organisation na encore rien tent qui ressemble Scrum, utilisez la
notation suivante :
(pour dj fait correctement ou serait facile faire )
(pour serait un dfi et je sais par o commencer )
? (pour serait un dfi et jignore par o commencer ? )
N/A (pour non-applicable ou napporterait pas de bnfice )
Lorsque que vous avez coch tous les points de la checklist, remplissez 2 6 Fiches
dObstacle Organisationnel, que ces obstacles soient ou non issus de la checklist.
Choisissez des obstacles que vous pourrez surmonter avec au moins 1 % de
chance.

Copyright 2007-2012 Michael James. All Rights Reserved 6