Note de lecture : Improv-ing Agile Teams, par Paul Goddard

Note : 6 ; Quelques petites choses à récupérer du théâtre d’improvisation.

Ce petit opuscule a pour objectif de décoder les éléments principaux du théatre d’improvisation pour exposer la manière dont ils s’appliquent dans le cadre de coaching d’équipes agiles. S’il m’a été chaudement recommandé par Tobias Mayer, je n’en ressort pas avec autant d’enthousiasme que lui. L’opuscule, de petit format, compte moins de 200 pages, annexes comprises. Il est vite lu. La partie principale compte seulement 5 chapitres pour moins de 170 pages, mais chacun de ces chapitres compte une partie principale et une partie jeu.

Du sous-titre « using constraints to unlock créativity », l’auteur a retenu la lettre « S » : l’avant-propos n’en contient aucune occurrence, tandis que chacun des chapitres principaux commence au contraire par cette lettre ! Les trente pages du premier chapitre sont intitulées « Safety ». C’est de confiance et de droit à l’erreur dont il est question ici. Ma partie préférée concerne ici le « slowing down », un élément dans lequel je me reconnaît ! Sur les jeux proposés, si le préféré de l’auteur est le « daily Tand Up » où l’on doit éviter d’utiliser la lettre « s » (encore), j’aime bien pour ma part le « psychic stand up » où l’on doit énoncer l’avancement à la place d’un collègue !

Lire la suite

Publicités

Note de lecture : Facilitating with Ease ! 3rd edition, par Ingrid Bens

Note : 7 ; Une véritable référence sur la facilitation de réunions !

Plus qu’un livre, c’est un support de cours ! Ou plus exactement, c’est les deux à la fois. Et sous un format inhabituel (à commencer par le « grand format » physique du livre), j’ai vraiment trouvé là un texte de référence sur la facilitation de réunions. Le tout en 227 pages sur 9 chapitres.

Le 1er chapitre est une introduction à la facilitation, pour mieux appréhender ce que l’on attends d’un facilitateur et quelle doit être sa posture. Les 36 pages de ce premier chapitre sont un raccourcis sur le reste de l’ouvrage et se terminent par un exercice d’auto-évaluation très bien fait.

Le second chapitre focalise sur la posture du facilitateur sur une douzaine de pages. Ce point qui avait été introduit au premier chapitre est ici développé : le facilitateur doit-il être interne ou externe ? Peut-il être un manager, avec une posture haute ? Quelle sont les challenges auxquels doit faire face le facilitateur ? Après avoir fait le tour de ces questions, cette notions un peu floue de posture acquiert une réalité plus tangible.

Lire la suite

La facilitation en kit

Ce “falititator toolkit” donne de nombreuses clés pour appréhender et focaliser la dynamique des groupes. Plus qu’un simple article, il s’agit-là d’un mini-book regroupant le “best of” des auteurs en matière de facilitation. J’ai apprécié la concision et l’efficacité du propos dans chacune des parties abordées:

Le rôle du facilitateur : en une seule page, les responsabilités et ses challenges !

La dynamique de groupe : elle s’articule autour du modèle de Tuckman, reprends la liste des bons et des mauvais comportements et les schémas d’intervention.Le tout en moins de 5 pages.

Idéation et consensus : on aborde ici le coeur de l’ouvrage et les outils qui le constitue : l’art de l’écoute, le “focused conversation”, “appreciative inquiry”, Le brainstorm, le consensus, le processus d’affinité. On a du mal à se rendre compte que l’on a couvert tout ça en 11 pages !

Les réunions efficaces : On balaye les états d’esprit, la check-list (avant, pendant et après), les rôles et règles et les comportements. J’aurais cru cette partie plus riche, mais là encore ce chapitre ne fait que 6 pages.
Gestion de projet: Une page … dont je ne comprend pas ce qu’elle fait là !
Stakeholders input tools : Elles tournent beaucoup autour du Focus group et un peu autour du Web Survey (plus pour faire la pub d’un outil dirait-on). En 6 pages, c’est quand même bien.

