Note de lecture : User Story Mapping, par Jeff Patton

Note : 9 ; Bien au-delà du story mapping, vers la découverte de la vraie nature des spécifications agiles en tant que compréhension partagée. Book of the year 2015 !

Jeff Patton est un vrai maître Jeidi de l’agilité : après avoir lu, ou plutôt dévoré son livre, je n’en ai plus aucun doute ! Mais si vous pensez lire « simplement » un ouvrage décrivant par le menu la technique développée par Jeff Patton, vous allez être surpris ! Car c’est bien plus que cela.

Le livre fait un peu plus de 260 pages en 18 chapitres. Je dis « un peu plus de 260 pages » car le corps principal du livre est précédé d’une introduction « read this first » qu’il ne faut rater sous aucun prétexte. On y parle « instructions » versus compréhension partagée, de comparer les (docs de) spécification à des cahiers de voyage, de l’importance de raconter des histoire et d’être frugal dans la construction tout en cherchant à maximiser l’impact plutôt que les fonctionnalités ! Bref, cette introduction à elle seule a la valeur d’un très bon livre. Et ce n’est pas fini !

Raconter des histoires, c’est le sujet du 1er chapitre où l’auteur introduit les story maps dans le but de raconter la grande histoire du système, d’avoir une « big picture ». Il le fait d’ailleurs en racontant une histoire, celle de Gary par qui les user stories sont arrivées ! D’ailleurs la totalité du livre est formée d’histoires. Et celles-ci sont illustrées de photographies des fresques (en couleur dans la version anglaise) que sont ces stories maps auxquelles l’auteur surimpose des explications sous forme de cartographie.

Continuer à lire « Note de lecture : User Story Mapping, par Jeff Patton »

Note de lecture : Agile and iterative development a manager’s guide, par Craig Larman

Note : 9 ; Eclairé et agréable à lire. Comme toujours, avec Larman…

Nous commençons à avoir l’habitude de la qualité des textes de Craig Larman. Celui-ci ne fait pas exception et est également témoin du virage de l’auteur vers les pratiques agiles. Dans cet ouvrage, Larman se focalise sur l’aspect gestion de projet, mettant l’emphase sur le cycle itératif et ses bénéfices, notamment par rapport au cycle en V. Il s’agit donc bien d’un ouvrage pour convaincre et faire prendre conscience du changement de paradigme qu’amène l’agilité. Le texte date de 8 ans, mais je pense qu’il reste tout à fait d’actualité, d’une part car il reste beaucoup de monde à convaincre, et d’autre part car il est à peu près seul sur son créneau, la plupart des livres dédiés à l’agilité se focalisent sur le « comment » plus que le « pourquoi ». Il serait plutôt à comparer à « Agile Software Development Ecosystem » de Jim Highsmith.

Cela dit, ce volume n’est pas un guide touristique. Ses 330 pages découpées en 12 chapitre en attestent. Je passe rapidement sur le premier chapitre qui ne compte que 6 pages : il fournit quelques généralités sur la logique de projet prédictifs à opposer avec le développement de nouveaux produits. Il fournit aussi nombre de liens dont beaucoup sont toujours actifs ! Le second chapitre traite sur une quinzaine de pages la logique des projets évolutifs et itératifs. C’est très abondamment illustré, extrêmement clair et chirurgical, dirais-je. Un plaisir !

Continuer à lire « Note de lecture : Agile and iterative development a manager’s guide, par Craig Larman »

Note de lecture : The Back of the Napkin, par Dan Roam

Note : 7 ; Le grand classique de la résolution de problèmes par la visualisation

Cela faisait un moment que je tournais autour de ce grand classique. Il n’y a plus pour moi aucun doute sur la raison pour laquelle ce titre mérite sa réputation, et elle est grandement méritée. Par contre, il ne va pas être très facile de résumer cela ! Tout d’abord le livre lui-même est d’un format inhabituel (il est de format carré), et ses 256 pages se comparent difficilement à un format classique. Ceci sans compter les très nombreux dessins de l’auteur qui sont l’âme même du livre.

La dernière représentation de l’auteur, page 255, résume parfaitement la teneur du propos, c’est à dire l’articulation de la démarche proposée en 4 plans.

  • Tout d’abord les « basic visual thinking tools » : les yeux, les « yeux de l’esprit » et la coordination œil-main. Il n’y a pas de chapitre à proprement consacré à ce plan, mais il est abordé au chapitre 2, avec une vue générale du framework.
  • Les 4 étapes de la pensée visuelle : regarder, voir, imaginer et montrer. L’auteur décompose ce processus au chapitre 3, en s’appuyant sur une partie de Poker ! Un cheminement qui met en valeur les qualités pédagogiques de l’auteur.
  • Le SQVID. Il s’agit d’un « framework de visualisation », probablement la partie la plus délicate de l’ouvrage. Elle est abordée au chapitre 6. Celui-ci méritera (au moins) une seconde passe.
  • Les 6 façons de regarder, qui correspondent à 6 questions : Qui / quoi ? Combien ? Où ? Quand ? Comment ? Pourquoi ? Abordé au chapitre 5, ce framework que l’auteur présente comme le <6><6> rules est développé réellement au chapitre 7.

