Note de lecture : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, par Véronique Messager-Rota

Note : 5 ; Un point de départ pour le chef de projet débutant, complété par des évolutions mineures, au fil des éditions.

Il est certainement une chose plus difficile que donner une note et un avis sur un ouvrage auquel on a participé : c’est se livrer au même exercice sur un livre dont on est l’auteur ! Je n’en suis pas là, mais cet exercice reste bien assez difficile pour moi.

Ce livre n’est pas une bible de la gestion de projet agile. Je doute d’ailleurs qu’une telle chose puisse exister. Il s’adresse plutôt à un publique junior ou en tout cas nouveau venu dans l’agilité et adresse deux questions essentielles :

  • Quelles sont les activités que doit mener ou maîtriser le chef de projet : Ce sujet est traité tout au long du livre, car les différents chapitres traitent chacun un aspect spécifique des disciplines à maîtriser : ébauche de la vision, gestion des besoin, suivi des hommes et pilotage du projet. Il manque hélas une partie consacrée aux tests, et je regrette de mon coté que la facette plus technique du projet ne soit pas abordée, car je considère le rôle du chef de projet comme davantage holistique.
  • Quel style aborder pour gérer les projets ? Le titre du livre réponds à cette question, bien que parfois le texte ne nous laisse pas clairement comprendre quelle approche est la bonne. Toutefois mettre les approches classiques et agiles en perspective est un bon exercice.

L’une des particularités du livre est certainement de laisser une part importante aux retours d’expériences (y compris ceux de votre serviteur) pour éclairer le propos. Sans être réellement aride ni académique, celui-ci est souvent un peu trop formel à mon goût.

Ce livre en est maintenant à sa 3ème édition. Que dire des évolutions entre la première mouture et le dernier rejeton ?

Tout d’abord que ces deux nouvelles éditions répondent en premier lieu au « business model » d’Eyrolles consistant à publier très régulièrement de nouvelles éditions de ses best-sellers. Donc il s’agit d’un best seller ! Comme chacun sait, cela n’est pas synonyme de qualité, mais en l’occurrence ce texte atteint bien sa cible (celle que j’ai évoquée plus haut) et le succès du livre en est témoin.

Dans la seconde édition, l’auteur a profité de l’occasion pour rafraîchir sa prose, même si c’est de façon mineure. Cela se voit dès la pagination, le volume total passant de 230 à 250 pages (hors annexes). Il s’agit surtout d’ajouts à l’intérieur des chapitres existant, le texte de base me paraissant inchangé. Ainsi le chapitre 2 qui exposait déjà de manière synthétique et avec brio les différentes méthodes agiles, ajoute « Lean » à sa panoplie. Le chapitre 3 se voit étoffé d’un court comparatif entre les users stories et les cas d’utilisation. Utile en soi, ce comparatif est je pense matière à débat. En clair : il faut qu’on en reparle, Véronique ! Le chapitre 7, consacré à l’adoption des méthodes agiles est celui qui bénéficie le plus d’ajouts : mesure de l’adoption et accompagnement de la conduite du changement.

L’apport le plus important à l’ouvrage est la section consacrée aux apports du coach (toujours dans le chapitre 7). Ces quatre pages supplémentaires ciblent les apports du coach par rapport à l’équipe et au management sur le « savoir être ». Il s’agit d’une prémices du prochain livre de Véronique !

La troisième édition qui n’apporte à nouveau que des bribes de nouveautés. On notera ainsi :

La section dédiée aux organisations agiles, au chapitre 2, qui permet de valoriser les idées avancées par Jérôme Barrand. Le chapitre 4, se voit lui, gratifié d’une page consacrée au pomodoro, ce qui est un ajout original et sympathique. Au chapitre 6, un petit ajout est fait sur le thème de la facilitation.

Sans avoir réellement vieilli, le livre voit son public se restreindre d’année en année : s’il adressait un public d’early adopter lors de sa sortie, il s’agirait maintenant plutôt de late adopters, pas forcements enclins à aller rechercher activement de l’information. Véronique Messager ne semble guère souhaiter poursuivre la politique de retouche mineures du texte et c’est à son honneur.

