Note de lecture : Scaling Lean & Agile Development, par Craig Larman & Bas Vodde

Note : 9 ; Enfin un ouvrage sur le Lean développement qui renouvelle les idées ! Book of the year 2010 !

Le problème des ouvrages sur le Lean développement, c’est qu’ils ne savent guère que tourner en rond, exposer et (dans le meilleur des cas) développer les idées sous-jacentes aux principes Lean. Bien que le Lean soit à la mode, chaque lecture d’ouvrage sur ce domaine tend à se transformer en ennui annoncé.

J’ai donc une excellente nouvelle pour vous : ici, il n’en est rien ! Cet ouvrage de 330 pages est complété d’un « companion book » plus imposant, écrit par les deux mêmes auteurs. Mais nous allons nous concentrer sur celui-ci pour l’instant. Si l’ouvrage est écrit par deux auteurs, l’un des deux au moins, ne m’est pas inconnu : Craig Larman est « chief scientist » de mon employeur précédent, mais aussi un auteur émérite. Bref, il sait écrire, et je n’ai jamais été déçu par ses textes jusqu’à présent. Et disons que la série se poursuit.

Avant d’attaquer le contenu, je vous livre une de mes petites manies permettant d’avoir des indices sur la qualité du livre, avant et après lecture. Avant de commencer la lecture, je regarde les 1ère et 4ème de couverture. Une proportion importante des meilleurs ouvrages y propose des schémas ou des tableaux récapitulatifs du livre, ou même des aides mémoire. On a ça ! Après lecture, je compte le nombre de post It que j’ai placé sur le livre : ici j’en ai posé 22, c’est très très bon.

Après la forme, le fond. Le livre se découpe en 3 parties constituées de 12 chapitres, ce qui fait donc une moyenne de moins de 30 pages par chapitre. Ca va.

Autant nous occuper tout de suite de la 3ème partie, « miscellany » essentiellement constituée du dernier chapitre « Scrum Primer », qui n’est en fait pas écrite par les auteurs, mais par des auteurs du site http://www.scrumprimer.com ; Pour distinguer ce texte de celui des auteurs, le corps de la police utilisée est différent, plus petit. Il s’agit d’un bon « Scrum primer » qui présente l’avantage d’être assez direct et succinct et de bien recadrer ce qui fait partie du corpus de la méthode et ce qui n’en fait pas partie mais est généralement utilisé ! En plus de ce chapitre, on trouve les annexes habituelles (index et bibliographie), accompagné d’un « recommanded readings » assez sympa.

La première partie est consacrée aux « thinking Tools ». Il est long de 140 pages découpées en 5 chapitres (je n’ai pas compté le chapitre d’introduction, qui précède cette première partie). Le chapitre 2 (system thinking) est essentiellement un tutorial aux « causal loop diagram », même si les « fishbone diagrams » sont aussi évoqués. Le diagramme de boucles causales sera d’ailleurs utilisé ultérieurement dans le livre. Très réussi. On poursuit au chapitre 3 (Lean thinking) où l’on présente « Lean thinking house ». Les principes sont déclinés en pratiques. Les pratiques sont développés et illustrées. Impeccable là aussi. La théorie des queues est un volet important du Lean thinking. Le chapitre 4 qui lui est consacré est assez ardu à suivre. Mais on coupe court aux idées fausses de manière abrupte et l’on en a pour son argent ! Le chapitre 5 (false dichotomies) est sans doute l’un des plus abstraits par sa nature. Il s’agit là aussi de couper court aux idées fausses et de réfuter certaines idées prétendument opposées. Enfin le chapitre 6 (be agile) termine cette première partie en promouvant l’idée « d’être agile », donc de s’adosser aux valeurs, plutôt que de « faire de l’agilité » et donc de ne voir que les pratiques.

