Note : 4 ; La promesse d’un accompagnement pour démarrer, mais au final des conseils biaisés et parfois critiquables sur la mise en place de Scrum !

Un livre pour vous accompagner durant votre première année de Scrum, telle est la promesse de Mitch Lacey ! Le livre est bien écrit, et l’auteur sait puiser dans une large connaissance de ses sujets. Chaque chapitre est construit de la même façon : d’abord une histoire, puis « le modèle » et enfin les clés du succès pour conclure. Dommage de ne pas avoir tenté de construire un fil rouge avec l’histoire, car c’est un contexte différent que l’auteur nous propose à chaque fois.

En lui-même, le livre n’est pas une lecture légère ; 350 pages découpées en 30 chapitres sous 4 parties. Rajoutez à cela 10 pages d’annexes pour décrire le framework Scrum. Les 18 pages du 1er chapitre sont en dehors des 4 parties. Il sert à introduire Scrum et fait plutôt bien son boulot. Notons que l’on y parle des valeurs et pratiques Scrum (à distinguer de celles du manifeste).

La première partie elle-même est constituée de 7 chapitres sur 95 pages. La douzaine de pages du second chapitre évoque l’embarquement des personnes sur le projet, la vision, le sentiment d’urgence, tout ça. J’ai trouvé cela bien peu convainquant. Au long des 15 pages du chapitre 3, l’auteur développe un modèle bien à lui, celui du « team consultant ». On s’écarte assez notablement de la Vision Scrum ici. Et pour des nouveaux venus, elle est facile à interpréter incorrectement, avec le mise en place de baronnies au sein de l’organisation ! 15 pages également sont dédiées à la gestion de la vélocité au chapitre 4. Pourquoi traiter ce sujet dès maintenant ? Mystère. Toute la logique du plan est en fait un peu mystérieuse pour moi. Rien de transcendant dans ce chapitre 4, par ailleurs. Mais les rôles de Scrum eux méritent bien d’être traités tôt. Mais on n’en dit presque rien ! Seules 9 pages leurs sont dédiées au chapitre 5. Décidément les priorités et les importances des sujets sont troublantes. On passe un peu plus de temps (mais à peine) sur la détermination de la longueur des itérations, où l’auteur nous propose une impressionnante « scoring key », à mon avis complètement inutile. Dans le même ordre d’idées, 8 pages à propos de la définition de terminé… bof, pas grave, n’est-ce pas ? Le chapitre se termine par un sujet qui tient à cœur à l’auteur : le « full time Scrum Master », sur lequel je suis en complète opposition !

La seconde partie « field basics » occupe 85 pages sur 8 chapitres. 14 pages sont consacrées aux pratiques d’ingénierie, je n’ai rien à y redire, pas plus que je ne saurais critiquer l’auteur de commencer par cela. Le « core hours » du chapitre 10 est un sujet plus original, bien qu’il n’occupe que 7 pages. Trouver la période de travail commune d’une équipe ne me semble pas nécessiter le chapitre d’un livre, cela dit. Le release planning est sans doute plus utile, même si je regarde la pratique classique aujourd’hui avec recul (disons…). 13 pages pour cela ici, on préfèrera le propos plus solide de « essential Scrum ». Nous avons également droit à une dizaine de pages sur le découpage des stories en tâches. Je trouve la décomposition hiérarchique des stories un peu bizarre, du moins telle qu’elle est présentée. Sinon, il y a peu à dire. Un très court chapitre de 5 pages est dédié à la gestion des défauts (chapitre 13), j’avoue ne pas avoir compris où l’auteur voulait en venir… Vient ensuite un chapitre consacré sur 8 pages au « sustained engineering », en principe relatif au legacy code et d’inspiration Michael Feathers. S’il est considéré comme important dans Scrum, le Sprint Review n’a droit qu’à 8 pages ici, mais au moins l’essentiel y est dit ! 8 pages, c’est aussi la taille du dernier chapitre de cette partie sur les rétrospectives et qui fait surtout référence à Esther Derby et Norman Kerth.

Les 6 chapitres couvrant 60 pages de cette 3ème partie constituent l’originalité du livre : la trousse de secours ! On commence au chapitre 17 par 10 pages consacrées à des stand-up productifs. C’est le prétexte à introduire le « deep dive », un machin que je n’ai toujours pas compris ! Le chapitre 18 fait 4 pages, il aurait pu être fusionné avec le précédent, car il s’agit simplement d’introduire une 4ème question au Stand-up. Une affaire de goût. Le chapitre 19 long de 9 pages concerne le pair programming. Ce n’est pas le plus inintéressant du livre. Un peu bateau le chapitre 20, qui en quelques pages permet à l’auteur de montrer qu’il connaît le modèle de Tuckman. Mais tout ça est bien abstrait. Le chapitre 21 est plus conséquent avec 13 pages et a trait aux « collisions de cultures ». Intéressant. Enfin le dernier chapitre de cette partie a trait à l’arrêt d’urgence du sprint. Un procédure dont je doute, et dont je doute que l’auteur l’ait appliquée.

La 4ème partie compte 8 chapitres et une centaines de pages. On parle ici de techniques de survie avancées, rien que ça ! La dizaine de pages du chapitre 23 est consacrée au rythme soutenable, l’auteur s’appuie sur le monitoring du burndown et évoque les principes de Tom De Marco en provenance de Slack. Les 10 pages du chapitre 24 se focalisent sur le MMF (Minimal Marketable Feature), enfin un sujet d’intérêt réel ! Ce sont 8 pages qui sont consacrées au sujet de l’analyse de la valeur, au chapitre 25. Autant dire que l’on en ressort frustré ! J’imagine que la dizaine de pages du chapitre 26 consacrées à l’analyse du coût du projet sont là pour lui faire le pendant ? Je l’imagine seulement car il m’est difficile de comprendre le but du propos… Les 11 pages du chapitre 27 consacrées à la documentation sont plus satisfaisante, avec une bonne analyse comparative du mode traditionnel. Suivent une douzaine de pages consacrées à l’offshore qui pourraient se résumer comme suit : ne le faites pas ! Au chapitre 29, l’auteur nous propose une méthode pour gérer de gros backlogs. En quelque sorte, une méthode alternative au Story Mapping. Bof. On termine l’ouvrage par un chapitre consacré aux contrats, un sujet que l’auteur connaît apparemment bien. Sans nous fournir de solutions toute faites, on peut y glaner quelques idées.

Le fil du livre est un peu décousu, et à mon avis il n’adresse pas la cible qu’il s’est fixé. Il aurait été plus juste de le sous-titrer « ce que j’ai envie de dire sur Scrum ». La qualité du propos est assez inégale, mais il est juste de dire que certains des chapitres valent le détour. Mais c’est trop peu pour que je puisse le conseiller. Surtout aujourd’hui, maintenant que de très bons ouvrages existent sur le sujet !

Référence complète : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4