Si vous débutez en gestion de projet et vous posez la question de l’adoption d’une approche agile, ce livre est pour vous. Il vous permettra de poursuivre plus facilement votre apprentissage par des textes plus avancés ensuite.

Gestion de projet agile avec Scrum, Lean et XP

Référence complète : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, 3ème édition – Véronique Messager-Rota – Eyrolles 2010 – EAN : 978 2 21212750 8

Gestion de projet agile avec Scrum, Lean, eXtreme Programming...


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

Note de lecture : Pair Programming Illuminated, par Laurie Williams & Robert Kessler

Note : 7 ; Plutôt bon, mais un livre qui ne présente pas le même niveau d’intérêt pour tous les publics !

Laurie Williams est reconnue dans la communauté agile pour être une grande spécialiste des aspects collaboratifs, il est donc logique qu’elle soit l’auteur de l’ouvrage de référence sur le pair programming, avec Robert Kessler, son mentor.

Le « pair programming » est probablement la pratique qui fait l’objet du plus de résistance lors de la mise en place d’une méthode agile. A cet égard, il n’est pas illogique de chercher à blinder la mise en place de cette pratique, par exemple à l’aide de ce livre. On reconnaitra que le texte cherche vraiment à traiter toutes les facettes du pair programming.

La première partie a trait à la compréhension de ce qu’est vraiment le pair programming. C’est sur cette partie qu’il faudra construire l’argument pour convaincre. L’auteur s’attaque aux mythes justifiant l’opposition à cette pratique avant d’évoquer les aspects bénéfiques. Vient ensuite le plat de résistance : convaincre le management. J’avoue que c’est du solide, avec des arguments, des chiffres et tout et tout. Cette partie se termine par l’évocation des difficultés qui peuvent se rencontrer à la mise en place du pair programming. Somme toute, cette première partie est une sorte de préambule à la mise en place de la pratique : pour convaincre, anticiper les obstacles et les objections, etc… Il n’y a rien à jeter et on a vraiment des choses solides sur les 60 pages de cette partie.

Longue d’une trentaine de pages, la seconde partie intitulée « getting started » m’a paru moins utile. Beaucoup d’éléments qui y sont présentés viennent simplement du bon sens et l’on a guère besoin du texte pour y arriver. Mais peut-être n’est-ce pas si mal d’avoir cela écrit quelque part ? Une mention particulière au chapitre 11 « tips ‘n tricks » qui donne pas mal de trucs utiles.

La troisième partie est la plus longue du livre avec une centaine de pages. Elle est écrite sous forme de patterns avec les différentes configurations de pairing (expert / novice, expert/expert , etc…) et différentes situations émotionnelles. L’idée est de fournir des solutions sous forme de scénarios afin de rendre possible ces différentes dynamiques de travail. Je ne suis pas convaincu que tout cela marche d’une manière aussi simple, mais au moins cela donne des pistes de réflexions.

La dernière partie enfin évoque différents aspects rassemblés ici de manière un peu hétéroclite : aspects économiques, les bonnes habitudes, pair programming versus code inspection, etc..

Le texte n’est pas mal écrit et plutôt plein de bon sens. De plus il est abondamment émaillé de références bibliographiques (l’auteur les a même fait figurer en fin de chaque chapitre). La première partie est littéralement de l’or en barre et on trouve clairement du matériel intéressant dans les autres. Beaucoup de matériel reste surtout intéressant pour ceux qui portent un intérêt académique au sujet (c’est mon cas). C’est un livre que je conseillerais sans hésiter au coach qui va y trouver beaucoup de matière première pour guider les pratiques d’une équipe. Le manager va y trouver des arguments pour défendre cette pratique, mais le développeur aura sans doute la sensation de perdre son temps à cette lecture.

pair-prog-illuminated

Référence complète : Pair Programming Illuminated – Laurie Williams & Robert Kessler – Addison Wesley 2002 – ISBN: 0-201-74576-3

Pair Programming Illuminated


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

En finir avec …

Mare du dogmatisme ? Besoin de fraicheur ?

Cet été je vais me métamorphoser en grand sacrilège du Scrum ! Non que je ne crois plus en Scrum, mais plutôt que je voudrais m’insurger contre une utilisation un peu mécanique de la méthode qui va à l’encontre même de l’agilité

En finir avec les zombies !

