Note de lecture : Turn Your Ship Around ! par L. David Marquet

Note : 7 ; Le management intentionnel en action, ou plutôt « en question ».

Ce petit opuscule est ce que l’on appelle parfois un « workbook », pour travailler et compléter à la maison ce que vous avez appris de la lecture de « Turn the Ship Around ». La similitude des titres donnait un indice sur le fait que ce titre venait compléter le précédent.

Le livre compte un total de 180 pages structurées en 29 chapitres très petits. L’ensemble est regroupé en 5 grandes parties. Il ne s’agit pas de 180 pages de texte. En fait il y en a même peu. Il s’agit pour beaucoup d’exercices introspectifs que l’auteur initie à partir de questions bien choisies. La plus grande partie de l’espace est donc en fait occupée par des lignes blanches ! Pour quelques exercices (peu en fait), l’auteur nous convie au visionnage de « Master & Commander » de Peter Weir. C’est sympa et original, l’auteur aurait pu le faire plus.

La première partie « mechanisms for starting over » regroupe 7 chapitres. Elle débute par un chapitre peuplé de questions destinées à identifier nos présupposés sur le leadership et à prendre du recul à ce sujet. C’est l’horizon de pensée et d’action du leadership qui est évoqué au chapitre suivant. La structure de récompenses / bonifications structure souvent celle-ci et l’auteur nous invite à considérer cet horizon comme allant au-delà du moment où l’on quitte l’organisation. « Care but don’t care » considère la manière dont nous aidons notre équipe à grandir tout en les laissant se débrouiller dans leurs tâches. Un point de vue qui me parle particulièrement.

Continuer à lire « Note de lecture : Turn Your Ship Around ! par L. David Marquet »

Note de lecture : Agile Game Development with Scrum, par Clinton Keith

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…

Continuer à lire « Note de lecture : Agile Game Development with Scrum, par Clinton Keith »

Note de lecture : Refactoring to Patterns, par Joshua Kerievsky

Note : 6 ; Un grand sujet, traité avec acuité, mais parfois présenté de façon un peu fastidieuse !

Joshua Kerievsky est donc le premier à avoir franchi le fossé entre le refactoring et les patterns ! Nous devons lui en être reconnaissants. L’intérêt et l’expérience de l’auteur (notamment en tant que créateur du « new York patterns group ») l’ont conduit à aborder les patterns non pas comme des éléments initiaux de conception, mais comme des solutions à des problèmes, donc des éléments de conception émergentes, ce qui nous amène au refactoring ! La conception émergente via les patterns est le thème et l’intérêt central du livre et en font sa valeur.

Le sujet va nous occuper au long des 350 pages découpés en 11 chapitres que forme cet ouvrage. Au chapitre 1, l’auteur nous livre la démarche que l’a conduit à ce texte. En partant tout d’abord des patterns pour obliquer vers le refactoring et le cycle TDD, pour revenir enfin vers les patterns, pour améliorer la conception sans tomber dans l’over engineering. Le second chapitre est consacré au refactoring. Il ne s’agit pas là, en une douzaine de pages, de reprendre le propos de Martin Fowler, mais simplement de se focaliser sur l’intention et l’essence de cette démarche.

L’introduction aux patterns du chapitre 3 n’est ni vraiment utile, ni spécialement éclairante. Le chapitre est court mais assez vague sur la nature des patterns, le propos se concentrant plutôt sur l’histoire personnelle de l’auteur… Les Code Smells du chapitre 4 souffrent moins de ce défaut, Joshua Kerievsky nous gratifie ici des odeurs les plus rependues. Il s’agit plus d’un mini-catalogue que d’une introduction.

Continuer à lire « Note de lecture : Refactoring to Patterns, par Joshua Kerievsky »

Note de lecture : The Professional Product Owner, par Don McGreal & Ralph Jocham

Note : 6 ; Une solide lecture pour le Product Owner, qui ne reste pas figée dans le dogme Scrum mais s’égare parfois un peu.

La Scrum.org s’est impliqué dans l’écriture de son corpus de connaissances et de pratiques. Le présent volume consacre celui dévolu au Product Owners. Comme nous allons le voir, c’est globalement une bonne surprise, même s’il nous embarque dans quelques hors sujets.

Les 320 pages du présent ouvrage sont découpées en seulement 9 chapitres structurés en 3 parties. Nous voilà donc embarqués dans des chapitres plutôt conséquents. La première partie « strategy » couvre 4 chapitres, soit un peu plus de 100 pages. Le premier chapitre est lui consacré à la gestion de produit agile. On y retrouve quelques poncifs habituels tels que le triangle de fer. Plus intéressant sont les propos sur les boucles de valeur et surtout les « roles type » qui offre une vue originale des profils de maturité du product ownership.

