Note : 8 ; La référence sur Scrum, à la hauteur des ouvrages de Mike Cohn

Le nom de l’auteur ne m’évoquait rien jusqu’à présent. Mais Kenneth Rubin n’est pas seulement un vieux routier de l’informatique et de l’agilité, il fut aussi le premier chairman de la Scrum Alliance ! La motivation de l’auteur était, pour cet ouvrage, de réaliser un texte de référence sur Scrum, que l’on puisse prendre avec soi et qui suffise lorsque l’on se pose une question sur la mise en œuvre de Scrum. Je vais certainement casser le suspens, mais c’est pour moi mission accomplie. En prenant un peu de recul, on peut constater que les points abordés tombent dans 3 catégories.

• Les éléments et pratiques qui font partie du cœur de Scrum. C’est ce que l’on va trouver dans le Scrum Guide, par exemple, ou dans les 3 ouvrages de Ken Schwaber.
• Les pratiques généralement admises dans la mise en œuvre de Scrum, mais qui ne font pas partie du framework officiel. Ce sont par exemples les pratiques empruntées à l’Extreme Programming. A ce titre, c’est ce que nous pourrons rencontrer dans l’excellent « Scrum from the Trenches » de Kniberg ou le livre en Français sur Scrum de Claude Aubry.
• Les pratiques avancées qui peuvent compléter Scrum. Nous pouvons penser au Management 3.0 de Jurgen Appelo ou au Lean Startup…

Ce livre vise à couvrir complètement les deux premiers aspects et une bonne partie du 3ème. C’est un vrai texte pratique qui ne se limite pas à ce que l’on doit faire, mais surtout développe le « comment ». On s’appuie ici sur une prose de bonne qualité (je l’ai comparé à Mike Cohn tout à l’heure), mais aussi sur une abondante illustration. Le tout pèse benoitement ses 400 pages, c’est le prix à payer ! Au niveau du contenu, il faut compter avec 23 chapitres regroupés en 4 parties principales.

Le premier chapitre est une courte introduction sur la raison d’être de Scrum. Un peu ce que l’on retrouve dans « Software in 30 days », mais mieux écrit. C’est expédié en 10 pages.

La première partie regroupe 7 chapitres sur un peu plus de 150 pages et est dédiée aux « core concepts ». On commence très classiquement par un chapitre 2 justement nommé « the Scrum Framework » de 15 pages. Juste Scrum, rien que Scrum. C’est ce que couvre le Scrum Guide, rien à ajouter.

Ce sont aux principes agiles qu’est consacré le chapitre suivant. Par principes on entend : gestion du changement, taille des lots (WIP size) ou coût du délais, le tout comparé aux approches « plan driven ». Un chapitre un peu dense, dont les 30 pages ciblent plutôt le middle management et les décideurs. On reste encore beaucoup dans les principes avec les 17 pages du chapitre 4 consacré aux sprints : à quoi sert le timeboxing, les conséquence d’un changement en cours de sprint, etc. On retrouve un propos plus en phase avec les préoccupations du praticien. « requirements et user stories » qui est le titre du chapitre 5, c’est un bon condensé de ce que l’on trouvera dans l’ouvrage de Mike Cohn sur le sujet. C’est une sorte de MVP des stories pour partir du bon pied. Le chapitre 6 consacré au backlog continue sur cette lancée mais couvre également les cas particuliers de backlogs multi-équipe et autres spécificités. Les 20 pages destinées aux estimations sont aussi un condensé d’Agile Estimating and Planning de Cohn. Mais c’est très bon et suffisant pour démarrer. Le sujet des dettes techniques tient visiblement à cœur pour l’auteur, les 23 pages qui sont dédiées à ce point sont un peu en décalage avec les chapitres précédent. Le sujet est traité sous l’angle économique, qui distribue la nature de cette dette en 4 catégories.