Je vais intitulé ma série d’article “en finir avec …”. Pour l’instant je n’en ai écrit aucun, j’espère que j’arriverais à tenir ce que je dis. Je ne m’engage pas sur un nombre d’article, vous verrez bien ce qui arrivera, mais ça arrivera entre maintenant et la mi-spetembre, qu’on se le dise. Ca vous oblige aussi à rester à l’écoute, du moins ceux qui pensent que je peux les intéresser.

Mais pourquoi “en finir avec” ?

Par provocation, d’abord !

Ensuite pour stigmatiser que rien n’est coulé dans le béton. Les éléments constitutifs de Scrum ne sont ni une fin en soi ni une justification. Ce sont juste des moyens, un guide pour faire des projets agiles. Si je dois choisir, je préfère un projet agile sans Scrum, qu’un projet déguisé qui s’auto-proclame agile (mais qui ne l’est pas) sous couvert de backlog, product owner, stand-up, etc…

Pensez plutôt que d’appliquer !

Je constate, et hélas je ne suis pas le seul, une augmentation des projets Scrum Canada Dry. Peut-être est-ce le prix à payer pour cette extension rapide de Scrum que nous observons aujourd’hui ? Beaucoup d’organisation dépourvue d’ADN agile tentent l’agilité en mimant ses rituels. C’est le “cargo culte”.

Mon but est de réagir, de nous éloigner de l’aspect rituel afin de nous concentrer sur l’aspect fondamental et initial de l’agilité. Je ne le ferais pas en citant une nouvelle fois le manifeste agile, bien que j’avoue que ce soit un bon moyen mais en faisant oeuvre active de déconstruction !

Attention, ça commence bientôt …

Action !

Ce prologue va me forcer à entrer en action, car je n’ai encore rien rédigé. Voici donc l’agenda :

  • A partir de la semaine de cet été jusqu’à la mi Septembre, une série de posts sur ce thème ! Je ne sais pas encore combien, cela va dépendre de mon courage et de mon inspiration.
  • Une proposition de Lightning talk pour l’agile tour nantes ! Ca c’est pour très bientôt, mais les délibérations pour l’acceptation des sessions ne seront connues que le 17 Septembre. J’ai horreur du travail à la chaine, je ne soumet donc mon sujet qu’à un seul évènement, avec l’espoir qu’il sera retenu. Nous verrons bien.

A très bientôt !

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

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

Note de lecture : Agile Coaching, par Rachel Davies & Liz Sedley

Note : 5 ; Une vision claire de ce qui est nécessaire à un projet agile, mais un texte plutôt entre la conduite de projet et le coaching proprement dit.

Coacher une équipe pour la rendre agile est sans aucun doute un exercice difficile. Que faire ? Comment interférer, comment aider l’équipe à se prendre en main, à quel moment faut-il faire preuve de fermeté ? Bref, faire les bonnes actions, adopter les bonnes approches et les bonnes attitudes ne sont pas choses aisées et la frontière entre le succès et l’échec est parfois bien mince.

L’objectif de ce nouvel opus des pragmatic programmers est d’aider le coach à agir de manière opportune le long des pratiques agiles classiques. L’écueil de ce type d’ouvrage est de tomber dans une nouvelle description des pratiques agiles en négligeant la façon dont le coach doit ou peut entreprendre l’équipe sur chacun de ces sujets.

Je ne vais pas revenir sur chacun des chapitres, il y en a 14, pour 200 pages, sachez donc que la brièveté des chapitres joue en faveur de l’efficacité du texte et donne un rythme à la lecture, celle-ci n’est donc pas pesante. Je peux toutefois dire quelques mots à propos des 4 parties qui découpent le livre.

La première partie (ainsi que la dernières) sont celles qui concernent réellement la partie coaching « humain ». Les 4 chapitres couverts sur 58 pages sont consacrées au travail avec les personnes et avec les équipes. Le parti pris est ici de « coacher par l’exemple » et non de se ternir en retrait. Bien sûr l’observation, le feedback et la communication font partie des outils abordés. C’est fort peu à propos que je parle d’outil, car le texte montre plutôt des directives et si j’ai certaines idées générales une fois la dernière page tournée, je me suis quand même senti plutôt démuni.

