Note : 3 ; De la « soupe au Shu » … Et encore, celle de l’auteur !

J’en suis encore à me demander ce qui m’a pris lorsque j’ai acquis ce bouquin ! Car autant le dire tout de suite : il est très dogmatique. Pire encore, il y bien peu de choses avec lesquelles je sois d’accord. Pour couroner le tout, il ne s’agit pas d’une lecture légère. Voyons cela.

L’ouvrage est fort de 4 sections de longueurs très inégales totalisant 27 chapitres. La première d’entre-elles est introductive et se satisfait de 2 chapitres. Le premier est d’avantage un avant-propos que l’introduction du livre lui-même car il se focalise sur le « pourquoi » du texte. Celui-ci débute réellement au second chapitre qui propose un « tour du propriétaire ». Celui-ci est assez conforme au Scrum guide même si l’on voit poindre en filigrane les interprétations des auteurs. J’aurais l’occasion d’y revenir.

La seconde partie « people » compte 6 chapitres. On débute assez logiquement au chapitre 3 par l’équipe. Les auteurs commettent leur premier coup de canif en évoquant 6 rôles (Business Owner, Stakehold et Subject Matter Expert). C’est un chapitre assez long qui remet au clair nombre de principe mais verrouille aussi tout autant des principes d’articulation entre rôles qui n’ont pas besoin de l’être autant. Le chapitre 4 qui vient se focaliser sur le PO donne le ton dès la première page « le PO priorise le travail de l’équipe et en échange reçoit le blâme pour le résultat ». Autant pour la collaboration ! J’ai trouvé le point de vue quelque peu tordu, voir schizophrène entre un discours sur la collaboration et des directives de fonctionnement induisant des comportements à l’inverse.

A l’inverse, je me suis trouvé plus en harmonie avec le chapitre 5 consacré au Scrum Master, le résumé des missions qui en est fait couvre bien le rôle. Les auteurs introduisent la notion d’Intraspection qui mérite une mention honorable. Les auteurs attribuent un pilier technique au Scrum Master ce que j’approuve. Enfin les « modes du Scrum Master », soit formateur, coach et mentor sont abordés au sein d’un chapitre dédié. Un chapitre qui présente au moins un certain intérêt. A l’inverse le chapitre 7 revient sur ses 3 rôles supplémentaires, cherchant à formaliser des patterns de collaboration : un travail vain et inutile, en contradiction même avec l’esprit de Scrum. Cette section se referme sur un chapitre dédié au « team swarm ». L’idée va dans le bon sens et méritait d’être évoquée, mais encore une fois les auteurs rentrent dans trop de formalisme.

La troisième partie est consacrée au produit, et pas moins de 10 chapitres éclairent ce volet. Le chapitre introductif se focalise bizarrement sur les relations avec le stakeholder se résumant à « ils veulent ce qu’ils veulent ». Oublions vite le processus focalisé sur l’impact. C’est au tour du backlog d’être abordé au chapitre 10. Là encore les auteurs adoptent une opinion tranchée : le backlog est ce que « les parties prenantes veulent » versus « ce qui a besoin d’être fait ». L’optique des auteurs conduit trop souvent hélas à des produits auxquels il manque des aspects opérations. Le cycle de vie des éléments du backlog fait l’objet d’une vue intéressante mais complexe avec des concepts emprunts à la cuisine : « front burner », « back burner », « fridge », etc… avec des phases permettant de passer d’un état à un autre. Tout cela est trop compliqué. L’idée de l’item de backlog apportant de la valeur aux parties prenantes est prise à contrepied au chapitre 11 avec les concepts de « capabilities », justement dédiées aux parties prenantes et de « chore » apportant de la valeur à l’équipe ou au produit (notez le « ou »). Un schisme qui peut finir par se payer cher, d’ailleur les auteurs suggèrent un Yalta 70/30 entre les deux. Il n’y a pas grand-chose avec lesquelles je sois d’accord ici.