La seconde partie est dédiée aux « organizationnal Tools ». De taille égale à la premier (5 chapitres pour 150 pages), il focalise chaque chapitre sur une pratique Scrum inspirée de Lean, et adaptée aux projets de grande taille. Le chapitre 7 (feature team) met en exergue l’idée d’équipes pluridisciplinaires, par opposition aux organisations orientées composant. Le chapitre 8 (teams) est la poursuite de cette idée, avec une emphase sur le caractère auto organisée des équipes et sur la gestion des dépendances externes. Le chapitre 9 (requirements area) introduit une idée nouvelle sur la gestion de très gros backlogs. Dommage que ce chapitre de seulement 9 pages n’ait pas été plus développé ! Le chapitre 10 évoque l’extension de l’organisation agile au niveau de l’organisation de l’entreprise. J’y ai surtout aimé la distinction projet / produit, souvent incomprise et source de problème, tandis que les aspects ressources humaines sont du déjà vu et hélas une appréhension bien trop idéaliste du sujet. Enfin le chapitre 11 (large scale Scrum) évoque une partie du sous-titre de l’ouvrage et dit en substance que l’adaptation de Scrum aux grands projets … n’existe pas en tant que tel !

Finalement, j’ai retardé la lecture de cet ouvrage ne me sentant pas tellement concerné par le « large scale Scrum ». C’était une erreur, car en fait pu de choses dans ce livre sont vraiment dédiées spécifiquement aux grandes équipes. Au contraire, la littérature agile qui me semble rabâcher les mêmes propos depuis quelques années retrouve un peu de fraicheur ici. J’ai hâte de lire la suite, et bien sûr je recommande chaudement, sans aucune réserve !

scaling-lean-agile-dev-Larman

Référence complète : Scaling Lean & Agile Development, Thinking and organizational Tools for large-scale Scrum – Craig Larman & Bas Vodde – Addison Wesley 2009 – ISBN : 978 0 321 48096 5

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

http://www.goodreads.com/book/add_to_books_widget_frame/0321480961?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Agile Product Management with Scrum, Creating products that customers love par Roman Pichler

Note : 3 ; Vraiment très léger, et pas si bien avisé que ça.

Plutôt qu’un livre, il s’agit d’un opuscule. D’abord par son nombre réduit de pages (118) et par son format à mi-chemin du livre de poche, ce qui est inhabituel. Tant mieux si le texte y gagne en pertinence et en efficacité. Hélas, ce n’est pas trop le cas, on frôle même parfois le hors sujet sans traiter en profondeur le sujet principal du livre ! Justement, effeuillons le texte. Celui-ci est découpé en 6 chapitres, donc avec une moyenne de 20 pages par chapitre.

Le premier chapitre rentre directement au cœur du sujet : qu’est-ce que le product owner ? On y énumère les qualités attendues de celui-ci et on évoque son rôle au sein de l’organisation, y compris celle d’un groupe de PO. Je dirais que globalement le propos est intéressant mais qu’on y apprends pas grand chose, le traitement me paraissant abstrait voir un peu théorique.

J’ai été intéressé de voir un chapitre consacré au développement de la vision, qui est l’un de mes thèmes favoris. Si on y reprends des bonnes idées largement connues par ailleurs (elevator statement, vision box ou modèle de Kano), je vois plutôt ce chapitre comme une introduction au sujet. Et je reste gentil.

Le troisième chapitre consacré au backlog est naturellement un des points majeurs du livre. Le principe de granularisation progressive des items de backlog est je pense un sujet connu d’un certain nombre de praticiens, il est bien de le voir évoqué là. Hélas une fois encore j’en trouve le traitement superficiel. Ce chapitre joue un double rôle en évoquant le volet recueil des besoins. Ce sujet aurait mérité son propre chapitre. Cet aspect est important et j’en trouve le traitement bien léger, voir bâclé. Un exemple du genre est l’évocation des exigences non fonctionnelles. La comparaison entre ce qui est dit ici et ce que l’on retrouve dans les meilleurs ouvrages traitant de l’ingénierie des exigences fait mal, très mal.

Les chapitres 4 et 5 sont consacrés au rôle du PO au sein des différentes pratiques de Scrum. Il s’agit à mon avis d’ajouts inutiles. Ces aspects sont déjà traités dans les ouvrages classiques traitant de Scrum. Et même si le propos est centré sur le product owner, je n’y trouve ni créativité ni apport de l’expérience de l’auteur.

Le sixième chapitre conclut sur les façons de monter en compétence sur le rôle de product owner. Dommage qu’il ne fasse que 7 pages, la prose y est forcément superficielle.