Continuer à lire « Note de lecture : The Back of the Napkin, par Dan Roam »

Note de lecture : The Principles of Product Development Flow, par Donald G. Reinertsen

Note : 8 ; Passionnant et passionnément austère !

Don Reinertsen n’est pas là pour s’amuser. Déjà vers la page 17, l’auteur nous explique que la manière d’appréhender les dimensions économiques d’un produit sont aujourd’hui bien naïve, que la théorie des contraintes de Goldratt est certes un progrès mais qu’elle ne représente qu’une étape intermédiaire, et que nous allons passer en revue tout cela au long de 150 principes que couvre le reste du livre. Oui : 150 ! A ce stade, on pressent que la lecture des 266 pages de l’ouvrage découpé en 9 chapitres va être bien plus longue que prévue. Une impression qui se vérifiera.

Le premier chapitre compte 26 pages. Il sert d’introduction aux 8 autres chapitres, ce n’est donc pas le plus difficile à lire. Et pourtant il fourmille déjà de concepts et d’une description très affutée des problèmes auxquels nous devons faire face lorsque l’on développe un produit. Bref, il campe le décors et fort bien !

On a guère pitié du lecteur : le second chapitre sur la « vue économique » est déjà un des chapitres difficiles de l’ouvrage. Mais c’est aussi la clé de voute de ce qui suit, à savoir le coût du délai ! On y parle d’objectifs économiques clés et déjà de la perception économique de la taille des lots intégrant le facteur « coût de transaction ».

Continuer à lire « Note de lecture : The Principles of Product Development Flow, par Donald G. Reinertsen »

Note de lecture : The Scrum Field Guide, par Mitch Lacey

Note : 4 ; La promesse d’un accompagnement pour démarrer, mais au final des conseils biaisés et parfois critiquables sur la mise en place de Scrum !

Un livre pour vous accompagner durant votre première année de Scrum, telle est la promesse de Mitch Lacey ! Le livre est bien écrit, et l’auteur sait puiser dans une large connaissance de ses sujets. Chaque chapitre est construit de la même façon : d’abord une histoire, puis « le modèle » et enfin les clés du succès pour conclure. Dommage de ne pas avoir tenté de construire un fil rouge avec l’histoire, car c’est un contexte différent que l’auteur nous propose à chaque fois.

En lui-même, le livre n’est pas une lecture légère ; 350 pages découpées en 30 chapitres sous 4 parties. Rajoutez à cela 10 pages d’annexes pour décrire le framework Scrum. Les 18 pages du 1er chapitre sont en dehors des 4 parties. Il sert à introduire Scrum et fait plutôt bien son boulot. Notons que l’on y parle des valeurs et pratiques Scrum (à distinguer de celles du manifeste).

La première partie elle-même est constituée de 7 chapitres sur 95 pages. La douzaine de pages du second chapitre évoque l’embarquement des personnes sur le projet, la vision, le sentiment d’urgence, tout ça. J’ai trouvé cela bien peu convainquant. Au long des 15 pages du chapitre 3, l’auteur développe un modèle bien à lui, celui du « team consultant ». On s’écarte assez notablement de la Vision Scrum ici. Et pour des nouveaux venus, elle est facile à interpréter incorrectement, avec le mise en place de baronnies au sein de l’organisation ! 15 pages également sont dédiées à la gestion de la vélocité au chapitre 4. Pourquoi traiter ce sujet dès maintenant ? Mystère. Toute la logique du plan est en fait un peu mystérieuse pour moi. Rien de transcendant dans ce chapitre 4, par ailleurs. Mais les rôles de Scrum eux méritent bien d’être traités tôt. Mais on n’en dit presque rien ! Seules 9 pages leurs sont dédiées au chapitre 5. Décidément les priorités et les importances des sujets sont troublantes. On passe un peu plus de temps (mais à peine) sur la détermination de la longueur des itérations, où l’auteur nous propose une impressionnante « scoring key », à mon avis complètement inutile. Dans le même ordre d’idées, 8 pages à propos de la définition de terminé… bof, pas grave, n’est-ce pas ? Le chapitre se termine par un sujet qui tient à cœur à l’auteur : le « full time Scrum Master », sur lequel je suis en complète opposition !

Continuer à lire « Note de lecture : The Scrum Field Guide, par Mitch Lacey »