Outils pour collecter et analyser les données : quelques outils sont proposés, ils sont bons à rappeler même s’ils sont assez classiques : check sheet, importance / satisfaction diagrams, analyse causale, diagrammes d’interrelation, analyse SWOT.
Flowcharting: Il est assez curieux de trouver ici ces 3 pages sur les flow charts diagrams ici. Cela a bien peu à voir avec la facilitation proprement dite…

Outils de prise de décision : Sans être mortel, ce chapitre nous donne ou rappelle quelques outils : matrice de critères, analyse “force field”, Notation 0 à 10, matrice impact / effort.

Mesurer les impacts : On est plus ici dans la déclaration d’intention. Ou plus exactement, il s’agit d’introduire le matériel fourni en annexe qui d’ailleurs vaut aussi bien le coup !

Bref un papier remarquable qu’il serait dommage de négliger, même si 2 ou 3 parties sont un peu plus faibles ou n’ont simplement pas leur place.

La plupart des outils sont décrits de manière introductive, voir un peu plus. En fait, ce qui est fourni ici est largement suffisant pour démarrer, mais les auteurs donnent aussi les pointeurs pour aller plus loin !

Bonne lecture !

La boite à outil du coach agile

Besoin d’étoffer votre boite à outil de coaching ? Voici des conseils avisés de la part de nos pairs !

Des outils de coaching pour améliorer la dynamique de votre équipe

Cette présentation de JF Hélie et Guillaume Duquesnay a été donnée à Agile France 2012

20 coaching tips in my agile suitcase

Cette fois c’est Yves Hanoulles qui nous délivre une série de recommandations.

Agile coaching workshop

Workshop monté par Craig Smith

Du chef de projet au coach agile

Ces deux vidéos nous ont propos&ées par Lissa Adkins. Il s’agit d’une retranscription d’un workshop donné à Chicogo en 2008 lors d’un Scrum GatherinG

Il s’agit de réflexions à propos de ce que cela signifie réellement de devenir coach agile.

Solution focus

S’intéresser à la solution plutôt qu’au problème et en rechercher les prémisses dans la réalité présente, tel est la ligne directrice du Solution Focus. Vous pouvez aussi vous reporter à la note de lecture que j’avais rédigé sur Coaching Plain & Simple.

Wu Wei Coaching

Je le place ici par pure curiosité. Car en fait, je n’ai toujours pas compris de quoi il retournait ! “Wu Wei” signifie “sans action”. Et en fait, comme il est indiqué à la fin de cette présentation, celle-ci ne vous aidera pas à comprendre ce que c’est !

Retours sur Agile France 2013, 2nd partie (en images)

Nous avons évoqué, il y a peu le début de matinée de la conférence Agile France 2013. Il est temps de reprendre notre bâton de pellerin et de poursuivre plus avant.

Mais avant cela, j’aimerais saleur l’équipe d’organisation. Je n’ai pu les prendre en photo tous. En fait, c’est la photo que j’ai où ils figurent !

agileFrance2013-06Pezziardi02

Grand merci à Eric, Ellène, Stéphanie, Caroline, Damien, Jonathan et Frédéric. Ils essaient tant de se faire discrets qu’il est difficile d’avoir la liste exacte !

Je dois vous avouer une chose : il y a certains orateurs que j’essaie de voir coûte que coûte. Je ne regarde pas le résumé de leur session, en fait je n’en regarde même pas le titre. Je viens sans me poser de question et je n’ai jamais été déçu. Quatre d’entre eux étaient présents sur ces 2 jours, bien répartis : 2 le Jeudi et 2 le vendredi. Coup de chance, pas de chevauchement entre leurs sessions. Vous découvrirez les autres plus tard, mais Pascal est l’un d’entre-eux.

Pascal Van Cauwenberghe : Real options

Quand et comment (ne pas) prendre des décisions

Les options réelles sont le pendant des options financières. Elles permettent :

  • D’exercer un décision à une date future
  • C’est un droit (et non un devoir) d’exercer ce choix à cette date future.
  • Ce droit s’achète cash à l’instant présent (c’est la prime).
  • L’exercice de l’option s’accompagne d’un coût (le prix de l’option) et d’un bénéfice éventuel.

Pour illustrer tout cela, Pascal va nous raconter des histoires. Il y en aura 3.

agileFrance2013-05VanCauwenberghe01

Un choix de design embarrassant