Clairement ce livre a été une grosse frustration pour moi. Il ne mérite pas la « signature series ». Peut-être mes attentes étaient-elles trop élevées, mais je pense qu’il y a plus et mieux à dire sur le rôle du product owner que ce qui est évoqué ici. Je n’estime pas la note trop sévère. Il reste que le texte satisfera peut-être de nouveaux venus à Scrum ?

agile-product-mgt-scrum

Référence complète : Agile Product Management with Scrum, Creating products that customers love – Roman Pichler – Addison Wesley / Signature series 2010 – ISBN : 978 0 321 60578 8

Agile Product Management with Scrum: Creating Products That Customers Love


http://www.goodreads.com/book/add_to_books_widget_frame/0321605780?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Quand mon produit est un système d’information (Scrum Day 2011)

Scrum évoque implicitement, dans les différentes descriptions qui en sont faites, la réalisation de systèmes fermés, qu’ils soient logiciels ou applications Web.

Lorsqu’il s’agit d’informatique interne, il s’agit le plus souvent, non plus de réaliser une application isolée, mais de faire grandir un système d’information constitué de plusieurs composants applicatifs collaborant ensemble.

Dans ce contexte, la dimension projet est généralement dissociée de la dimension produit (le système d’information). Comment gérer une telle dichotomie avec Scrum ?

Les différents projets d’informatique interne s’adossant et faisant croitre un même système d’information, comment gérer les interactions et les synergies entre ces projets ?

Est-il nécessaire de penser et faire des plans sur l’évolution de l’architecture du SI indépendamment du cadre imposé par chaque projet ? Si oui, est-il possible de faire cela tout en restant dans Scrum ?

C’est à ces différentes questions et bien d’autres encore que nous tentons de répondre ici.

Scrum Day 2012 : appel à orateur

Le Scrum Day 2012 Arrive, ce sera le 27 mars à l’espace CAP 15 !

http://www.frenchsug.org/display/FRSUG/Scrum%2BDay%2C%2B27%2Bmars%2B2012

Vous pouvez dès à présent soumettre vos propositions de présentations via le formulaire en ligne prévu à cet effet :

https://docs.google.com/a/frenchsug.org/spreadsheet/viewform?hl=en_US&formkey=dG43VHNhLUNkcmVUWFp6N1EySTdqRmc6MQ#gid=0

Vous avez jusqu’au 22 février pour soumettre vos propositions, la sélection finale des sujets retenus s’opèrera fin février, les orateurs seront notifiés à ce moment là et le programme du Scrum Day mis à jour au même moment sur le site.

Les inscriptions à la conférence elle-même seront ouvertes très bientôt, vous en serez prévenus par les canaux habituels.

Si vous avez des questions concernant la soumission de sujets, merci de de les envoyer à orateur@frenchsug.org

Appel à animateurs pour la Scrum Night de décembre

Si vous suivez les évènements du SUG sur meetup, vous aurez certainement remarqué la programmation d’une Scrum Night le mercredi 7 décembre !

Cet évènement est entièrement dédié aux agile / innovation games. Il y sera proposé des activités sous forme d’ateliers se déroulant en parallèle.

Les innovations games sont un sujet qui vous passionne ? Vous êtes aguerri(e) à la pratique de l’un d’entre eux et/ou avez eu l’occasion d’animer un tel atelier ? Proposez-vous pour animer un atelier lors de la Scrum Night !

Faites votre proposition à orateur@frenchsug.org ! Idéalement, nous souhaiterions recevoir toutes les propositions d’ici le dimanche 30 octobre. Peut-être serons-nous amenés à allonger ce délais toutefois.

N’hésitez pas ! Cet évènement promet d’être convivial, inhabituel et fun. Vous pouvez aussi vous proposer dans le cadre d’une co-animation, soit en vous proposant directement en binôme, soit simplement en vous proposant en co-animation. Nous verrons alors comment vous associer à un partenaire en fonction des candidatures qui nous seront parvenues.

Bien sûr si vous n’êtes pas intéressés par une animation, mais simplement par une participation, inscrivez-vous sur le meetup : les inscriptions sont ouvertes !