Note : 6 ; De nouvelles idées et de nombreux remaniement pour un texte qui continue (hélas) de privilégier les saisons aux itérations courtes et les fonctionnalités regroupant les user stories.
Les éditions du livre de Claude Aubry se suivent et incarnent pour moi le changement dans la continuité. Nous en sommes déjà à la 5ème édition. Je les ai toutes lues, chacune d’entre-elle du début à fin et non pas en diagonale. Car l’auteur se fait un point d’honneur à faire véritablement évoluer son texte à chaque édition et ne se contente pas d’un simple changement cosmétique.
Le livre reste sur une structure de 22 chapitres, mais fait un bond de 294 à 343 pages ! Le premier chapitre compte une quinzaine de pages (contre 14 précédemment). Il fait toujours un bon boulot (en léger progrès même) pour situer Scrum et le mouvement agile. Quelques changements non anodins aujourd’hui, dont l’évocation de la systémique. Le second chapitre traite des sprints et prends 5 pages d’embonpoint. Et l’auteur d’évoquer des « saisons » en lieu et place des releases, en ajoutant des notions de prélude et d’interlude. Tout ceci prend des odeurs de SAFE, et ce ne sont pas de bonnes odeurs pour moi.
Place au chapitre 3 qui a changé de titre et parle de « sublimer l’équipe ». Pas mal de bonnes choses dans ce chapitre qui a pris aussi quelques pages au passage, avec l’ évocation de « The People’s Scrum » et l’heureuse disparition à la référence « Exploring Scrum », mais je trouve la métaphore de la permaculture compliquée et peu convaincante. Des remaniements également au chapitre 4 sur ce chapitre consacré au Product Owner, qui n’était pas mauvais et le reste. Par contre, l’évocation de la permaculture, ce n’est toujours pas ça.
Cette fois encore, c’est le volet permaculture qui donne un peu plus d’embonpoint au chapitre 5 dédié au Scrum Master. A part cela pas d’évolution majeure par rapport à l’édition précédente. Cette fois encore, j’invite Claude à la lecture du « Scrum Mastery » pour faire monter cette partie d’un cran. J’ai trouvé le chapitre 6 plus agréable à lire que dans l’édition précédente, bien qu’il n’ait pas changé fondamentalement. Les typologies de stories inspirées de Philippe Kruchten, introduites à la 4ème édition sont toujours là. Je les avais trouvées inutilement lourdes au moment, c’est toujours le cas. Ce chapitre est complété d’un chapitre 7 dédié à l’affinage du backlog. Le point de différence essentiel est l’introduction des tests BDD à ce niveau-là, ce qui me fait plaisir.
Le chapitre 8 est consacré à la définition de fini. L’apport majeur est la structuration en 3 volets : fonctionnement, qualité interne et qualité externe. J’aime bien. Je maintiens cependant mon reproche de l’édition précédente : il faut décaler les définitions au moins d’un cran vers le bas : le fini de la mise en service ou même de la saison ressemblent à du cycle en V, alors qu’il manque le fini de la tâche ou même du commit ! J’ai par contre peu de choses à dire sur la planification de sprint, objet du chapitre 9, qui a évolué dans sa forme, mais peu dans le fond.
Peu de choses également à dire du chapitre 10 sur le stand-up. Il a droit au même lifting, et le texte de la 4ème édition faisait déjà bien le boulot. Le chapitre 11 amplifie un peu les concepts de revue interne et externe qui n’éveillaient pas spécialement mon intérêt précédemment, ainsi que la séparation des travaux techniques qui ne soulève pas mon enthousiasme. La rétrospective, sujet du chapitre 12, a droit à deux exemples issus de l’expérience de l’auteur (étoile de mer et rétrochataigne), mais guère de nouveautés sur le fond. Le texte est correct, mais je pense que l’on peut demander mieux à l’auteur.
Le chapitre 13 est une nouveauté : il parle du sprint zéro (ou du « prélude », comme l’appelle l’auteur). Je ne suis un févervent du sprint zéro, mais le propos de l’auteur tient la route. J’achète. Nous retrouvons le plan initial avec le chapitre 14 où l’on parle de contextualiser Scrum. Le chapitre n’a guère bougé et on y liste bien les éléments de contexte qui influent (géographie, culture d’entreprise) mais sans se mouiller beaucoup au-delà de quelques généralités. Toutefois, nombre d’auteurs ne font même pas cet effort. C’est d’élaborer le backlog initial dont il est question au chapitre 15. Un chapitre qui regroupe 2 chapitres de l’édition précédente, l’un sur le story mapping, l’autre sur l’impact mapping. Le propos est moins développé, ce que certains pourront regretter. Mais je trouve que c’est un choix judicieux, recentrant le texte d’avantage sur le cœur de Scrum. L’auteur suggère implicitement de se diriger vers des lectures complémentaires.
L’auteur ne parle plus de release, donc ce chapitre 16 s’intitule-t-il « planifier à moyen terme ». C’est le focus de l’auteur qui m’ennuie le plus. Je trouve peu de qualité agile à cette vision qui de surcroit ramène la discussion sur l’estimation. De l’objectif, on revient aux vieux démons du périmètre. Le chapitre 17 consacré aux outils évolue aussi peu, si ce n’est sur la forme. Il n’est pas si mal, mais peut-être est-il temps de le faire évoluer ? Dans la continuité, le chapitre 18 parle indicateurs. Lui non plus n’a guère bougé : il y est question de burndowns et burnups et de vélocité, principalement. L’auteur nous assène aussi que la valeur n’a pas de sens sous la release et qu’elle est de toute manière difficile à estimer. Disons que nous avons une marge de progrès ici.
Je retrouve aussi les mêmes choses qu’avant au chapitre 19 sur les pratiques d’ingénierie. Je ne saurais contredire l’auteur, je trouve maintenant qu’un chapitre succinct c’est bien trop peu vu l’importance croissante du CI/CD et du devops en général. Le livre accuse ici son âge. Nous retrouvons dans cette édition le même matériel sur l’application de Kanban que précédemment. Et comme précédemment ma remarque sera : mais pourquoi diable focaliser sur les features une pratique dédiée au flux… Légères évolutions du chapitre 21 consacré à Scrum à l’échelle. Sans céder aux sirènes de SAFe, on perçoit quelques inspirations et la toujours aussi confuse métaphore de la permaculture. Le livre se referme sur un chapitre 22 consacré à l’évolution de la culture agile, surtout centré sur l’Agile Fluency. La référence est bonne, et le propos ni bon ni mauvais.
J’accusais l’édition précédente d’être surannée, en ignorant la tendance et les pratiques permettant de ramener notre focus (validation, déploiement) sur de plus petits morceaux, notamment avec l’émergence des pratiques devops comme le « trunk based » ou le « deployment pipeline ». Le texte reste toujours aussi sourd à ces tendances et reste très ancré sur les gros morceaux (saisons et features). Encore un peu d’entêtement dans ce sens et l’ouvrage sera devenu obsolète. Ce serait dommage, car il recèle un très bon matériel et est fort bien écrit et illustré.
Référence complète : Scrum, pour une pratique vivante de l’agilité, 5ème édition – Claude Aubry – Dunod 2018 – ISBN : 978 2 10 077923 9
Christophe, tes remarques, comme la grande majorité des feedback, sont enrichissantes. En tous cas je l’imagine pour Claude. Un feedback, si je peux me permettre, tu sembles penser que tous les lecteurs sont comme toi. Peut-être est-ce un parti pris ? Ce qui te nourrit ne nourrit pas forcément d’autres et vice-verca ?
J’aimeJ’aime
Je reporte ici ma réponse faite sur LinkedIn
Tu peux te permettre, Pablo 😉 J’ai fait le choix depuis que j’écris mes notes de lecture d’avoir un point de vue totalement subjectif (donc le mien). Oui clairement mes remarques dénotes l’écart entre mes idées, mes réflexions et ce que je lis. Parfois je trouve des livres ennuyeux tandis que d’autres les trouveront passionnants…
Au lecteur de se caler par rapport à mes notes. Et « se caler » ne veut pas dire se conformer ! Certains de mes collègues sont en complet désaccord avec moi sur certains sujets, et c’est cool. Pour d’autres, je suis même une boussole qui indique le sud.
Je ne doute pas que beaucoup aient cessé de lire mes notes parce qu’ils ne s’y retrouvent pas. D’ailleurs je ne les publie pas pour faire un concours de popularité. Pendant 14 ans je les ai écrites sans les publier (le stock réel dépasse les 800 notes)… Essayer une forme ou une autre d’objectivité pour tenter de faire plaisir serait probablement malhonnête.
Dernière chose: la note a trait à l’ouvrage, pas à l’auteur. Et ça marche dans les deux sens. Il m’est arrivé de donner de bonnes, voir d’excellentes notes à des ouvrages d’auteurs dont la rencontre m’a laissé de mauvais souvenirs, pour faire dans l’euphémisme.
Je confirme donc : ce qui me nourrit ne nourrit pas forcément d’autres. Peut-être même une minorité, je n’en rien. Je ne peux préjuger de ce que les autres viennent chercher ou ont besoin. Ce serait particulièrement arrogant. Je crains que ce ne soit au lecteur d’en prendre conscience et de mesurer si mes avis peuvent l’aider. Je ne suis heureusement pas le seul à publier des revues de livres. J’engage le lecteur à trouver une boussole qui lui correspond. Ou à utiliser plusieurs boussoles !
J’aimeJ’aime