Notre première histoire nous emène dans le monde du jeu video en ligne pour les enfants. La date de sortie est fixée, la période de Noel est cruciale, on ne saurait la rater. Le contenu du jeu est à peu près dans les rails. Mais les créatifs veulent changer d’identité visuelle, mais ils ne sont pas sûrs, mais…

C’est là que rentrent en compte les options réelles : on veut pouvoir décider aussi tard que possible. Mais cela a un prix.

Ici, l’idée consiste à rendre la décision facile à changer. Le prix est donc un refactoring permettant un changement facile du design. Ce prix nous donne droit de retarder le moment ou il faudra arrêter la décision définitive. Une leçon importante à retenir :

Il faut payer le prix pour des options qui ont de la valeur.

Cette démarche débouche sur plusieurs conséquences :

  • La réalisation des tranches fonctionnelles est pensée en terme de rétro-planning par rapport à la date à laquelle on doit opérer le changement de design.
  • Une question pour le développement : est-on obligé d’appliquer le design dès le début ? En fait non. Le développement sera entièrement fait en noir et blanc. En fait, cette situation embarassante aura débouché sur une évolution du processus de développement: dorénavant, tous les développement seront fait en noir et blanc avec application du design à la fin !
  • Nécessité de traquer l’évolution de cette option toutes les deux semaines afin de voir si on dispose de plus d’information quand à son exercice ou non.

Le processus de suivi de ces options est le Real Options Optimal Decision Process décrit dans le livre Commitment.

Set-based development

Dans ce second projet, le challenge est différent : un service doit être développé, le temps est critique (comme toujours). Hélas le choix de la plateforme n’est pas encore arrêté. Mais on ne peut se permettre de mettre le projet en stand-by en attendant ce choix, le projet est trop critique !

Comment faire ?

Il suffit d’implémenter toutes les options ! En clair cela signifie :

  • Faire le développement sur des API isolant la plateforme. Ces API sont mises en places au fur et à mesure de l’avancement du projet.
  • Opérer parallèlement l’implémentation de ces APIs sur toutes les plateformes qui forment l’ensemble de nos option (deux dans le cas présent)

Un effet de bord positif est que cette approche simplifie le test du service, car parallèlement on va implémenter un “test server” qui est en fait un “mock” de la plateforme.

Plus tard le choix de la plateforme est arrêté. On se focalise alors sur l’une des implémentations de l’API.

L’histoire ne s’arrête pas là. Par le jeu des fusions / acquisitions d’éditeurs, l’éditeur de le seconde plateforme rachètera la plateforme A … et demandera à ses clients de migrer vers la plateforme B. Le Set-Based design rendra cela facile !

Plus tard, cet éditeur B sera lui-même … vous m’avez compris !

Une histoire d’intégration

La troisième histoire est celle d’un projet en retard. Le retard est déjà de 3 mois, il en faut encore 6 ! Arrêter ou poursuivre ?

Il y a des décisions à prendre, et celles-ci ne doivent pas tenir compte de l’investissement déjà réalisé : il faut le considérer comme perdu. C’est le Sunk Cost Fallacy. On a pratiquement toujours tendance à surestimer la valeur de ce que l’on a. La valeur n’est pas le coût.

Une histoire d’EDI, une question d’architecture

L’EDI permet d’interconnecter des vendeurs et des fabricants. De chaque côté de la plateforme, vendeurs et fabricants doivent implémenter l’API avant que l’éditeur customise celle-ci.

Malheureusement pour chaque partie prenante, l’implementation de l’API est un gros projet, donc subordonné aux retards qui sont le lot des gros projets. Comme la customisation de la plateforme est tributaire de l’implémentation des API de chaque côté, la planification de ce travail ne sert à rien !

L’intégration dure longtemps, car elle est conséquente et n’intervient qu’une fois que chacun a fait son travail. Que faire ?

Ne plus faire de gros projets ! Au lieu de mettre en production toute une connexion vendeur / fabricant, ne peut-on déployer flux par flux ? Les objets métiers nécessaires à ces flux seront développés de manièreincrémentale, et seulement ceux dont on a besoin pour le flux en cours. Par contre ils pourront être réutilisés pour les flux suivants.