Note de lecture : Why Plans Fail, par Jim Benson

Note : 8 ; Où l’on parle (enfin) de biais cognitifs !

J’ai eu un peu de mal à classer ce texte. De par la nature du texte, il devrait plutôt se classer dans la gestion de projet, la gestion de projet agile pour être plus précis. D’un autre côté, la nature même du sujet me donnait envie de le classer dans l’expression de besoin : à mon avis la détection des biais cognitifs doit nécessairement faire partie de la boite à outil du Product Owner. Finalement j’ai opté pour le premier choix.

L’une des grandes qualités de ce mini-livre est sa brièveté : 82 pages (plus quelques annexes) sous un format des plus réduit. Il s’agit donc d’une lecture que l’on peut avaler en quelques jours, voir une seule journée ! Ce sont une douzaine de biais cognitifs parmi les plus fréquents qui sont évoqués ici, remis dans un contexte de projet informatique. Cela en fait un livre unique, car si le sujet est traité de manière plus extensive dans d’autres ouvrages qui font autorité et auxquels l’auteur se réfère, celui-ci est le seul à évoquer le propos dans le domaine qui nous concerne.

Le texte ne se veut pas un traitement en profondeur du sujet, mais plutôt une amorce de réflexion et de discussion autour de ces biais cognitifs. La prose est en effet découpée en 16 chapitres, qui ne comptent donc que quelques pages chacun.

Continuer à lire « Note de lecture : Why Plans Fail, par Jim Benson »

Note de lecture : Managing to Learn, par John Shook

Note : 4 ; Storytelling peu convainquant

Cet ouvrage au format inhabituel m’a été chaudement recommandé pour m’initier au A3 problem solving. Le format est inhabituel pour trois raisons :

  • Du fait de son format physique tout d’abord. Il est pratiquement carré et dépasse donc allègrement mes autres livres une fois rangé dans la bibliothèque.
  • Par son approche éditoriale : il s’agit d’un double storytelling, permettant une lecture à double niveau. Mais ceci complexifie aussi considérablement la manière d’aborder le texte. J’y reviendrais.
  • Par ses annexes : en fait des exemples de A3 (qui du coup ne sont pas au format A3), livrés pliés et insérés dans un rabat de la couverture arrière. Une bonne surprise de l’ouvrage.

Mais revenons-en au texte. Sous le format inhabituel dont j’ai parlé tout à l’heure, l’ouvrage compte 127 pages présentées en deux colonnes de largeurs inégales. La plus large, imprimée en noire, raconte l’histoire de Porter qui s’initie au A3 (mais bon, il connaît quand même un peu en fait). Cette histoire doit nous permettre de nous initier par l’exemple au concept du A3, le fameux « problem solving » spirit ! La seconde colonne est imprimée en bleue, c’est une histoire dans l’histoire, celle de Sanderson le manager de Porter. Sanderson est en posture de coach par rapport à Porter, c’est donc un deuxième niveau de lecture qui nous est proposé ici.

Continuer à lire « Note de lecture : Managing to Learn, par John Shook »

Note de lecture : The People’s Scrum, par Tobias Mayer

Note : 9 ; Scrum niveau « Ri ». Book of the year 2013 !

Le livre ne paie pas de mine : un petit format qui compte environ 150 pages et une annexe de 3 pages (la description de Scrum selon l’auteur !). Le contenu lui-même vient d’une sélection de posts de l’auteur en provenance de son ancien blog : Business Craftsmanship. Les posts eux-mêmes ont été un peu retouchés, mais à peine ! Le volume se présente donc en 3 parties, chacune découpées en environ une douzaine de posts.

Ainsi décrit, il n’y a rien qui attire spécialement l’attention ! Ce qui attire vraiment l’attention, c’est le contenu même des posts, l’angle pris par l’auteur. Ici, nul focus sur l’aspect folklorique des méthodes agiles. D’ailleurs on ne parle même pas de méthode, mais de communication, de savoir-être et de culture ! C’est un point de vue original et disruptif sur Scrum, où l’auteur met d’avantage le doigt sur l’aspect dépouillé du framework qui laisse la place à ce qui compte vraiment. Voyons cela, justement.

La première partie, « The Intrepid Explorers » est composé de 13 posts, qui couvrent 35 pages. Parmi ceux-ci, je retiendrai « the heart of Scrum », qui présente le Scrum board comme un forum de communication pour l’équipe, « distributed teams are not teams » qui pose bien la posture tranchée de l’auteur. « The agile explorer » est très significatif du point de vue de l’auteur sur l’approche agile, un état d’esprit de perpétuelle découverte, de remise en cause de l’organisation pour implanter l’ADN agile. Bien entendu, on ne peut faire l’impasse sur « the people’s Scrum » qui donne son titre au livre, véritable profession de foi de l’auteur sur sa vision humaniste de l’agilité.

