Note : 5 ; Un texte honnête, finalement peu spécifique au domaine du jeu, mais qui accuse un peu son âge.

Pour une « simple » déclinaison de Scrum à l’univers du jeux, l’addition est un peu sévère avec ses 325 pages. Quand on regarde la date de publication, on voit qu’il date d’une époque où le sujet n’avait pas encore envahis chaque recoin de notre bibliothèque. Fort logiquement il reprend un certain nombre de basiques. Je pensais rentrer dans un univers très différent, mais c’est finalement peu le cas comme nous le verrons.

Le livre comprend 5 parties, pour un total de 16 chapitres. Belle bête, donc. La 1ère partie maigre d’une trentaine de pages sur deux chapitres est un avant-propos, au domaine du jeu et au développement agile. Le domaine du jeu est traité dans le chapitre introductif. L’auteur y aborde efficacement la course à l’armement des studios de développements conduisant à une crise du logiciel spécifique de ce secteur. La vingtaine de pages du second chapitre serait classique si l’auteur n’y avait introduit quelques concepts spécifiques du domaine du jeu : phases de pré-production / post-production et recherche du « fun », par exemple.

La seconde partie, avec ses 90 pages et ses 4 chapitres est plutôt indépendante du domaine concerné. Le chapitre 3 s’intitule sobrement « Scrum ». On y trouve sur ses 22 pages ce qu’on peut s’attendre à y trouver. Seuls les exemples sont empruntés au monde du jeu. La prose est bien écrite, avec quand même certains partis pris. Le déroulement du Sprint est au menu du chapitre 4. Là non plus nous ne trouverons une prose se démarquant réellement des grands classiques. Nous arrivons ainsi au chapitre 5 évoquant les user stories. Pas non plus beaucoup d’originalité ici également. On évoque longuement le « INVEST » comme à l’accoutumée. Plus original, le découpage hiérarchique des stories me laisse toutefois un peu perplexe. Enfin, l’agile planning n’est probablement pas mon sujet préféré, mais je dois avouer que le chapitre 6 qui lui est consacré est de bonne teneur. Il me rappelle quelque peu « agile estimating and planning » de Mike Cohn. C’est dire…

Lire la suite →

Note : 5 ; Les savoir-être du « Scrum Master Way ».

Le format de ce petit livre consacré au scrum mastering me rappelle celui de Roman Pitcher dédié au Product Owner. Je n’avais pas aimé ce dernier. Celui-ci n’est pas grandiose mais il aborde tout de même mieux le sujet. Il n’est pas question de parler de Scrum ici, le sujet est considéré comme acquis et c’est très bien.

Je l’ai dit, il s’agit d’un petit livre. Plus précisément d’un moyen format qui accuse tout juste 130 pages pour un total de 8 chapitres. Le tout abondement illustré de sketchnotting que nous devons à l’auteur. Le premier chapitre compte une quinzaine de pages et se focalise sur les basiques : rôles et responsabilités. Un focus important est donné sur sa responsabilité concernant l’auto-organisation de l’équipe. Ce chapitre expose aussi avec clairvoyance les conséquences de combiner ce rôle avec un autre rôle au sein de l’équipe. Clairement Zuzana est une adepte du Scrum Master « full time » quitte à ce qu’il s’occupe de plusieurs équipes.

Le second chapitre s’articule autour du modèle d’état d’esprit du Scrum Master qui compte 5 volets. Professeur et mentor mettent l’accent sur la posture haute pour aider l’équipe à progresser en lui apprenant des pratiques agiles. L’importance de cette posture diminue avec le temps. Supprimer les blocages est un rôle actif au sein de l’équipe pour lui permettre de progresser sans perturbations. Coach et facilitateurs sont deux postures distinctes mais qui caractérisent la posture basse du Scrum Master, tandis que l’observation est le 5ème pilier qui permet à celui-ci de déterminer la posture qu’il doit adopter.

Lire la suite →

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.

Lire la suite →

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.

Lire la suite →

Note : 6 ; Le texte progresse, mais pas assez et surtout pas assez dans la bonne direction pour moi !

Mon principe de base est simple : pour une nouvelle édition, si le texte ne progresse pas, la note baisse ! Pourtant du changement, il y en a et oui, j’ai fait baisser la note. Que s’est-il passé ?

Le volume de l’ouvrage n’a guère changé : 294 pages contre 291 pour l’édition précédente. Mais le découpage est passé de 20 à 22 chapitres, ce qui augure de l’ampleur des changements.

Le premier chapitre est passé de 10 à 14 pages avec un contenu complètement revu en bien, il fait d’ailleurs référence à ma présentation « Scrum Shu Ha Ri » et est moins méthodologique que dans l’édition précédente. Même taille pour le chapitre 2, mais lui aussi profondément remanié. Le concept de Sprint est mieux abordé mais il n’y a guère de différence sur le fond. Notamment, il y a ce concept de release dont je pense qu’il serait temps de le laisser tomber. Nous y reviendrons.

Lire la suite →