Note de lecture : The Agile Leader, par Zuzana Sochova

Note : 3 ; Beaucoup d’éléments d’intention, mais pas grand-chose pour aider ni même faire comprendre ce qu’est un leader agile…

C’est le second livre en langue anglaise de cette auteure en langue anglaise qui nous a gratifié d’un premier volume sur le Scrum Mastering. Le parcours professionnel de Zuzana Sochova mérite le respect, non seulement sur ses accomplissements au sein de la Scrum Alliance que dans ses expériences. L’avant-goût est prometteur. Comme nous le verrons hélas, tout cela a bien du mal à se concrétiser dans le texte !

L’opuscule ne nous fera pas souffrir trop longtemps : malgré ses 310 pages, son format plus réduit qu’à l’accoutumée et ses nombreuses illustrations (en fait des scribings, souvent très bons, de la main de l’auteure) lui rendent l’équivalent d’à peu près 200 pages d’un format plus habituel. Le découpage en 12 chapitres semble plus pertinent sachant cela. Le tout est structuré en 2 parties inégales. La première « unleash your leadership potential » compte 200 pages pour 8 chapitres. Dans le chapitre introductif, l’auteur fait état de sa propre expérience pour pousser le besoin d’un changement : une organisation sans management !

Lire la suite

Note de lecture : The Art of Agile Development, par James Shore & Shane Warden

Note : 4 ; Une prétention encyclopédique qui tombe un peu à plat.

Ce n’est certainement pas le premier ouvrage à nous parler de développement agile. Vu son âge vénérable, nous lui concèderons aussi de faire partie de la première génération de livres consacrés à l’agilité. Nous ne nous étonnerons pas non plus que la pratique se consacre à Extreme Programming, mais sans aucune velléité dogmatique pour autant.

Avec près de 400 pages presqu’exclusivement couvert de texte, l’ouvrage est particulièrement dense. Il a des prétentions bibliographiques, car en grande partie consacré à des descriptions de pratiques qui sont loin d’extreme programming en grande partie. En cela ce titre est particulier. Il est structuré en 3 parties et totalise 15 chapitres. La première partie, « getting started » regroupe les 4 premiers sur environ 65 pages. Elle débute par un chapitre nous aidant à répondre au « pourquoi » de l’agilité. Il n’y a guère de surprise ici. Il est intéressant toutefois de voir l’auteur articuler son propos à la croisée des succès techniques, individuels et organisationnels.

Le « comment » devenir agile ne réserve guère plus de surprises, moins même. Les quelques pages qui lui sont dévolues se concentrent sur le manifeste agile : les valeurs et les principes, sans entrer dans les détails. Les détails, ils sont pour le chapitre 3 qui couvre XP, ou plus exactement l’interprétation par l’auteur de XP. La description est déjà colorée de pratiques et de rôles qui n’appartiennent pas au corpus d’extreme programming. La méthode originale en est difficile à reconnaitre. Le chapitre 4 « adopting XP » permet mieux de reconnaitre la méthode et ses vecteurs d’adoption. A une différence de taille : la recommandation d’adopter XP pour les projets « page blanche » qui me semble à la fois réducteur et en décalage avec le monde réel.

Lire la suite

Note de lecture : Agile Conversations, par Douglas Squirrel & Jeffrey Frederick

Note : 5 ; Des cadres de conversation essentiels, mais difficiles à appréhender !

Les transformations agiles ne sont pas seulement le fait d’adoption de pratiques, elles passent par des conversations qui favorisent le changement de culture. C’est tout l’objet de ce texte. Il ne s’agit pas de n’importe quelles conversations, mais d’un processus, d’une progression entre 5 types de conversation.

Avec moins de 190 pages et un format réduit, il a tout d’une lecture légère. Mais il n’en est rien, la prose ne s’avale pas d’un trait. L’ouvrage est composé de 2 parties très inégales. La première a une nature plutôt introductive et ne compte que 2 chapitres totalisant 50 pages. Le premier d’entre eux, escaping the software factory est une simple introduction à l’agilité, au lean et au devops. Il a le mérite de poser les principes de ces 3 courants de pensée, avec une mention spéciale aux principes du devops que l’on ne rencontre pas souvent écrits. Le second chapitre « improving your conversations » est une introduction à la seconde partie. Les types de conversation décrits dans cette seconde partie obéissent tous au cadre des « 4 Rs » décrit ici. C’est pour faciliter les deux premiers Rs (record & reflect) que les auteurs utilisent le format de conversation sur 2 colonnes utilisé par la suite et détaillé ici.

La seconde partie propose 5 types de conversations qui forment autant de chapitres. Ils sont à prendre dans l’ordre, car ils forment un édifice où une conversation sert de base à la suivante. Le chapitre 3 nous propose la conversation de la confiance, qui est bel est bien la fondation de l’édifice agile. Le cœur de cette conversation est le « TDD for people », un cycle délimité par l’action et l’observation, mêlant croyance, hypothèse est sens. C’est un concept plutôt difficile à appréhender et plus encore à adopter. Prévoyez de le relire deux ou trois fois.

Lire la suite

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.

Lire la suite

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.

Lire la suite

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.

Lire la suite

Note de lecture : Pomodoro Technique Illustrated, par Staffan Nöteberg

Note : 7 ; Pragmatique, simple et rafraichissant.