La seconde partie nous montre clairement que l’expérience des auteurs vient plus des projets agiles que du pur coaching. En effet cette partie est consacrée aux pratiques de projet : planning meeting, stand-up, etc… Le tout sur 4 chapitres et un nombre de pages qui va de pair avec la première partie. Ici on est en terrain solide et les auteurs savent parler de la matière. Dommage que la matière n’ait plus l’attrait de la nouveauté car ces sujets ont déjà été largement traités par ailleurs. Le texte est intéressant mais devrait prendre place dans un ouvrage sur les projets agiles plus que dans un texte consacré au coaching.

Un pas plus loin, la troisième partie traité des pratiques de craftmanship : qualité du code, build, définition du « done ». Là encore les auteurs connaissent leur sujet, mais on en est plus à donner des conseils sur les pratiques de développement qu’à guider l’équipe ou ses membres.

La quatrième partie est dédiée au feedback : démo, rétrospective et progression du coach lui-même. Le chapitre sur la démo est dans la continuité des chapitres précédents, donc d’avantage lié à la conduite de projet qu’au coaching tandis que le chapitre sur la rétrospective, s’il est plus dans la continuité de ce à quoi je m’attendais n’est qu’un condensé de « Agile retrospective » d’Esther Derby, lecture que l’on préfèrera. Cette partie me laisse un goût d’inachevé.

Au final, le bilan est assez mitigé. J’ai trouvé que l’ouvrage insistait trop sur les pratiques déjà bien connues : standup, planning meeting, rétrospectives, démonstrations, ainsi que sur les activités d’ingénierie (build, design, tests). Fort heureusement, le tout est émaillé de conseils et d’histoires venant de l’expérience des auteurs. Mais ceux-cis ne constituent pas une part assez importante du livre à mon goût. J’avoue avoir quand même apprécié les sections « hurdle » et « check-list » à la fin de chaque chapitre.

Si je semble quelque peu déçu (et peut-être un peu sévère dans a notation), c’est sûrement que j’attendais beaucoup de ce livre en particulier et du « pragmatic bookshelf » en général, dont la qualité s’avère quand même élevée de manière récurrente. Mais je n’irais pas jusqu’à déconseiller la lecture de ce livre. Au pire, vous y aurez appris des choses sans consacrer trop de temps à la lecture !

agile-coaching-pragprog

Référence complète : Agile Coaching – Rachel Davies & Liz Sedley – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 643 2

Agile Coaching


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

Mes retours sur l’Agile Day Valtech 2012

Ce 19 Juin 2012, Valtech nous accueillait dans ses locaux du 103 rue de Grenelle pour une journée de présentations et d’atliers dédiés à l’agilité. Quelques retours.

Keynote

C’est toujours quelque chose d’écouter Laurent Sarrazin ! Il y a du dynamisme, de la substance, beaucoup d’anglicisme et des phrases choc ! C’est sous un format singulièrement raccourcis que Laurent nous a présenté Sweet Rupture qu’il avait déjà joué au Scrum Day. Je n’avais alors assisté qu’à une partie de cette présentation. Ici, j’ai tout vu, mais en accéléré !

Laurent nous raconte l’odyssée du centre agile de la société générale et ses nombreuses sources d’inspiration qui en font de “l’agilité Benetton” selon ses propres mots. Difficile de raconter cette session, je vous propose plutôt d’en visonner la version longue  celle du Scrum Day.

Kanban game

Laurent Morisseau est probablement l’une des personnes les plus pointues en France sur l’application de Kanban en France. Il est d’ailleurs l’auteur d’un livre qui arrive en librairie ces jours-ci : Kanban pour l’IT. Vous devriez d’ailleurs avoir droit à une note de lecture à ce sujet dans euh … un certain délais, car Laurent a eu la gentillesse de m’en faire parvenir un exemplaire !

Cet agile game est désormais un classique, car Laurent a déjà joué le Kanban Game à de nombreuses reprises. Toutefois je n’avais jamais eu la possibilité d’y participer. J’étais donc bien décidé à combler cette lacune.