La vingtaine de pages du second chapitre va aborder la Vision. Le propos tourne autour de quelques pratiques désormais bien connues : le business model canvas, la product box et l’elevator statement. Le propos est bien ficelé, mais les habitués n’y découvriront pas grand-chose. Arrive le chapitre 3 et un sujet tout à fait épineux : la valeur ! Les auteurs lui accordent un peu moins de 40 pages. Les auteurs ont quelque peu du mal à trouver un angle, aussi commence-t-on avec « l’évidence-based management », ce qui a au moins le mérité d’introduire le sujet pour évoquer ensuite la satisfaction des employés et des utilisateurs (avec l’inévitable NPS). Après cela, ça part un peu n’importe comment en parlant budget, taux d’innovation, etc. Un chapitre qui n’est pas mémorable, sur un thème particulièrement difficile.

Continuer à lire « Note de lecture : The Professional Product Owner, par Don McGreal & Ralph Jocham »

Note de lecture : Enterprise Integration Patterns, par Gregor Hohpe & al

Note : 8 ; Un très grand classique !

Cet ouvrage s’inscrit dans la continuité du « Patterns for Enterprise Applications » de Martin Fowler. Plus exactement, il traite de l’intégration d’application asynchrones par le biais de messages. Cette imposante référence regroupe 65 patterns, décrits au long des 650 pages de cette imposante référence. L’ensemble est découpé en seulement 14 chapitres.

Le premier chapitre est déjà conséquent avec près de 40 pages. Les auteurs y construisent un exemple d’intégration d’application fictif allant jusqu’au monitoring et montrant comment et pourquoi chaque pattern y prend place. Cela me rappelle quelque peu le premier chapitre de l’Enterprise Applications Patterns de Martin Fowler. Par contraste, le second chapitre est bien plus succinct avec ses 17 pages. Il s’agit ici de patterns stratégiques décrivant les différents styles d’intégration : transfert de fichiers, base de données partagée, échanges de messages, appels de procédures distantes, etc.

Le chapitre 3 s’attache à zoomer sur un seul des styles d’intégration décrit précédemment : l’échange de messages. Les patterns figurant ici décrivent les différents composants de cette structure : messages, endpoints, chanel, routeurs, transformateurs, etc. Nouveau coup de zoom au chapitre 4, sur un des composants de l’échange de messages : les canaux. Ce chapitre nous fait découvrir les différents types de canaux de manière exhaustive : point à point, publish and subsribe, bridge, etc. C’est l’occasion de découvrir certains patterns beaucoup moins connus que les grands classiques. Je pense, par exemple au Datatype chanel ou au Dead-letter chanel.

Continuer à lire « Note de lecture : Enterprise Integration Patterns, par Gregor Hohpe & al »

Note de lecture : The Inmates are Running the Asylum, par Alan Cooper

Note : 7 ; Thumbs up sur le goal-directed design, thumbs down sur le processus.

Il s’agit là du livre de référence sur les Persona. Mais en fait l’ouvrage couvre bien plus largement la question de la place du design dans la conception des produits. Un propos qu’il faudra relativiser avec son écriture au début des années 2000 et même de la findes années 90, car il s’agit en fait d’une édition révisée.

C’est certainement moins vrai aujourd’hui, grâce en partie à cet ouvrage. Le père du Visual Basic nous gratifie ici d’un ouvrage de près de 250 pages découpé en 14 chapitres. Le nombre apparemment élevé de chapitres est bienvenu car il s’agit presqu’uniquement de prose ! L’ensemble est structuré en 5 parties. La première, intitulée « computer obliteracy » couvre 40 pages avec 2 chapitres. Le premier « riddles for the information age » nous propose de regarder les objets qui nous entourent pour constater à quel point l’électronique les a envahis … et à quel point notre expérience avec ces objets s’est dégradée. La phrase clé du chapitre est : quand vous croisez un objet (quel qu’il soit) avec un ordinateur, le résultat est un ordinateur ! Au second chapitre, il est question d’apologistes, de survivants et d’ours qui dansent. L’interaction avec les logiciels s’apparentent aux ours qui dansent : on s’émerveille de ce qu’ils font, mais tout bien considéré, en fait un ours ça danse terriblement mal ! Les apologistes sont les développeurs : ils imaginent que parce qu’ils sont capables de d’utiliser un ordinateur à la geek, les utilisateurs le seront ! Ces derniers s’apparentent souvent à des survivants : Bien qu’ils soient tourmentés par un système qui se comporte pour eux en dépit du bon sens, ils se conforment pour pouvoir faire leur boulot. Les deux chapitres sont de purs régals.