Pour Pascal, changer d’architecture, de plateforme ou de langage implique les points suivants:

  • Faire un prototype pour maitriser le concept ou la technologie.
  • Commencer par les aspects les moins critiques.
  • Garder l’ancien composant.
  • Opérer un déploiement incrémental.

Vous l’aurez peut-être remarqué, cela rejoint certains points de la présentation de Cyrille Martraire (voir mes retours dans la 1ère partie).

Avec l’éclairage des options, Pacal nous soumet ce qu’il juge être les vertus d’une bonne architecture :

  • Elle doit nous permettre de prendre tôt les décisions faciles à changer.
  • Elle doit permettre de prendre tard les décisions difficile à changer. Ou encore : rendre les décisions difficiles à changer pour qu’elles deviennent faciles à changer !
  • Elle permet l’effort minimal, c’est le YAGNI d’extreme programming.
  • Elle créé des options pour l’équipe et/ou pour l’entreprise.
  • Elle se construit et s’améliore tous les jours, à petits pas. Sinon, on crée du legacy !

Il ne faut pas mésestimer la valeur des conditions contrariantes que l’on nous impose. Elles nous servent et nous apprennent souvent quelque chose.

Dans les mauvaises décisions se cachent de bonnes décisions.

Les techniques utiles

Une simple liste des techniques et principes abordées dans cette session :

Pascal avait déjà donné cette présentation lors de Devoxx France, fin Mars. Voici le support de présentation qu’il avait alors utilisé. Le contenu est identique à la présentation faite ici.

Lectures recommandées

Pierre Pezziardi – Agilité : do the wrong thing faster

Pierre Pezziardi n’est pas n’importe qui : co-fondateur d’Octo Technology, puis DSI de la BRED, puis actuellement start-uper, on peut dire qu’il a de l’envergure. C’est aussi un orateur de grande qualité, comme j’avais pu le constater lors d’une soirée organisée par l’institut agile : pertinent, incisif, riche d’enseignements. Je n’ai donc pas vraiment hésité à aller l’écouter.

agileFrance2013-06Pezziardi03

Sans aller jusqu’à m’avouer déçu, je dois dire que la session a été un peu en-deça de mes attentes. L’orateur a voulu cette session interactive, ce qui est en principe une bonne chose. Peut-être les interventions de la salle plus souvent conotées “coach / consultant” que “retour terrain” ont-elles participé à cette impression mitigée ? Honnêtement, j’ai un peu de mal à le dire.

Plutôt que de tenter retracer cette session (ce que je serais bien en peine de faire), je vais plus simplement livrer mon “take away” de cette session.

On peut faire de l’informatique et créer zéro valeur

Qui décide quel projet faire ?

A quel point les vrais utilisateurs sont impliqués ?

Le logiciel qui est produit va-t-il faire la différence chez les utilisateurs ? Hélas pas si souvent que ça…

L’unique mesure de la valeur, c’est le regard de l’usager

Des applications en pré-production que les utilisateurs détournent pour un usage en production. Des utilisateurs déclarant que l’application X a changé leur façon de travailler ou qu’elle leur permet de consacrer leur temps à des tâches plus valorisantes…

Des exemples venus de l’assistance ont permi d’illustrer ce point.

La pensée systémique est différente de la pensée analytique

Pierre a évoqué des grands projets publiques permettant des améliorations … pour une catégorie de population, hélas au prix de plus de souffrances pour d’autres population !

Apporter de la valeur ne doit pas se mesurer localement, il faut prendre en compte l’ensemble de l’écosystème concerné, donc avoir une approche systémique par opposition à l’approche purement analytique.

Etre acteur du changement

Sommes-nous trop petits, trop insignifiants pour pouvoir changer les choses. La réponse de Pierre est claire : Non ! Pierre est engagé dans une démarche entrepreunariale pour changer les choses, mais tout le monde n’est pas dans cette logique là. Et l’on peut tenter des choses, même petites pour les améliorer. Par exemple en collaborant avec des personnes au-delà des frontières organisationnelles. Je citerais Pierre concernant l’alternative:

Tu peux rester où tu es à te plaindre et à souffrir. Dans ce cas, bonne chance car t’as encore 30 ans à tirer !