Je n’ai pas été déçu, d’autant que Laurent et son complice Dimitri Baeli (visiblement faire collaborer Bretons et Normands est donc possible) sont rompus à l’exercice. Nous avons donc exécuté par équipe de 6, 8 itérations de développement afin de délivrer de la valeur, mais surtout de l’argent (eh oui : la valeur délivrée tôt capitalise et rapporte plus…). Voici ce que j’en ai trouvé:

  • Le jeu est intéressant et prenant, la qualité de l’animation aide sans aucun doute !
  • Des équipes de 6, c’est un peu trop: on se marche sur les pieds et cela génère trop de discussions quand aux différents choix !
  • Le jeu met bien en évidence les “limites de WIP” et le focus sur le flux et les goulots d’étranglements.
  • L’aspect “comptabilité” est un peu complexe et ce n’est pas évident d’en tirer les enseignements. Au minimum, il aurait fallu passer plus de temps (encore !) pour les décoder.
  • Le timing était un peu trop serré, mais c’était lié à l’agenda spécifique de cet Agile Day. Les conditions normales requièrent un peu plus de temps.

Bref, je suis satisfait de cet agile game qui matérialise très bien les aspects principaux du Kanban.

Outside in Design : the BDD way

Cette session présentée par Marcus Anhve de Valtech Suède était pour moi la session hard core de cette journée ! Concrètement, cette session dédiée au Behaviour Driven Developement par l’exemple était d’un abord ardu pour moi : Marcus a réalisé ses exemples en Ruby (que je ne connais pas), en y ajoutant du Rails, de la compilation avec Rake  et évidemment du RSpec pour l’acceptance testing ! Sans oublier un moteur de templating pour le HTML que j’ai justement oublié …

Bref, au-delà de la présentation d’introduction il me fut très difficile de suivre le fil, j’ai juste réussi à ne pas être complètement noyé. Respect pour notre très cool présentateur qui a réussi à faire du “par l’exemple” avec absolument aucun code préparé à l’avance et en réalisant absolument tout en live ! Franchement il faut le faire et c’est la première fois que je le vois ainsi fait intégralement. Marcus m’a confié qu’à son avis c’est vraiment la bonne façon d’exposer la façon dont on avance et on construit les choses : de le faire sans tricher !

Innovation needs waste

Ce fut ma sesion préférée de la journée ! L’animateur de cette session, Dirk Lässig de Valtech Germany était venu nous initier au Design Thinking. Dirk a intelligemment combiné une présentation limpide avec un exercice hélas un peu trop sous la contrainte du temps !

Le Design Thinking, quest-ce que c’est ? Une approche et un ensemble de pratiques pour permettre l’innovation radicale, celle qui n’est pas une simple amélioration d’idées existante mais l’émergence d’un concept nouveau en rupture avec l’existant !

Les approches agiles parlent souvent de “vison” et de son importance. Mais d’où vient-elle ? D’une personne particulièrement géniale qui l’a sortie de son chapeau à l’aide d’un quelconque tour de magie ? Faire émerger les Visions innovantes ne doit plus être comme le-boulot-de-quelqun-d’autre-car-nous-on-écrit-du-code ! Le design thinking nous apprend à mettre ensemble des personnes d’horizons différents justement pour élargir le champs du possible. Et justement pour élargir ce champs il faut générer des idées sans se censurer, même si au final la plupart et peut-être même toutes seront écartées.

Nous avons donc tenté (avec un succès mitigé, je le crains) d’abord d’identifier des cibles et des contextes d’utilisation pour une application smartphone, puis de développer ce concept à l’aide de techniques de brainstorming. Bien sûr en si peu de temps, il ne pouvait s’agir que de jeux de l’esprit. Toutefois un peu plus de temps aurait certainement produit un résultat plus pertinent.

Mais j’ai appris une nouvelle chose, un nouveau territoire à explorer qui fait le lien avec d’autres que je connais. J’ai aussi remarqué et apprécié la synergie très importante entre cette approche et le Lean Startup. D’ailleurs cette technique est fugitivement évoquée dans le livre d’Eric Ries. Ici aussi on parle d’emettre une hypothèse, de confronter celle-ci à la réalité le plus vite possible, d’apprendre sur cette base et d’itérer en s’appuyant sur ce que l’on a appris.

Bravo Dirk !

L’agilité au service du marketing, une révolution en marche