La seconde partie est consacrée aux rôles de scrum, enfin à une couverture un peu plus large que les rôles officiels. On leur dédie 5 chapitres sur un peu moins de 100 pages. Contrairement à moi, l’auteur s’accroche à la séparation des rôles « by the book », avec un chapitre 9 consacré au Product Owner, complet et bien fait, où il est toutefois admis que l’ensemble des compétences demandées ne se retrouvent pas forcément en un seul homme… Le chapitre 10 est logiquement dédié au Scrum Master. Là aussi je diffère de l’auteur qui préfère le SM « professionnel » quite à se qu’il s’occupe de plusieurs équipes. Les 8 pages dédiées au sujet paraissent étrangement peu. L’équipe est traitée au chapitre 11. Il est beaucoup question de polyvalence au long de ces 16 pages, mais aussi de « profil en T » que je vois rarement évoqué. Le modèle a ses limites, à mon avis. Une dizaine de pages sont consacrées à la question du « team structure ». Sceptique sur l’intérêt du sujet de prime abord, j’avoue que l’auteur fait du bon boulot à opposer le « feature team » au « component team » et à évoquer le travail en équipes multiples. Le chapitre 13 qui clot cette partie est dédié au management. On sort un peu de Scrum pour aborder des questions qui sont reprises du Management 3.0 de Jurgen Appelo.

La troisième partie sort en grande partie du « Scrum by the book ». Elle est intitulée « planning » et couvre 5 chapitres sur 90 pages. Le chapitre 14 sert d’introduction et aborde sur 8 pages les principes économiques sous-tendant la manière d’aborder la planification agile. Le chapitre 15 sert de guide au reste de cette 3ème partie en reprenant le « multi-level planing » que Rallye Software évoquait déjà en 2006. Le chapitre 16 embraye donc sur la planification de portefeuille qui sort du cadre projet. Disons que le sujet n’est pas mal abordé sur une vingtaine de pages, bien qu’il lui manque un volet réellement pratique. Le chapitre 17 « envisonning » semble être un sujet qui passionne l’auteur. Il lui dédie même un début d’étude de cas, ce dont on n’a pas eu le droit avant. Et on y évoque aussi le release plan du projet et le « validated learning » du Lean Startup ! Ce sont 25 pages qui sont consacrés au release planning traité au chapitre 18. Je ne suis pas fan du sujet, mais il est fort bien traité en y intégrant plusieurs stratégies de contraintes.

J’aurais préféré voir cette quatrième partie « Sprinting » plus tôt dans l’ouvrage, car c’est quand même le cœur de Scrum ! 11 pages semblent suffire pour couvrir le Sprint planning au chapitre 19. C’est très concret, à la limite de la recette de cuisine, donc réellement exploitable. Le chapitre 20 « sprint execution » n’est pas facile à aborder car il doit traiter de ce qui se passe entre le début et la fin de Sprint. Bien sûr on y évoque le Daily Stand-up, mais aussi la communication dans l’équipe et la manière de se distribuer les tâches. Bon boulot, finalement. Très logiquement le chapitre 21 aborde la démo, pardon le « sprint review » ! Pas trop de blabla sur cette dizaine de pages et l’auteur y aborde aussi des points épineux comme le « rien à montrer » ou la démo de réalisations sous le capot ! Enfin c’est à la rétrospective que se consacre le chapitre 22. Le contenu reprend plus ou moins la trame d’Esther Derby, mais l’auteur consacre un peu plus de développement à la timeline. Pourquoi pas ? C’est mieux que de paraphraser un ouvrage déjà bien connu. Aller plus loin, c’est le thème du chapitre de clôture. C’est un peu mon « Scrum Ri ». Une bonne façon de terminer l’ouvrage.

De mon point de vue, l’objectif est atteint. Ce livre vise le même créneau que l’ouvrage de Claude Aubry : être un livre de référence sur Scrum. Je pense qu’il est un cran au dessus de son équivalent Français déjà fort honorable. Son seul réel défaut est peut-être que sa cible naturelle est constituée d’un public peu enclin à avaler un ouvrage de 400 pages.

Référence complète : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3