Je ne rends pas justice à Pierre avec mes notes, car son intervention était bien plus intéressante qu’il n’y parait ici. Soyez certain que je retournerais l’écouter quand j’en aurais l’occasion !

A table !

On est toujours bien reçu à Agile France, et déjeuner autour d’une table avec un vrai repas et un service tranche avec les conférences auxquelles nous sommes habitués. Et puis, ça a de la gueule, jugez-en !

agileFrance2013-07LunchJeudi02

Bien sûr, ce moment de convivialité est l’occasion de nouer des contacts. N’esperez-pas que je vous en dise plus : ça va rester entre moi en mon LinkedIn !

agileFrance2013-07LunchJeudi01

Fin de la pause, retour aux affaires. Ca va parler coaching pour débuter l’après-midi

Jean-François Hélie : Votre nouveau défi, déployer l’agilité dans votre organisation

Votre organisation est-elle agile ?

A cette question on est souvent tenté de répondre “oui” (de toute façon, répondre “non” fait désordre). Souvent parce que l’on a déployé Scrum sur un, plusieurs, voir la totalité des projets. Généralement, ça marche un peu mieux qu’avant. Mais on est loin des améliorations radicales escomptées.

agileFrance2013-08Helie01

Voyons la démarche que Jean-François Hélie nous propose.

Opérer des rapprochements

Si on peut juger de seulement une “petite” amélioration, force est de constater que certains projets stratégiques marchent nettement mieux. Pourquoi ? Essentiellement parce que leur nature stratégique fait qu’ils ont moins de contraintes. Ils ont d’avantage le droit de franchir les frontières organisationnelles.

Tout cela est insuffisant, mais ces projets stratégiques nous donnent des indications :

  • Trop de cloisonnement interne DSI / Marketing / Métier
  • Pas de remise en cause fondamentale du processus projet
  • L’agilité reste cantonnée au niveau de la réalisation
  • Les projets sont mal cadrés et démarrent trop vite.

Sur ce dernier point, enfin tel qu’il est exprimé, je crains de ne pas être d’accord sur le fond. Je pense que Lean Startup a quelque chose à nous enseigner de ce côté. Sans doute devrais-je discuter avec Jean-François précisément là-dessus…

La difficulté fondamentale à faire tomber les cloisonnements a hélas une origine plus profonde.

Comprendre la culture

Comprendre les organisations, c’est comprendre leur culture. Celle-ci est étroitement liée aux niveaux de maturité :

  • De l’équipe
  • De l’organisation

Comme on aime bien les modèles, Jean-François nous propose celui de Richard Barett qui décrit 7 niveaux de conscience. Ce modèle étend en fait la célèbre pyramide de Maslow. La voici.

7levels

Pour Jean-François Hélie, l’agilité se situe au niveau 4, les niveaux au-dessus sont, disons, du bonus ! Pour arriver à ce niveau, 2 challenges :

  • La manager doit devenir facilitateur
  • L’ambition agile : comment se réaliser individuellement, en interaction avec les autres ?

Conjuguer le changement au présent

Jean-François n’a pas d’hésitation à ce propos : Le changement ne s’opère pas en planifiant ce qu’on pourra faire plus tard. Pas plus qu’il ne se construit en regardant ce que l’on a fait dans le passé. L’un sert à rêver, l’autre à se lamenter.

Seul compte l’instant présent, ce que l’on peut faire dans le contexte actuel.

Autre point important : le changement culturel s’amorce par le haut de la pyramide. En fait la dynamique des comités de direction reflète celle de la société.

  • Un comité de direction hésitant, qui ne sait dans quel direction aller donnera une société où les employés sont peu engagés et n’osent pas aller de l’avant.
  • Un comité de direction energique et focalisé engendrera une société dynamique avec des employés volontaires.

D’accord, c’est peut-être un peu caricatural, mais c’est l’idée.

Pour changer les projets, changeons les réunions

C’est le “take away” de cette session. Jean-François Hélie veut partager une de ses convictions avec nous et nous propose ses outils. A l’image de ce que l’on vient de dire pour les comités de direction, les réunions de projet sont le poul du projet.