Une mauvaise pioche m’a fait choisir cette session que j’ai trouvé la plus décevante de la journée ! J’étais impatient de voir et comprendre l’agilité projeté dans le domaine du marketing. Hélas la présentation de Laura Guillemin manquait cruellement de substance ! Certes, la bonne idée de cette présentation était d’y faire participer des acteurs métier (mais aussi un consultant). Alors oui, on peut facilmement se douter que les plan marketing à long terme se voient balayés par les itérations rapides et les possibilités qui nous sont offertes de mesurer les impacts dans l’économie numérique ! Mais même un gros bourrin d’informaticien comme moi sait cela depuis longtemps.

Il existe une substance, des concepts dans le marketing numérique dont j’ignore même l’existence. Un question venant de la salle (mais vite balayée) sur les modèles d’attribution en a été l’un des exemples. Bref, je n’ai rien appris !

Keynote de cloture

A la session de Laura Guillemin, j’ai largement préféré la cloture que nous a proposé Scott Brinker ! Difficile de résumer cette intervention vraiment très riche. Je vous recommande la présentation qui est en lien, ce support est vraiment très bon (avec un petit arrêt sur le slide 16). Le(s) message(s) de base de cette présentation est (sont):

  • Tout est marketing !
  • Tout le monde doit être agile !

Un grand merci à Valtech d’avoir organisé cette journée !

Note de lecture : Agile Estimating and Planning, par Mike Cohn

Note: 8; La mine d’information de la gestion de projets agile

Déjà auteur d’un ouvrage sur les “User Stories” (et futur auteur d’un autre livre sur la transition vers Scrum) Mike Cohn nous livre ici un texte complet sur les estimations et la planification agile, et c’est vraiment une bonne surprise. A la différence de certains livres qui entretiennent un flou artistique, l’auteur a vraiment fait l’effort de couvrir le terrain du sujet, en découpant le texte en 7 parties, qui totalisent 23 Chapitres (soit 312 pages) !

La première partie “problems and goals” traite des défaillances de la planification classique, pourquoi elle échoue et en quoi l’approche agile est radicalement différente. Les 3 chapitres constituant cette première partie se résument à 32 pages. On débute par la question de l’estimation par le biais du cône d’incertitude. De là, le chapitre 2 aborde les causes d’échec des estimations classiques : multitâche, ignorance des dépendances et estimations se transformant en engagements ! On conclut logiquement cette première partie par un chapitre 3 mettant en relief les vertus de l’approche agile : planification à plusieurs niveaux, boucle de feedback, planification par la valeur métier.

La seconde partie traite de l’estimation. Forte de 5 chapitres totalisant 44 pages, l’auteur a réellement privilégié ici les petits chapitres, condensés et efficaces ! Les deux premiers chapitres expliquent l’approche de l’estimation en “story points” puis en “jours idéaux”, avant d’aborder les techniques collaboratives (planning poker, analogies, wide band delphy, etc.). Plus original, le chapitre 7 évoque la réestimation ! Cette partie se conclut logiquement par une discussion du choix entre story points et jours idéaux.

Prioriser par la valeur est le thème de la troisième partie (50 pages, 4 chapitres). C’est à mon avis la partie la plus ludique de l’ouvrage, car on y découvre l’évaluation par le modèle des cash flows, l’utilisation d’abaques « risque vs valeur » ou encore l’utilisation du modèle de Kano. L’utilisation de ces techniques révèlent parfois certaines user stories comme ambivalentes. Le dernier chapitre de cette partie traite du découpage de ces stories.

Avec la quatrième partie, on aborder le second grand thème du livre : la planification. Il est logique que cette partie soit la plus longue, avec 80 pages découpées en 6 chapitres. Les deux premiers chapitres couvrent les deux niveaux principaux de la planification agile : le release plan, puis la planification d’itération. Les autres aspects couverts dans cette partie sont l’évaluation de la vélocité et les problématiques de synchronisation entre équipes (buffering, planification avec plusieurs équipes). Cette quatrième partie est assez dense, croyez-moi !

C’est au suivi de la réalisation qu’est consacré la cinquième partie. Ce n’est pas un sujet sur lequel l’approche agile met un accent particulier, aussi est-il logique qu’il ne couvre que 34 pages (3 chapitres). Bien entendu, on y parle burndown charts, suivi de l’accomplissement des tâches et communication avec le management.