Continuer à lire « Note de lecture : The People’s Scrum, par Tobias Mayer »

Note de lecture : The Elements of Scrum, par Chris Sims & Hillary Louise Johnson

Note : 6 ; Bien écrit et pertinent, mais aussi sans beaucoup de surprises.

Cet ouvrage est le grand frère du « Scrum, a Breathtakingly Brief and Agile Introduction », ou plutôt est-ce l’inverse ! Cela reste un ouvrage descriptif sur Scrum. Au moins celui-ci est-il vivant et bien écrit.

La première partie (introduction à l’agilité) est précédée d’un petit storytelling « a week in the life of a Scrum Team ». Il me rappelle le « Scrum in action » de Jeff Sutherland. Mais ici il n’a qu’un objectif de mise en jambe et c’est plutôt original et réussi. Le premier chapitre de cette seconde partie a trait (tarte à la crème des temps modernes) à la comparaison entre cycle en cascade et agile. On échappe toutefois aux lieux communs et le propos est même éclairé !

Le second chapitre (3ème en fait) introduit l’agilité (classiquement aussi) par l’écriture du manifeste agile. Là encore bien écrit et documenté il constitue une bien sympathique synthèse historique. Il n’est guère surprenant de voir un chapitre dédié aux principes et valeurs agiles lui succéder. Le propos sur les valeurs agiles n’est guère original, mais les 12 principes sont plus rarement évoqués. Ils intéresseront les nouveaux venus à l’agilité.

L’agilité est-elle rentable ? C’est ce qu’explore ce 5ème chapitre en comparant le déroulement en parallèle d’un projet en agile d’un côté et en cascade de l’autre. Cette histoire montre la valeur de l’approche agile d’un point de vue financier. Cela dit, ce chapitre aborde ce cas de figure de manière un peu simpliste.

Continuer à lire « Note de lecture : The Elements of Scrum, par Chris Sims & Hillary Louise Johnson »

Hiring the Best Knowledge Workers Techies and Nerds, par Johanna Rothman

Note : 6 ; De la définition de poste jusqu’à l’embauche

Le recrutement est probablement le facteur le plus important de la constitution d’une équipe. Avec le temps, on finit par développer une certaine expérience sur le sujet, et aussi une approche de ce qui est important, déterminant et ne l’est pas. Et à un moment donné, on souhaite confronter ces idées instinctives aux personnes expertes du sujet. C’est à ce moment que l’on s’aperçoit que ces experts ne sont pas si nombreux, la plupart se bornant à de classiques conseils RH sans valeur dans notre domaine. S’il est un auteur auquel j’attache quelque importance dans ce domaine, c’est bien Johanna Rothman.

Sur ce sujet, notre experte du management agile nous gratifie tout de même d’un ouvrage comptant 280 pages sans les annexes (comptez une cinquantaine pour ces dernières). Johanna Rothman a délibérément choisi de couvrir tout le cycle de vie du recrutement, donc en ne se limitant pas à l’interview. Par ailleurs, ce livre ne s’adresse pas spécialement à de l’embauche en contexte agile et certains éléments du cycle de recrutement sont assez spécifiques du contexte américain. Toutefois, aucun de ces deux points n’est un obstacle, l’approche de l’auteur est en effet très convergente avec ce que l’on essaie de faire (en tout cas moi) lors d’un recrutement en contexte agile.

Passons maintenant en revue le texte. L’ouvrage compte 5 parties distinctes totalisant 15 chapitres. La première partie couvre globalement les questions de définitions de poste. Elle est longue de 65 pages et comprend 3 chapitres. Le premier couvre une vingtaine de pages et traite de la stratégie d’embauche. Il culmine avec un « hiring strategy template » permettant de s’orienter entre embauche externe, contractant, embauche interne, etc. en fonction du type de besoin et du contexte de la recherche. Malgré sa qualité, ce n’est pas ce qui m’a intéressé le plus. Le propos du chapitre suivant est « d’analyser le job », il occupe 30 pages et nous conduit à déterminer les compétences techniques et humaines nécessaires en fonction du type de travail. Une analyse très fine et pertinente qui va jusqu’à évoquer les questions de fit culturel avec l’entreprise et les facteurs d’élimination. Cette partie se conclut avec le chapitre 3 qui traite sur une dizaine de pages l’écriture de la fiche de poste. Il s’agit du chapitre qui m’a le moins intéressé : l’auteur nous propose une fiche de poste des plus classiques (bien que complète) mais qui ne sera pas à même de faire briller les yeux…

Continuer à lire « Hiring the Best Knowledge Workers Techies and Nerds, par Johanna Rothman »