A l’inverse, on peut agir sur un projet en agissant sur la dynamique des réunions ! Une idée un peu déconcertante pour moi, mais intéressante. En tout cas, je n’y avais jamais pensé. Voyons comment réunions et projets sont les reflets l’un de l’autre :

  • La participation en réunion : Elle reflète l’energie et la motivation sur le projet.
  • La gestion du temps en réunion : Elle caractérise la façon dont est appréhendé le respect des délais.
  • La relation à l’animateur : Elle est un indicateur du respect de la hiérarchie.
  • La gestion des l’espace de la salle de réunion : Elle donne des informations sur les stratégies territoriales des uns et des autres.
  • Le processus de communication au cours de la réunion : Elle est un miroir des circuits d’information (qui parle après qui, etc..)
  • Le désir de quitter la réunion ave un résultat : Il est significatif de ce que peut délivrer le projet.

Pour amorcer les changements en réunion, le premier pas est la prise de conscience à la fin de celle-ci :

  • Qu’est-ce qui a bien fonctionné ?
  • Qu’est-ce qu’on peut améliorer ?
  • Qu’est-ce que l’animateur a bien fait ?

Dans la plupart des réunions “classiques” l’animateur de la réunion :

  • Définit l’objectif de la réunion
  • Dirige la discussion
  • Recadre celle-ci
  • Et la plupart du temps monopolise 80% du temps de parole.

Cela n’est pas très constructif, et en réalité ce genre de réunion est surtout informatif. Les autres participants ne sont pas engagés et en fait participent peu. D’où la généralisation des ordinateurs portables en réunion.

Lorsque l’animateur gère la réunion en mode participatif, les différences sont :

  • L’animateur invite les participants à prendre la parole
  • L’animateur ne garde le temps de parole que 20% du temps.

Dans la version Intelligence Collective (le nirvana des réunions, en quelque sorte), les rôles deviennent distribués :

  • Un facilitateur qui invite à participer et délègue les rôles.
  • Un pousse-décision qui suit les actions arrêtées et incite les participants à conclure une discussion par une action.
  • Un gardien du temps.
  • Un “meta” qui observe la dynamique du groupe et la posture des participants
  • Un leader. C’est toujours un peu le même, celui qui a une autorité naturelle sur le groupe du fait de son charisme ou de sa connaissance du sujet.

Déployer l’agilité dans l’organisation

Jean-François Hélie voit deux approches possibles :

L’approche structurelle : Elle débouche sur de grands efforts pour de petits effets.

L’approche culturelle et systémique : Elle permet d’obtenir de grands effets avec de petits efforts. Pour en résumer les clés :

  • Ne pas chercher à changer la culture en elle-même.
  • Changer la culture dans les réunions
  • Créer et partager une vision
  • Faire participer les collaborateurs

Et c’est tout !

Lecture recommandée

Un seul ouvrage ici :

A suivre…

Nous avons bien avancé dans notre première journée, il nous reste 2 sessions pour la compléter. A très bientôt !

Note de lecture : Agile Retrospectives, Making good teams great, par Esther Derby & Diana Larsen

Note : 7 ; Des patterns pour les rétrospective

Le « project retrospectives » est incontestablement l’ouvrage phare sur les rétrospectives de projets. Hélas, cette approche en grand était fort peu adaptée aux simples rétrospectives d’itération, destinées à être menées en une heure ou deux. Ce titre couvre cet aspect, entre autres choses. Certaines des pratiques évoquées sont également adaptées aux rétrospectives de release, mais sans un focus particulier sur ce dernier point. Tout comme le livre de Norman Kerth, celui-ci est construit en une suite d’activités que l’on peut sélectionner judicieusement. En fait, ces activités sont même présentés sous forme de patterns regroupés en 5 rubriques (les chapitres 4 à 9) qui sont autant de phases de la rétrospective :

Activities to set the stage : 4 activités sont proposées afin de démarrer la rétrospective et accueillir les participants.

Activities to gather data : Cette phase permet de collecter des données chiffrées ou qualitatives sur l’itération passée. Ce ne sont pas moins de 8 activités différentes (et interchangeables) qui sont offertes pour aboutir à cette fin.

Activities to generate insights : 9 activités sont proposées ici afin d’élaborer causes et conséquences du déroulement de l’itération.