La 2ème partie « i twill cost you big time » regroupe 3 chapitres sur 40 pages. Le chapitre 3 « wasting money » couvre 17 d’entre elles. On y comprend que l’agilité, ce n’est pas son truc à Alan Cooper. Exhortant des « shipping late doesn’t hurt » ou les coût des prototypes, il nous invite à prendre le temps de faire des études amont bien détaillées… Le chapitre 4 signe le retour de l’ours dansant. L’auteur évoque le coût de la non qualité des logiciels : installation fastidieuse, incapable de mémoriser les habitudes de l’utilisateur ou simplement inflexibles et paresseux. Un coût qui se chiffre en perte de loyauté, comme il est évoqué au chapitre 5. Si Apple a su se rendre désirable au point que la loyauté de ses clients soit à tout épreuve, seule la position dominante de Microsoft lui a permis de contrer le manque de désirabilité de ses produits. Un atout que n’avait pas Novell et qui lui a coûté la vie alors que l’entreprise se pensait invincible.

La troisième partie prétend nous montrer comment manger de la soupe avec une fourchette. Elle compte 3 chapitres sur une quarantaine de pages. Le chapitre 6, éponyme du livre nous compte combien les ordinateurs sont différents des humains (sauf les programmeurs qui tendent à converger vers les ordinateurs) et que malgré tout on s’attend qu’ils leur ressemblent ce qui est la recette pour des catastrophes. Le développeur, parlons-en ! L’auteur l’appelle « homo logicus » qu’il oppose à « homos sapiens ». Dans ce chapitre 7, Alan Cooper évoque tout ce qui différencie ces deux espèces. De geeks oppressés par les brutes au lycée, ils sont devenus les brutes oppresseurs de leurs anciens bourreaux… C’est bien sévère ! Le chapitre 8 fera mal à certains, car il appelle la culture de la programmation, une « culture obsolète », isolationniste centrée sur les souhaits de l’ingénierie et non sur les besoins de l’utilisateurs.

Continuer à lire « Note de lecture : The Inmates are Running the Asylum, par Alan Cooper »

Note de lecture : Clean Agile, par Robert C. Martin

Note : 7 ; Un « back to basics » très bien écrit et malheureusement aujourd’hui nécessaire… mais par moments trop empreint de dogmatisme XP !

Quand on ouvre un livre de Robert Martin, on est presque toujours sûr de passer un bon moment. C’est bien le cas ici, et c’est sans doute pourquoi j’ai avalé ce court opuscule en à peine 2 jours. Le sous-titre « back to basic » traduit bien la volonté de l’auteur, revenir aux sources de ce qu’est l’agilité, de pourquoi et comment la met-on en œuvre. Le retour aux sources, c’est le retour à la véritable agilité, et pour l’auteur ce ne peut être rien d’autre que Extreme Programming. Nous verrons que cela induit quand même quelques biais qui peuvent aller de légèrement irritant à franchement embarrassant.

Place au texte ! Comme énoncé, c’est une lecture fort digeste : 185 pages réparties sur 8 chapitres. C’est d’histoire dont nous parle Robert Martin dans ce premier chapitre. L’histoire telle qu’il la connait et qu’il l’a vécue. Cela couvre des éléments bien antérieurs aux années 89/90, que les non-férus d’histoire découvriront, et bien sûr l’écriture du manifeste à Snowbird. Un régal. Le chapitre se termine sur le « circle of life » d’extreme programming, car pour l’auteur agile est synonyme d’extreme programming, et en fait rien d’autre.

Le chapitre 2 couvre les raisons de faire de l’agile (oui, j’ai dit « faire »). Le chapitre incarne assez bien l’aspect « retour aux bases » avec un éclairage résolument XP et ingénierie du développement. Ce n’est pas vraiment une découverte bien sûr, ni une redécouverte pour moi, mais il pourra éclairer des nouveaux venus qui n’ont que le prisme facilitation en tête. Le plus curieux dans le chapitre 3 est le titre « business practices » qui pour moi correspond peu au contenu (pour ne pas dire pas du tout). Peut-être que selon le prisme XP, le business est tout ce qui n’est pas strictement l’ingénierie de développement ? On y aborde de manière conséquente les estimations et la vélocité ce qui, même si c’est bien et clairement abordé est tout à fait ennuyeux. La fin du chapitre sur les tests et la QA parvient tout de même à me sortir de ma torpeur.

Continuer à lire « Note de lecture : Clean Agile, par Robert C. Martin »

Note de lecture : Coacher une équipe agile, par Véronique Messager

Note : 7 ; Une boite à outil plutôt qu’un cadre de coaching