Les auteurs scandinaves se suivent … et sans se ressembler, ils semblent tous faire preuve d’une redoutable efficacité dans la rédaction de leurs textes ! Après avoir dégusté Kniberg, Staffan Nöteberg nous offre le texte de référence sur le Pomodoro.

En soit, le Pomodoro est une technique simple, qui en fait peut se décrire complètement en 2/3 pages. Bien sûr, ici il est question de mieux que cela, et l’auteur développe au long des 7 chapitres de cet ouvrage toutes les facettes de la mise en pratique de cette technique, s’appuyant pour cela sur sa propre expérience et nous la faisant partager.

Je l’ai dit, le Pomodoro est une technique simple (c’est bien sûr l’une de ses qualités essentielles), il n’était donc pas nécessaire de nous asséner un pavé pour l’expliquer. Le texte n’est long que de 137 pages. En fait, il est même plus court, car comme l’indique le titre, le livre est « illustrated » au sens le plus littéral : chaque page fait l’objet d’une illustration (naïve, mais amusante et réussie), faite de la main de l’auteur, sur du papier quadrillé et en couleur (crayon à papier et gouache, si vous voulez tout savoir). C’est une première pour un livre d’informatique, mais cela se marie curieusement bien au texte. Du fait de ces illustrations, la taille réelle de ce texte ne couvre qu’environ 2/3 des pages, soit environ 90 pages.

Lire la suite

Note de lecture : More Agile Testing, par Janet Gregory & Lisa Crispin

Note : 4 ; Pléthorique, mais toujours et encore trop verbeux.

Ce nouvel opus, de prime abord semble avoir pas mal de points communs avec le premier tome. Le plus important est la taille : ici encore il s’agit de 500 pages environ. Plutôt qu’une suite du premier volume, le thème serait plutôt « les auteurs n’ont pas tout dit » ! Si le volume précédent était majoritairement guidé par les cadrans de Brian Marrick, ici l’approche est plus thématique.

Le volume nous propose 25 chapitres, regroupés en 8 parties. La première d’entre-elle, sobrement intitulée « introduction » ne compte que 2 chapitres sur 25 pages. Le premier est consacré aux évolutions des pratiques durant les 10 années qui ont séparé les 2 volumes. Une synthèse juste et plutôt bien faite qui évoque par exemple le test d’applications mobiles ou les pratiques de test d’acceptation. Le second chapitre met un coup de zoom sur l’importance de la culture de l’organisation. C’est un aspect qui avait été peu (ou pas) évoqué précédemment.

La seconde partie « learning for better testing” va regrouper 4 chapitres sur un peu plus de 60 pages. Le chapitre 3 dédié aux rôles et compétences comprend des sujets tels que les profils généralistes versus spécialistes, donc bien sûr une évocation des profils en « I » et en « T » qui m’a toujours semblée un peu bateau et de la pluridisciplinarité. Donc, pas tant de choses nouvelles ou originales au final. Les « thinking skills » évoquées au chapitre m’ont semblées plus intéressantes : la facilitation, l’écoute, la connaissance du domaine pour n’en citer que quelques-uns sont replacés dans le contexte d’une activité de test. Une prose qui pourra s’avérer utile pour le recrutement de vos prochains testeurs.

Lire la suite

Note de lecture : L’art de devenir une équipe agile, par Claude Aubry, illustré par Etienne Appert

Note : 8 ; Une réussite !

Je pense qu’à un moment donné, Claude Aubry en a eu marre d’être enfermé dans Scrum. Au bout de 5 éditions de son best-seller, on le serait à moins. Ici c’est de culture agile dont il est question (bien que le cadre s’appuie très fortement sur Scrum).

Le format de l’ouvrage est atypique : la taille est large mais ne compte que 170 pages, bien que le grammage du papier laisse penser qu’il en contient 250. L’impression est bichromique, mais surtout les illustrations d’Etienne Appert se taillent la part du Lion. On aurait presque l’impression de lire « Martine s’essaie à l’agilité ». Si le texte de Claude forme la portion congrue (bon j’exagère un peu), il a en fait déployé tout son talent, car on savait déjà qu’il savait écrire, pour condenser son propos en peu de mots sans qu’il en coûte en fluidité de lecture. Un magnifique tour de force !

Le texte compte 7 chapitres et débute par une question cruciale : pourquoi devenir agile ? On y parle valeurs et principes, raison d’être et sens, le tout saupoudré d’un peu d’historique. Mais on y évoque aussi le faux-agile et une démarche pour réellement devenir agile s’appuyant sur l’agile fluency. Le tout est abondamment illustré, d’images mais aussi d’exemples, avec les « lapins agiles ». C’est excellent.
Le second chapitre aborde la question cruciale de l’équipe. Et l’auteur de nous proposer l’acronyme TAPIS pour résumer les propriétés d’une équipe agile. Claude Aubry aura été très créatif en acronymes tout au long du livre et ils sont très bons. Claude, c’est un peu notre Mike Cohn français. L’auteur s’appuie sur Scrum pour aborder les rôles dans l’équipe, alors même qu’il nous avait dit qu’il serait agnostique. L’angle se défend car l’alternative serait d’être trop abstrait. J’aurais aimé deux mots sur « compétences versus rôles », mais j’accorde un bon point à la section consacrée à la confiance. Encore une fois le chapitre est remarquable de clarté et d’efficacité, mais c’est vrai pour tout le livre.

Lire la suite