Les sixième et septièmes parties ne comportent qu’un seul chapitre chacune. Si la sixième partie forme une sorte de conclusion (ou devrais-je dire d’ode) à la planification agile en en listant les qualités, La dernière partie reprend elle l’ensemble des thèmes via une étude de cas. Ce chapitre (assez long) est intéressant car il recolle les morceaux directement en situation, l’ensemble étant narré via des dialogues entre membres d’une équipe de développement, le management et un coach.

On pourrait en douter de prime abord, mais l’estimation et la planification agile couvrent un grand nombre de sujets et de techniques. Le tour de force de l’auteur est de nous présenter une boite à outil très complète de manière concise, efficace et agréable à lire.

C’est tout simplement un incontournable d’une bibliothèque « agile » digne de ce nom!

agile-estimating-planning

Référence complète : Agile Estimating and Planning – Mike Cohn – Prentice Hall 2006 – ISBN: 0-13-147941-5; EAN: 978-0-131- 47941-8

Agile Estimating and Planning


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

Portfolio agile : de la visibilité au pilotage, par Caroline Damour-Nobi

Caroline Damour-Nobi a eu la gentillesse de m’autoriser à faire figurer sa présentation dans mon blog.
La gestion d’un portefeuille de projets est un sujet difficile, tiraillé entre les vertus de vision et de transparence qu’elle apporte et l’idée de “stock” qu’elle sous-tend ! Cette présentation fait le point sur la démarche et l’évolution de la mise en place de la roadmap telle que l’a vécue Caroline.

Note de lecture : Agile Adoption Patterns, a roadmap to organisational success, par Amr Elssamadisy

Note : 4 ; Le pattern ne fait pas le moine !

Etant à la fois amateur de patterns et de méthodes agiles, je me faisais un plaisir d’aborder cet ouvrage. De plus, Amir est un excellent ex-collègue que j’ai eu le plaisir de rencontrer. J’ai pu apprécier sa maîtrise du sujet et aussi sa grande humilité. Ce livra n’en reste pas moins une déception.

Les deux premières parties sont dédiées à une présentation générale (mais plutôt agréable) des valeurs et du sens de l’agilité, tandis que la seconde partie est consacrée aux « stratégies d’adoption ». Les deux axes en sont la valeur métier et les « mauvaises odeurs » conduisant à une direction / stratégie d’adoption. Cette partie se conclue par des propositions de roadmaps s’appuyant sur les patterns présentés au long des parties suivantes.

La troisième partie est forte de 38 chapitres couvrant 37 patterns (et un chapitre introductif) construits selon la forme dite « alexandrienne ». Ces patterns couvrent de très nombreux aspects des pratiques agiles, sinon toutes. Depuis la capture des besoins jusqu’aux pratiques de développements en passant par les pratiques supports telles que l’intégration continue, le rythme du projet, etc… Chacun de ces patterns traite de manière réduite (donc concentrée) chaque pratique en mettant l’accent sur les points forts et faibles de celles-ci. J’avoue avoir trouvé difficile de faire le lien entre les patterns, et ce malgré les roadmaps. La partie « sketch » sensée donner un contexte au pattern est hélas à mon goût trop stéréotypé : on croit entrer dans un monde où tout est parfait. Telle n’est pas mon expérience.

Les deux chapitres finaux consacrés aux retours d’expérience valent le détour : il s’agit tout simplement des rapports d’audit et de rétrospective de l’auteur sans aucun habillage ni concession. Outre qu’il met en évidence le travail de consulting de l’auteur il met aussi en lumière la réalité du terrain de l’adoption de l’agilité.

Ma déception face à cet ouvrage est probablement due au fait que ce texte ne s’adresse pas à moi ! J’ai ainsi eu du mal à y fixer mon intérêt. Un nouveau venu dans cet univers aura probablement un autre regard !

agile-adoption-patterns

Référence complète : Agile Adoption Patterns, a roadmap to organisational success – Amr Elssamadisy – Addison Wesley 2008 – ISBN : 0-321-51452-1 ; EAN : 978 032 151452 3

Agile Adoption Patterns: A Roadmap to Organizational Success


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