Activities to decide what to do : Une rétrospective qui n’aboutit pas à un plan d’action n’a que peu de valeur. Ce sont 4 activités qui sont proposées ici pour aboutir à cette fin.

Activities to close the retrospective : Les 5 activités proposées ici permettent de conclure la rétrospective.

Au-delà de ces phases, cet opuscule de 160 pages complète le paysage par quelques mots sur les rétrospectives de release et de projet, et un panorama de l’environnement nécessaire à la menée des rétrospectives.

Cet ouvrage propose incontestablement des outils pour les rétrospectives, hélas l’exposé de ceux-ci est parfois bien léger. Quelques pages (de 2 à 4) sont consacrés à la description, avec un format invariant : But, durée nécessaire, description, étapes, matériel et préparation et exemples. Justement, la partie « exemples » pourrait être plus développée afin de décrire l’activité de façon moins abstraite. De même, toutes les activités ne se combinent pas entre elles, et lister les activités en entrée possible aurait bien aidé !

L’utilité de ce livre est incontestable, il est hélas plus léger que ce que les auteurs auraient été capables de produire. Je suggère de toute façon de commencer par lire le livre de Norman Kerth, il permet de bien comprendre la notion de rétrospective. Ce livre est certes différent car s’adressant à un type de rétrospectives différent, mais il est plus pertinent en complément du premier.

agile-retrospectives-pragprog

Référence complète : Agile Retrospectives, Making good teams great – Esther Derby & Diana Larsen – Pragmatic Bookshelf 2006 – ISBN : 0-9776166-4-9

Agile Retrospectives: Making Good Teams Great


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

Note de lecture : Project Retrospectives, a handbook for team reviews, par Norman Kerth

Note : 8 ; De l’or en pages ! Book of the Year 2006 !

La plupart du temps, quand un auteur traite un sujet, et plus encore lorsqu’il s’agit d’un sujet touchant au consulting, si cet auteur nous livre son savoir, il garde souvent pour lui son savoir-faire. Rien de tel ici, Norman Kerth nous lâche tout : ses trucs, sa façon de vendre les rétrospectives, l’attitude qu’il adopte dans certaines situations, absolument tout !

La rétrospective est une étape méconnue (et souvent méprisée) de la vie du projet : elle permet de tirer les enseignements positifs comme négatifs, du déroulement de celui-ci. C’est grâce aux rétrospectives qu’une organisation peut réaliser une démarche d’amélioration de ses processus. Après un rapide chapitre introductif traitant du besoin de rétrospectives, le livre débute réellement par un chapitre consacré à une présentation générale des rétrospectives, à l’aide d’une étude de cas fictive. Celle-ci campe très bien le contexte et permet de comprendre la progression d’une rétrospective. Les trois chapitres suivants sont consacrés aux étapes préalables : la vente, les choix et la préparation de la rétrospective.

Le chapitre 6 est de loin le plus long de ce livre, avec ses 70 pages. Il présente des exercices (il y en a 12) sous forme de patterns. Ce sont ces exercices qui forment la substance des rétrospectives. Ceux-ci sont largement expliqués, en termes de but, de contexte et de déroulement. Ils sont généralement illustrés par une expérience vécue qui ajoute encore à l’intérêt de l’exercice.

Les chapitres 7 et 8 sont consacrés aux postmortems: la rétrospective des projets ayant échoué et arrêtés avant leur terme. Les conditions psychologiques de tels projets ont amené Norman Kerth à adapter sa démarche et ses exercices à ces conditions particulières. On ne saurait conclure un tel ouvrage sans aborder les aspects de compétence du facilitateur : quelles qualités, quelle formation doit-il avoir, quelles compétences doit-il développer. Enfin, l’ouvrage se conclut sur les rétrospectives de rétrospectives et la manière de collecter ces expériences dans une organisation.

Vous l’aurez compris : cet ouvrage est non seulement complet sur le sujet, mais d’une substance hors norme, il s’agit pour moi d’un livre incontournable sur le sujet, qui doit absolument être lu par quiconque souhaite devenir facilitateur de rétrospectives.

project-retrospectives-dorsethouse

Référence complète : Project Retrospectives, a handbook for team reviews – Norman L. Kerth – Dorset House 2001 – ISBN: 0-932633-44-7

Project Retrospectives


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