Au douzième chapitre il est question de stories. Ou plus exactement de stories et d’épics (les trucs trop gros pour être une story. Jusqu’ici ça va. Cela se gâte quand on commence à évoquer les « infrastructure stories », puis les « analysis stories ». Sans être en totale opposition avec le propos, je n’ai pas trouvé celui-ci particulièrement brillant. Le chapitre 13 aborde la dette technique, ce qui a peu de raccord avec le chapitre précédant. Le propos n’est pas nouveau, et j’avoue être en phase avec les idées abordées. Ouf. Retour au backlog avec le chapitre 14 et le « story agreement ». Je me serais bien contenté d’un propos sur le done, mais il fallait que ce soit plus compliqué. Il faut dire que les différents types de story évoquées rendent cette complexité inéluctable. Mais on se dirige aussi vers un concept de « cleanup story »… Une idée particulièrement efficace pour fabriquer de la dette technique, qui explique sans doute le chapitre précédant. Inutile de dire que je suis en complet désaccord. Incompréhensible aussi pour moi la séparation du « done » de « l’acceptance » ! Vélocité et taille sont au menu du chapitre 15.

Au chapitre 16, il est question de vélocité et d’estimation. Le texte rentre dans un niveau de détail et de formulation très complexe pour une utilité pratique quasi-nulle. L’organisation du backlog abordé au chapitre 17 fait apparaitre 3 nouveaux concepts : tags, thèmes et buckets. Aucun d’entre eux n’est convergent avec les epics évoquées précédemment : que de confusion ! Le chapitre suivant évoque priorisation et grooming. C’est l’un des chapitres que j’ai trouvé le plus pertinent à 2 ou 3 détails près, liés aux concepts complexifiant introduits précédemment. L’auteur emprunte les Storyotype de Gérard Mezzaros au chapitre 19. Encore un élément de complexité, mais intéressant cette fois car ils sont liés à des « done » différents pour chacun d’entre eux. On aurait pu en profiter pour jeter à la benne les autres bidules inutiles.

La dernière section évoque les pratiques. On en prend pour 9 chapitres. Et on commence avec le « planning day ». Vous avez bien lu : une journée entière pour ça, découpée soigneusement en tranches qui occupent même le temps du déjeuner. Il faut dire que l’on y inclus définition de l’objectif, « progress agreement », rétrospective et planning meeting, dans cet ordre. J’ai du mal à reconnaitre Scrum. Le « agreement-based planning » du chapitre suivant détaille avec moult précisions comment l’équipe se met d’accord sur l’objectif. Suivi d’un chapitre sur la manière d’ajuster le contenu du sprint. J’ai du mal à imaginer comment une équipe saurait adapter son processus avec une approche aussi prescriptive. Au 23ème chapitre apparait un concept pour le moins curieux : le placeholder story. En gros il s’agit d’un concept de budgétisation du temps pour les trucs dont on ne sait pas s’ils vont arriver. C’est idiot.

Retour sur les cleanup stories déjà évoquées au chapitre 24. J’ai déjà dit le mal que j’en pensais. Mais juste pour clarifier : qui dit cleanup story, dit acceptation d’un concept de « dirty story » juste avant. Et comme les stories sont priorisées indépendamment… Le chapitre 25 traite du burndown, qui n’est pas mon sujet favori. En tout cas pas le burndown en heure évoqué ici, qui en est la pire variante. Un petit passage par le Kanban eu chapitre 26 : l’auteur reste assez vague sur la manière d’adapter son usine à gaz à cette approche. Les idées gravitant autour du daily Scrum au chapitre 27 m’ont toutes parues pertinentes. C’est donc un autre des chapitres que j’apprécie. L’idée de « l’intraspection » est probablement à conserver. L’ouvrage se termine sur un chapitre consacré aux « autres trucs », tels que le sprint zéro, l’annulation de sprint, le replanning. Seul le « release sprint » qui donne à Scrum des allures de cycle V m’irrite réellement. Même le sprint zéro est traité plutôt intelligemment ici.

L’ouvrage est long, la lecture en est laborieuse, surtout quand comme moi on est en opposition avec tellement d’idées développées ici. Mais ce n’est pas le seul défaut : l’approche ou plutôt la traduction de Scrum est excessivement prédictive, ce qui trahit franchement l’idée d’origine de l’approche. Comment s’approprier et adapter le processus dans ces conditions ? D’ailleurs le volet « rétrospective » n’a droit qu’à deux pages, preuve que pour les auteurs, tout est déjà définitivement décrit dans ces pages. Un livre que je déconseille vivement.

Référence complète : The DevOps Handbook – Exploring Scrum : The fundamentals – Dan Rawsthorne with Doug Shimp – CreateSpace 2011 – ASIN : B0058WS4T4