Faire une note de lecture d’un livre dont j’ai été l’un des relecteurs principaux n’est pas une tâche facile. De plus, j’avoue n’avoir que peu goûté les ouvrages que j’ai pu croiser sur le coaching agile. Peut-être bien est-ce au fond un manqué d’intérêt de ma part sur ce sujet ? Voyons ce qu’il en est.

Tout d’abord l’ouvrage : avec 273 pages découpés en 21 chapitres plus une conclusion il est de taille moyenne. Moi qui apprécie les chapitres de taille raisonnable, je serais plutôt satisfait, toutefois il y a une forte disparité de longueur des différents chapitres, mais rien de bien gênant.

Enfin, il faudra noter le découpage en 5 parties qui reflète une progression dans la démarche de coaching.
La première partie campe le contexte. Il faut compter 3 chapitres sur 40 pages pour cela. Si le premier d’ntre-eux parle d’agilité, ce sont bien les « comportements attendus » figurant en dernière page qui constituent le point dominant du propos. Le second chapitre forme un contrepoint mettant en relief au travers d’exemples fictifs mais inspirés de la réalité, la différence entre ce qui devrait être un acquis et l’observation du terrain. Le contraste est saisissant. L’explication arrive au 3ème chapitre avec, entre autres, l’homéostasie et le poids de nos émotions que l’auteur compare à un GPS interne.

Continuer à lire « Note de lecture : Coacher une équipe agile, par Véronique Messager »

Note de lecture : SAFe 4.5 Distilled, par Richard Knaster & Dean Leffingwell

Note 4 ; Un tour d’horizon à haute altitude bien écrit, mais manquant de consistance, de SAFe l’ERP de l’agilité.

SAFe est réellement le raz de marée de la seconde moitié des années 2010. Il serait vain de l’ignorer. Avec quand même un certain bagage sur le framework, j’aborde ce livre dans le but de mieux appréhender comment l’ensemble des briques s’articulent. Un objectif qui, nous le verrons, est malheureusement loin d’être atteint.

C’est un livre de taille moyen, avec ses 300 pages environ, qui surprend par son poids quand on le prend en main. Et pour cause : il est imprimé sur papier glacé, et même imprimé totalement en quadrichromie ! Un peu comme une plaquette publicitaire, ce qu’il est en partie. Le contenu est divisé en 6 parties et ne compte pas moins de 22 chapitres. La première partie nous invite à une vue générale, sur 25 pages comptant deux chapitres. Le premier est à peine un tour de chauffe, avec le « business case » de SAFe mâtiné de perspectives historiques. C’est bien écrit, mais on n’y apprend rien. C’est un peu plus concret au chapitre 2 qui nous explique clairement les différentes déclinaisons de SAFe et les rôles utiles. C’est une introduction comme il faut.

La seconde partie dédiée au mindset et principes compte 3 chapitres et couvre une cinquantaine de pages. On commence au chapitre 3 par parler mindset avec le manifeste agile et avec la « SAFe House of Lean », un peu librement adapté de l’original. A part cette nouveauté, la seule originalité est la déclinaison du manifeste à l’échelle, tout à fait sensée. Les principes SAFe sont détaillés au chapitre 4. Franchement ils sont bien et sont clairement évoqués. D’inspiration très largement Lean, j’ai quand même un peu de mal à les raccorder à ce que j’ai compris du framework. J’ai hâte d’en savoir plus. J’adhère aussi au propos sur le « Lean-Agile leader ». Du focus sur le développement des personnes au recrutement ciblé sur les soft-skills, nous sommes clairement dans la bonne direction !

Continuer à lire « Note de lecture : SAFe 4.5 Distilled, par Richard Knaster & Dean Leffingwell »

Note de lecture : L’art subtil de s’en foutre, par Mark Manson

Note : 6 ; Ou comment assumer que l’on n’est pas extraordinaire !

L’auteur déteste les programmes et les livres de développement personnels, est-ce peut-être pour cela qu’il en a écrit un ? Mais celui-ci se veut à contre-courant, bien sûr. Toutefois, comme nous le verrons, le titre est assez trompeur.

Le livre est relativement court, avec 186 pages sur 9 chapitres. La lecture en français facilite probablement les choses car je soupçonne que le style de l’auteur ne soit pas d’un abord facile par rapport à mes lectures habituelles…

Le premier chapitre « don’t try » fait hommage à l’épitaphe de Charles Bukowski. Il ne s’agit pas de se foutre de tout, mais de choisir ce à quoi on va accorder de l’importance, à des choses qui comptent vraiment et non à des préoccupations superficielles qui deviennent anxiogènes. Ainsi assumer de ne pas être dans la normalité, c’est cela « s’en foutre ».

Continuer à lire « Note de lecture : L’art subtil de s’en foutre, par Mark Manson »