Retours sur Agile France 2013, dernière partie (en images)

Dernière ligne droite pour cet Agile France 2013 !

Pour ceux qui n’auraient pas suivi les épisodes précédents, nous avons :

Les épisodes du Jeudi :

Pour le vendredi :

Projetons-nous directement au début d’après-midi où nous avons rendez-vous avec …

Laurent Bossavit : L’art d’avoir tort

Il manquait à notre main la quatrième carte de mon carré d’as. La voici. Il ne devrait pas être la peine de présenter Laurent Bossavit qui fut non seulement un des membres fondateurs de cette conférence, mais aussi une des figures marquantes de l’agilité en France depuis 12 ans ! Evangéliste, auteur, infatigable chercheur et bien d’autres choses encore, il est aussi à l’origine de l’institut Agile qui est aujourd’hui, selon ses propres mots, plus un hobby qu’un travail.

agileFrance2013-15Bossavit01

Laurent nous promet pour cet atelier :

  • 3 exercices interactifs (en fait, nous n’en ferons que deux, pour des questions de temps).
  • 1 super-pouvoir
  • 2 sites Web
  • 1 page de pub

Commençons par une question: pourquoi la question des estimations donne-t-elle lieu à tant de discussions enflammées (pour ne pas dire plus) ? Parce que l’on voir le monde en noir et blanc !

Le but de cet atelier est de sortir de ce mode de pensée binaire pour rentrer dans une logique probabiliste. C’est aussi grâce à ce mode de pensée que l’on va pouvoir se diriger vers une logique d’amélioration en travaillant sur nos intervals de confiance.

Assez pour l’introduction. Au boulot !

1er exercice

Ce premier exercice est largement inspiré d’un exercice de Steve McConnel extrait de cet ouvrage. L’objectif est de donner des réponses aux questions posées avec un interval de confiance de 90%. Allons-y !

agileFrance2013-15Bossavit02

En tant qu’informaticiens aguerris, nous savons que nous avons tendance à être optimistes. Plus amusant : en sachant cela et sachant même que l’exercice veut montrer cela, nous donnons dans le panneau. En relevant les copies, l’interval que nous avons voulu de 90% se révèle plutôt être de 50%. Votre serviteur n’a pas échappé à la chose : je n’ai réussi qu’un médiocre 5/10 !

Quel est notre problème ? C’est ce que Laurent appelle un “problème de calibration du hardware” !

Connais-toi toi-même

Voilà donc où il faut travailler : apprendre à connaitre notre propre cerveau : MON incertitude m’intéresse plus que les faits !

Dans son ouvrage “Expert Political Judgment”, Philip Tetlock présente des tests de pronostiques politiques auprès d’experts mondiaux reconnus. Les résultats parlent d’eux-mêmes:

  • 15% des évènements qualifiés “d’impossibles” par ces experts ont effectivement eu lieu.
  • 27% des évènement jugés par ces mêmes experts “d’absolument certains” ne se sont pas produits.

Le problème est un problème de calibration de l’écart de confiance. Dans le principe, il est facile à adresser: il suffit d’élargir l’interval de confiance !

Calibration = %confiance – %fausses réponses

Second exercice

Dans ce second exercice, Laurent nous propose une série d’affirmations. Nous devons nous prononcer sur celles-ci avec un pourcentage de confiance. On jauge nos réponses en utilisant le “score de Brier” originellement utilisé en météorologie. On obtient le moins de points en donnant réponse juste avec un pourcentage de confiance élevé, mais un maximum de points dans le cas contraire.

image

Le but est d’obtenir le minimum de points. On peut connaitre notre capacité de résolution à partir de là :

Résolution = %réponse vrais / %réponses fausses

En fait, ces deux exercices nous guident vers des directions qui peuvent paraître divergentes :

  • Je suis bien calibré : je ne me mouille pas dans mes estimations
  • Je veux m’améliorer en résolution : je dois me mouiller.

En travaillant sur ces deux fronts, nous allons acquérir notre super-pouvoir : SuperGeek !

super-geek2

Conclusions et références recommandée

Pour aller plus loin, il faut travailler, comme toujours ! Laurent nous propose de le faire via deux sites :

  • Pour enregistrer et suivre nos prédictions : predictionbook ; ça, c’est pour l’approche “fun”.
  • Philip Tetlock mène des études très sérieuses à l’aide de groupe de travail. On peut s’y joindre sur goodjudgement mais c’est visiblement assez prenant.

L’un des effets de bord positif de cet approche, de l’expérience même de Laurent, est qu’elle permet de prendre de la distance par rapport à un évènement à venir. Dans le cas de Laurent, un jugement au tribunal !

Quelques références bibliographiques :

C’est vrai, Laurent nous avait aussi promis une page de pub ! Elle concerne son livre paru sur LeanPub

Pour finir, qualques posts sur la même présentation, faite cettefois-ci lors du ScrumDay :

Alfred Almendra : Un peu d’UX pour innover efficacement

Alfred nous propose un atelier pour imaginer un MVP à la Lean Startup, en utilisant un peu d’UX !

Cet atelier est inspiré d’un atelier réalisé par Ariadna Font. Nous allons avoir un temps très limité pour réaliser une première ébauche de notre MVP. Plutôt qua de rentrer dans de longues explications, jetons-nous dans le bain ! 6 étapes en tout et pour tout. Et ça rigole pas ! Enfin si, quand même un peu…

Etape 1 : La carte d’empathie

On avait le choix entre deux sujets. Je suis très fier d’avoir convaincu les personnes de mon groupe d’avoir choisi un autre sujet : nous allons réaliser Funky Shirt, un service permettant de réaliser des chemises uniques et custosmisées … et bien sûr, Funky !

agileFrance2013-16Almendra04

La carte d’empathie nous permet de parler aux émotions : ce qu’on pense et ressent, ce que l’on entend, ce que l’on voit, ainsi que les problèmes et les besoins. Nous avons 10 minutes pour cela. C’est un peu court et c’est un peu le rush.

Etape 2 : Le pitch

En utilisant le fameux “elevator statement. Il pouvait servir de base à notre pitch … ou nous pouvions utiliser autre chose. C’est ce que nous avons fait. La clé étant de mettre en avant la proposition de valeur essentielle et l’aspect différenciant.

agileFrance2013-16Almendra03

Les 10 minutes étaient aussi un peu serrées, mais c’était déjà moins la panique qu’à l’étape précédente.

Etape 3 : Prototypage

C’est une application mobile ! Donc à nous de réaliser la "landing page” de cette application, plus une ou deux autres. Mais si possible une seule autre. 15 minutes pour ça !

Etape 4 : Test utilisateur

Une personne de chaque groupe va tester l’application d’un autre groupe. Elle se tient à bonne distance, le groupe reste silencieux et observe le testeur. Celui-ci décrit à haute voix ce qu’il observe et la façon dont il réagit.

Etape 5 : Prototypage

Sur la base de ce feedback, nous avions le droit de faire 1 modifications. En fait, on en a bien fait 2 ou trois. Hum… 5 minutes de modifications et nouveau cycle de feedback !

Etape 6 : Test utilisateur

Cette fois, c’est moi qui fait le beta testeur sur un autre MVP. Une ergonomie meilleure que chez nous, je dois dire …

Ce que j’en ai pensé

J’aime bien l’idée de ces ateliers en cycle court. Cet atelier-ci était probablement un peu surpeuplé pour qu’Alfred puisse en faire une facilitation efficace. J’ai bien aimé que nous ayons essayé de développer une idée originale ! Je retiens toutefois que :

  • On pouvait essayer de travailler sur une idée existante, pas nécessairement super-originale et faire quelque chose de potable dans le timing.
  • Ou l’on pouvait essayer d’être beaucoup plus original et alors le timing devenait un peu plus contraignant.

Bien sûr, la seconde idée me semble plus porteuse, mais il aurait fallu 1,5 ou 2 fois plus de temps…

En prime, voici le support d’ariadna Font dont Alfred s’est inspiré.

Remy-Christophe Schermesser : Tester autrement, le guide du testeur intergalactique

Ca sent la fin de cet Agile France : j’ai eu du mal à me décider sur la dernière session. Et en plus j’arrive en retard, largement en retard. L’orateur a commencé depuis un bon moment.

agileFrance2013-17Tests01

Remy-Christophe nous propose de nous détacher un moment de nos problématiques de langage “tel langage se teste mieux que tel autre…” et de reflechir à l’expressivité de nos tests.

JUnit, c’est bien mais on en atteint rapidement les limites, surtout en terme de lisibilité. Et surtout en terme d’expressivité quand on veut tester un comportement.

Il y a-t-il un espoir de ce côté ? Oui, il s’appelle RSpec ! Le DSL de RSpec permet de décrire ce qui est attendu !

Autre problème : le test des combinatoires. Nécessiare à une bonne couverture, il l’est aussi au traitement des différents cas sur les tests fonctionnels. La réponse s’apelle ici : mutations ! Ecrire un test et le faire muter, cela peut se faire avec Javalanche. La création de ces mutants peut toutefois conduire à des explosions combinatoires allongeant de manière exagérée la durée d’execution des tests. Il faut tuer sans pitié les combinaisons inutiles ou redondantes.

3ème volet : le property testing. ScalaCheck permet la génération automatique de cas de tests en se basnt sur la description des propriétés au sens mathématique du terme ! A n’utiliser que pour les sections de code critique, car là aussi l’inflation des temps d’execution des tests nous guette au tournant !

This is the end

Ici s’achève pour moi l’édition 2013 d’Agile France où j’étais présent cette année en touriste. J’aimerais l’être moins l’an prochain, nous verrons ce que l’édition 2014 nous réservera !

agile-france-4-1691
Publicités

Retours sur Agile France 2013, 4ème partie (en images)

Avant-dernière ligne droite pour mes retours sur Agile France 2013. Pour ceux qui débarquent, sachez que vous trouverez :

  • Un premier post couvrant le début de matinée
  • Un second terminant la matinée et couvrant le début d’après-midi
  • Un troisième terminant la journée du vendredi.

Welcome !

On commence tranquilement la journée par un café, une viennoiserie et des conversation avec des têtes connues.

agileFrance2013-12CafeVendredi01

Personnellement, j’aime bien arriver tôt et prendre mon temps avant de me ruer dans les sessions.

agileFrance2013-12CafeVendredi07

D’ailleurs en fait, on ne va pas commencer par une session, mais par le mot du bureau Agile France (à ne pas confondre avec l’organisation de la conférence Agile France).

Le mot du bureau Agile France

C’est Emmanuel Gaillot qui s’y colle. Je dirais que cela n’a pas été mon moment préféré de la conférence. Le style déjà est étrange : Emmanuel assis (comme il n’est pas un géant, on ne le voyait pas) lit une déclaration. Curieux, mais bon. La déclaration surtout en elle-même ne m’a pas fait forte impression, en tout cas dans le sens positif.

Je me méprends peut-être sur le teneur du message, mais il m’a semblé qu’on y opposait cet évènement non-sponsorisé et fier de l’être aux autres “vendus” à des partenaires, un Agile France “première manifestation agile en France” aux autres qui viennent saturer le paysage…

En tant que membre du Scrum User Group et donc organisateur du Scrum Day, j’ai un peu de mal à ne pas prendre cela comme une attaque ! Et franchement si nous avons des sponsors qui nous permettent de rendre l’évènement abordable, je n’ai pas pour autant l’impression de vendre mon âme. Mais j’ai peut-être mal interprêté le propos du bureau…

Alors que dois-je penser ?

A bien y réfléchir, rien de différent par rapport à ce que je pensais jusqu’à présent : Agile France est un magnifique évènement (le ScrumDay aussi et j’en suis fier), j’étais heureux d’y être et je reviendrais ! Il faudrait bien plus que cela pour gâcher mon plaisir !

D’ailleurs, c’est reparti !

Florence Chabanois : Mais pourquoi y m’écoute pas ?

C’est hélas assez souvent plus qu’une impression : c’est une réalité malheureuse de la communication sur nos projets ! Mais où donc se situe le problème ? Sommes-nous mauvais à faire entendre notre voix ou est-ce notre aptitude à écouter qui est prise en défaut ? Les deux mon capitaine ! Et Florence Chabannois va nous l’expliquer dans cette session.

agileFrance2013-13Chabanois03

Ecouter ou prétendre écouter ?

Mauvaise nouvelle : Le premier facteur de défaillance d’écoute, c’est nous même.

D’abord nous parlons trop (ce doit être vrai, ma mère me disait la même chose…) !

  • Difficile d’écouter quand on parle. Du coup nous nous écoutons nous-même plus que nous écoutons notre interlocuteur.
  • Le “moi je” qui rammène la discussion à soi, les rappels sont autant d’interruptions qui font obstacle à la communication.

Bref, quand on écoute et que l’on veut aussi parler, il faut attendre le bon moment pour le faire !

Par exemple, là ça marche bien : toute monde écoute Florence…

agileFrance2013-13Chabanois04

Ceci nous conduit à la première recette de Florence Chabanois

Recette n°1 : quand on écoute, il faut se taire

Quand florence parle de se taire, ce n’est pas seulement à propos de ce que l’on dit à haute voix. C’éest aussi faire taire notre petite voix intérieure (tiens ça me fait penser à Magnum, pour ceux qui ont vu la série…). Là, j’avoue que c’est plus challengeant, car je ne sais pas pour vous, mais pour moi la “petite voix intérieure”, c’est un peu tout le temps !

Ca ne s’arrête pas là, il faut aussi se concentrer sur ce que nous dit notre interlocuteur.

Et aussi montrer cela par notre attitude corporelle, en regardant notre vis-à-vis.

C’est un bon début. Mais ce n’est pas fini. Car à différents interlocuteurs, différentes attitudes d’écoute. Nous en arrivons à la seconde règle.

Recette n°2 : savoir s’adapter à son interlocuteur

Pour s’adapter, il faut reconnaitre des profils de personnalité. Et pour cela Florence nous propose … le modèle DISC !

On ne peut pas vraiment dire que ce soit d’une grande originalité, sans compter qu’il faut toujours un peu se méfier des modèles. Mais si ça aide à faire le boulot… Florence nous propose quelques exemples connus. Je vous laisse les découvrir dans la présentation, ils valent le coup !

Passons en revue ces différents types et comment s’adapter :

Le dominant

C’est un “problem solver”, il est pressé, voir brutal.

Avec lui, inutile de prendre des gants ou de longues introductions. Il faut faire des phrases courtes et aller droit au but.

L’influent

C’est l’archétype du commercial. Il est centré sur les personnes, les réseaux. Par contre, il manque d’organisation et le focus sur les délais n’est pas son point fort.

Quand on communique avec lui, il faut mettre l’emphase sur l’énergie et la passion. Il sera aussi sensible à ce qui touche à la réputation.

Le stable

Il est empathique, timide et orienté sur les personnes. Une sorte d’antithèse du dominant. Il est aussi indécis et torturé (dans les cas extrêmes quand même, j’imagine…). L’équipe est plus importante que lui-même.

Il faut lui parler doucement (n’oubliez pas qu’il est torturé, faut pas en rajouter) et être à 100% avec lui.

Le consciencieux

Il est orienté tâches et introverti. Les règles sont importantes pour lui. C’est un perfectionniste qui veut tous les éléments avant de se décider car il a peur de se rater. Les détails seront donc aussi très importants.

Recette n°3 : Reformuler

Pourquoi ?

  • Déjà pour montrer que l’on écoute et que cela se voit !
  • Pour tester notre bonne compréhension du message.
  • Pour provoquer l’empathie. On teste le moment où l’on est en phase lorsque notre interlocuteur nous dit “ouais, c’est ça !”.

Ce que j’en ai pensé

Une présentation certes agréable, mais où l’on apprends pas grand chose de nouveau.

Cela étant dit, je pense qu’il ne faut pas négliger les vertus de ce type de présentations, focalisées sur un aspect comportemental, même s’il est connu ou devrait l’être. C’est un retour aux fondamentaux, une sorte de “kata du coaching”. Il n’y a pas que le truc nouveau qui déchire qui compte. Les gestes élémentaires et quotidiens, nous les faisons bien plus souvent et nous devons ne pas oublier de les faire correctement.

Merci Florence !

Lectures recommandées

Régis Medina : Plus d’agilité avec le Lean

Nous étions resté hier avec la première paire de mon carré d’as. Transformons maintenant cela en brelan. Jamais je n’ai d’hésitation à aller écouter Régis et jamais je n’ai été déçu. Il en va de même aujourd’hui.

agileFrance2013-14Medina01

Alors voilà, on fait de l’agile. A-t-on amélioré les choses ? Oui, ça ne fait aucun doute ! Doit-on en rester là ? Régis est un vieux baroudeur de l’agilité. En fait le plus ancien ancien que je connaisse. S’il y a bien une personne capable d’évoquer cela, c’est lui !

La réponse est : oui. Nous allons voir pourquoi.

Il reste des challenges…

On parle bien au pluriel !

Avoir des gens “super forts”. On ne parle plus de faire des projets avec de grosses équipes, mais au contraire avec de petites capables d’abattre un gros travail ! On n’a pas le choix, sinon c’est le passage par la case “offshore” !

Faire des bon produits ! Des produits adaptés à nos clients, qui emportent l’adhésion. Ces dernières années, les services sur le Web ont terriblement monté le niveau de jeu !

Tenir le rythme du client. Grâce à l’agilité, nous avons drastiquement augmenté nos cadences de livraison et notre réactivité au changement. Las de son côté, le client a vu aussi ses rythmes s’accélérer. En fait, ses rythmes ont plus accéléré que les nôtres ! A notre grand désarrois, le fossé s’est donc encore creusé !

Quid d’une meilleure méthode ?

Oui, quelle est la bonne méthode pour passer le cap ?

Encore faux : ce n’est pas la bonne question !

Mettre les choses en perspective ne fait pas de mal. A mon grand plaisir, Régis l’a très bien fait en prenant le contre-pied d’idées à la mode.

La taylorisme.

On oppose souvent l’agilité au taylorisme, ce qui est juste. Mais on le fait sans discernement en se contentant d’asséner que “le taylorisme c’est mal”. Pourtant c’est bien lui qui a permi l’essort de l’ère industriel, il a permis un énorme pas en avant ! Mais l’organisation scientifique du travail montre des limites :

  • Le processus n’est pas toujours adapté au quotidien
  • L’équipe doit souvent adapter le processus au terrain.

Pour Régis Médina, il s’agit de garder les bénéfices de l’OST en adressant ses lacunes. Comment ? En gardant les personnes au centre du dispositif.

Attention, garder les bénéfices ne signifie pas conserver le principe du taylorisme qui divise le monde entre ceux qui pensent et ceux qui exécutent. En fait, c’est même le travers de nombreux déploiements “Lean” : on cherche à utiliser les outils du Lean dans le cadre de l’OST.

Nous avons hélas quelques mises en oeuvres catastrophiques estampillées Lean qui opèrent ainsi et sont très visibles. A mon avis, ces grand projets sont plutôt du Business Process Reengineering. On pourrait presqu’en dire que c’est l’ennemi juré du Lean … Mais je m’égare, revenons au propos de Régis.

Nous allions parler du Lean.

Le Lean à la rescousse

Pour éclairer le terrain du Lean, Régis nous dresse une image de la “maison Lean” :

  • Voir l’entreprise comme un terrain d’amélioration, donc d’expérimentation. L’opportunité de mener des “dojo”.
  • Le respect des personnes. Le succès est un droit ! Le rôle du manager est d’aider les équipes à relever des challenges.
  • Développer les compétences, non par “l’expérience” où les gens sont laissés à eux-même ou en usant nos pantalons sur les chaises des salles de formation, mais par la pratique délibérée.

Sur le développement des compétences, Régis nous entraine vers le terrain biologique et le développement et le renforcement des réseaux synaptiques par leurs usages. J’aime bien l’exercice intellectuel de ce rapprochement, mais je ne suis pas sûr de suivre l’orateur sur ce terrain. Pas en l’absence de sérieuses références dans le domaine des savoirs évolués (par opposition aux connaissances de base comme le langage, l’écriture, etc…). Disons que c’est au moins une perspective intéressante.

Pour débuter sur cette voie, l’orateur nous propose de commencer par…

3 pratiques

Management visuel

Le management visuel ce n’est pas mettre sur les murs n’importe quoi ! En Lean, c’est rendre visible l’exercice que l’on essaie de faire.

Le point principal est de visualiser le challenge à atteindre, ce qu’on veut réussir. C’est un focus différent de celui des “tâches à faire”.

Cet objectif macro à moyen terme doit se décliner en objectifs à la journée. Régis nous parlait du “droit au succès” au début de sa présentation : le droit au succès, c’est aussi pouvoir rentrer chez soi en étant fier d’avoir atteint le but que l’on s’était fixé en début de journée.

Le management visuel, c’est aussi rendre visible les problèmes et leur résolution. On rejoint ici la notion de Kaisen, c’est à dire d’amélioration continue. Pourquoi rendre visible les problèmes ? Pour avoir le nez dessus et être en position de devoir les résoudre plutôt que de les remettre au lendemain.

Votre exercice : Sur votre support de management visuel, mettez en évidence :

  • Qu’est-ce qui nous permet d’apprendre quelque chose
  • Qu’est-ce que le succès ?
  • Voit-on les points à travailler ?

La résolution de problèmes

L’outil de base, c’est le cycle PDCA, une approche rigide mais un passage indispensable en Lean. Nous cherchons à répondre à la question : quelle action précise va payer ?

Votre exercice : Une action de la dernière rétrospective dont vous êtes content :

  • Quel était le problème ? Etait-on en mesure de le chiffrer ? Quels en étaient les impacts pour l’entreprise ?
  • Quel était l’objectif de l’action ? Qu’est-ce qui nous permet de voir que l’action marche ?

L’observation de terrain

C’est voir où l’on peut grater de l’efficacité en allant là où l’action se passe.

Par exemple, en regardant l’utilisateur travailler avec l’outil informatique : noter les actions qui apportent de la valeur et celles qui sont du “gaspillage” au sens Lean. dans un cas l’outil aide, dans l’autre il est un frein.

Votre exercice :

  • Sur chaque item de backlog, quel est la valeur associée.

Conclusions

On fait avancer les choses, non pas en faisant de grand plans et en concevant des “ultrasolutions”, mais par la pratique quotidienne et répétée.

Changer notre façon de voir : les processus ne sont pas important. Scrum, XP, Kanban … quelle est la bonne méthode ? Ce n’est pas la bonne question. La bonne question est : comment développer les personnes.

Ce que j’en ai pensé

Voilà encore une session dont ma restitution va être bien fade. Difficile de rendre justice à la présentation de Régis. C’est bien fait pour vous, fallait être là ! La compréhension du Lean passe par la pratique et l’infusion des concepts. C’est ce qu’a fait Régis, il nous a infusé le savoirs de base. Il ne s’est pas arrêté là, il nous propose de commencer quelque part !

L’histoire ne s’achève pas ici. En fait ce n’est qu’un préambule. Régis travaille avec des collègues à un “starter kit” qui fait suite à cette introduction afin de nous aider à démarrer la mise en ouvre. Franchement, j’ai hâte de voir cela. Pour patienter un peu, voici le support de présentation.

http://fr.slideshare.net/slideshow/embed_code/22424062

Lectures recommandées

Dernière ligne droite

Nous allons souffler un peu avant les dernières sessions de cet Agile France 2013. Nous nous retrouvons très bientôt !

Retours sur Agile France 2013, 3ème partie (en images)

Après avoir couvert le début de matinée et le milieu de journée, il est temps de nous intéresser à la fin de cette première journée de conférence.

On commence par un Lightning Talk. Ou ce qui aurait dû être un lightning talk, car il est joyeusement passé de 15 minutes à 25 ! Mais c’est sans importance. C’était intéressant.

Egor Sviridenko – Je vois !

Ou comment la visualisation non conventionnelle contribue à des projets agiles

Une bonne visualisation fait la différence et permet de mettre en évidence une information importante qui sinon resterait cachée.

La visualisation par l’exemple

Pour illustrer cela, Egor nous parle de l’épidémie de choléra à Londres en 1854. En quelques semaines cette épidémie fit des centaines de victimes. Le mode de transmission de cette maladie n’était pas encore connu à cette époque (on pensait à tord qu’il s’agissait d’une transmission aérienne).

Les autorités se sont révélées incapables d’endiguer l’épidémie, jusqu’à ce qu’un médecin, John Snow, ait l’idée de reporter le nombre de personnes atteintes sur une carte. Cela permit d’abord de délimiter l’extension de l’épidémie, puis d’en localiser l’épicentre. Et enfin d’en déterminer la cause probable : une pompe à eau dont John Snow obtiendra le démontage de la poignée, mettant ainsi un terme à l’épidémie !

cholera_map_john_snow

La visualisation permet de rendre mieux interprêtable des informations. Encore faut-il utiliser la représentation adaptée !

D’autres visualisations

Egor a regroupé les principes de visualisation en 4 familles. Nous venons d’en voir la première : les cartes.

Si l’utilité de la carte dréssée par John Snow est indéniable, les données y sont superposées de manière plutôt classique. Mr Minard a utilisé une représentation bien plus originale afin de stigmatiser le désastre de la campagne de Russie de Napoléon 1er.

Les réseaux permettent de représenter des informations corrélées entre elles. McLaren utilise un backlog converti en mindmap afin de déterminer les évolutions à réaliser sur ses logiciels embarqués. Comme vous pourrez le voir sur le support de présentation, c’est assez impressionnant. A mon grand étonnement, ils paraissent être capables de s’en servir !

Les timelines permettent de construire des histoires où l’on voir l’évolution d’un ou plusieurs facteurs au fil du temps. La timeline du “seigneur des anneaux” nous permet d’appréhender les tribulations des personnages, leurs séparations et leurs rencontres. Celle de Jurassic Park nous montre que les différents personnages se font bouffer au fur et à mesure de l’intrigue. Mais ça on le savait déjà.

La représentation à plusieurs variables permet de représenter des facteurs non corrélés sur une même représentation. Un exercice dans lequel il est préférable de se restreindre afin de ne pas rendre cette visualisation illisible. Le Kanban que nous utilisons de plus en plus sur nos projets agiles rentre dans cette catégorie.

Je ne saurais trop vous recommander le support de présentation d’Egor : il regorge littéralement d’exemples de ces visualisations. Rien ne saurait être plus parlant !

Conclusions et conseil de lecture

Quel est la qualité principale d’une bonne représentation ? Elle doit raconter une histoire !

Un conseil de lecture principal :

Antoine Contal – Coacher des managers

Sur mon premier compte-rendu, j’avais évoqué 4 orateurs que je vais systématiquement écouter. Mon carré d’as en quelque sorte. Le premier était Pascal Van Cauwenberghe, Antoine est le suivant. Vous découvrirez les deux autres lors de la seconde journée.

agileFrance2013-09Contal01

L’heure est grave ! De nombreuses équipes améliorent leur façon de faire et leur productivité, et ce qui les handicapent, c’est parfois le management intermédiaire, celui qui devrait au contraire les aider à être plus efficaces ! Comment changer cela ?

Le management au quotidien

En Lean, on commence toujours par aller observer. Donc, il faut aller voir la bête dans son habitat naturel. Celui-ci se trouve en deux endroits principaux :

  • Son bureau
  • La salle de réunion

Quelle sont ses activités principales ?

  • Avaler et produire des rapports
  • Assigner des tâches
  • Eteindre des incendies

Ah ! Nous allions oublier son péché mignon : entamer des projets pharaoniques. Ce qu’en Lean on appelle des “ultrasolutions”.

L’idéal du management

En Lean, celui-ci se construit autour d’un certain nombre de valeurs et de principes.

  • L’amélioration continue : Le Kaisen. C’est progresser à petits pas en construisant des expérimentations.
  • Le Genchi Gembutsu : retourner sur le terrain, pour se baser sur des faits, plutôt que sur des opinions (ce qui est souvent le cas du travail fait en salle de réunion).
  • Construire des challenges : oser rêver l’idéal. Motiver par rapport à l’excellence. Le but est de créer l’adhésion, mais aussi de placer la barre haut afin de faire progresser.
  • Respect des personnes : croire dans le potentiel des personnes. Comprendre que les problèmes sont personnalisés et doivent donner lieu à un apprentissage.
  • Teamwork : savoir travailler et collaborer au-delà des frontières organisationnelles.

Pour Antoine Contal, le manager Lean est à la fois un chercheur et un entraineur sportif !

Comment réussir en sachant ce qui rate

  • Les critères de réussite : ils doivent être clairs. On peut coacher une équipe de développement sans définir clairement ce qu’est le succès et s’en tirer. Ce n’est pas possible avec des managers !
  • Etre sur un mauvais sujet. Par exemple : améliorer le délai de production des rapports d’activité !
  • Etre purement dans l’humain.

C’est bien d’avoir une idée de comment rater, mais c’est mieux si l’on a une idée de comment contrer ces travers.

  • Il faut définir le succès proprement. Il n’y a pas de raccourcis par rapport à cette étape. Le faire c’est déjà du coaching !
  • Choisir les bon sujets. Comment ? Ce sont ceux qui sont bon pour le manager et pour les équipes !

Le coaching fonctionne si la performance et les conditions de travail des équipes s’améliorent.

Petits exercices

Antoine Contal nous en propose 3.

Exercice 1 : Ecouter l’utilisateur

On en revient à la question de la valeur.

L’orateur illustre cela avec un manager confronté à un usager d’une application pour laquelle un lourd projet vient de se terminer. A la question “que pensez-vous des nouvelles fonctionnalités ?” ce dernier répond … “oh ! Elles ne me gênent pas…”.

Las, l’histoire se termine mal : le manager ne fera rien par rapport à cela et finira par être remplacé !

Exercice 2 : Définir la performance

Cela passe par la mise en place d’indicateurs (lead time, en cours, stock), d’enquêtes de satisfaction.

Le rôle du management intermédiaire est aussi de reconnecter l’opérationnel avec la stratégie. Antoine évoque pour nous l’histoire de cet urbaniste SI qui découvre que ses indicateurs d’urbanisation ne sont pas ce qu’il croit simplement parce que les cellules opérationnelles en charge d’arrêter les systèmes remplacées (et qui ne dépendent pas de lui) ne l’ont pas fait !

Exercice 3 : Aller voir

Encore et toujours aller sur le terrain. Pas seulement celui des utilisateurs, mais aussi celui des équipes de développement pour identifier ce qui nuit à leur travail.

“Comment je fais…”

Pour l’orateur, le rôle de coach de managers est un rôle de coach sportif !

Le manager est passé d’une situation où il accomplit son travail dans son bureau ou dans les salles de réunion à une situation où il est présent sur le terrain, pour voir ce qui se passe.

Le coach fait s’enchainer les exercices d’entrainements faits sur mesure, afin d’adresser les points où il s’y prend mal, ce qu’il doit apprendre.

Une session de coaching typique se découpe ainsi :

  • 30 minute : préparation ; où allons-nous, que voulons-nous tester.
  • 1h30 : Aller sur le terrain ; le manager doit apprendre à voir. Le coach reste silencieux, observe et prend des notes (pour le débrief). Il se permet une et une seule question !
  • 1h : Debrief ; Qu’avons-nous vu ou pas ? Que doit améliorer le manager. Que doit-il répéter avant la prochaine session.

Typiquement, le rythme est d’une ou deux sessions par mois.

L’ingrédient secret duu coach Lean, ce sont les “3 R” :

  • Relate : c’est la relation interpersonnellle que le coach doit construire avec le manager. Celui-ci doit apprendre à faire confiance à son coach.
  • Repeat : Faire répéter le même geste, encore et encore.
  • Reframe : Le coach donne “une autre lecture” de ce que le coaché a vu.

A vous de jouer

Pour synthétiser, quel doit être le rôle du manager ?

  • C’est “l’étoile du nord” des équipes de développement.
  • On fait progresser le manager en lui donnant de “petits exercices”.
  • La manager doit devenir un développeur de talents.

Une dernière chose : Il est rare que la demande de coaching de manager soit formalisée ou même demandée. Si la nécessité apparait, Antoine utilise le mode “stealth” et intègre cela au coaching de l’équipe !

Ce que j’en ai pensé

Difficile de rendre justice à la présentation d’Antoine par un simple compte rendu. Disons que, malgré le nombre appréciable de présentations de bonne qualité auxquelles j’ai assisté, c’est pour moi le point fort de cet Agile France 2013 !

Antoine Contal ne garde rien pour lui dans ses présentations. Son niveau de maturité fait qu’il est assez à l’aise pour procéder ainsi. On repart avec pas mal d’éléments à mettre en oeuvre, des éléments de reflexion pour nous faire progresser. En fait, comme disent les jeunes j’ai toujours un peu l’impression de “prendre cher” avec les présentations d’Antoine et de son comparse. Pourtant j’y retourne. Comme il l’a si bien dit, il place la barre haut et c’est grâce à cela que l’on progresse. C’est un peu déprimant pour moi de voir la marge de progression qu’il me reste, j’ai l’impression d’avoir si peu progressé, de rater tellement de choses … Mais nul doute que nous avons besoin de personnes du niveau d’excellence et de maturité d’Antoine pour nous y aider.

Lectures recommandées

Autres resources :

Pascal Van Cauwenberghe et Pierre Hervouet – Vous pouvez ignorer les contrôleurs de gestion, les contrôleurs de gestion eux ne vous ignoreront pas !

L’agilité, c’est l’adaptation au besoin, l’émergence du changement ! Mais bon, une entreprise a quand même besoin de savoir où aller et surtout de savoir où va son argent. Alors, on peut dire que l’on se focalise sur la valeur, des gens ont besoin de se focaliser sur les dépenses. Ces gens sont le contrôleurs de gestion. On les connait à peine, on les ignore (peut-être même les méprisent-on) le plus souvent. Ce n’est pas raisonnable.

Pascal et Pierre viennent nous faire prendre conscience de cette dure réalité. Nous allons suivre pour cela les pas de Dora l’exploratrice (en plus de ceux de Pascal et Pierre) !

agileFrance2013-10BeyondBudget02

Cost accounting

Puisque l’on est en atelier, on va se mettre aux travaux pratiques. Des travaux pratiques bien sympathiques, car on va préparer des cocktails ! On mélange des ingrédients, on a 2 tailles de cocktails et il faut calculer le coût de chacun.

agileFrance2013-10BeyondBudget01

Le cost accounting, c’est comme faire des cockatils (mais on a pas le droit de l’avouer). On a des ingrédients (des centres de coûts) et il faut les saupoudrer sur des lignes budgétaires !

C’est une approche analytique détaillée qui est très précise … mais précise ne veut pas dire exacte. En fait la ventilation de coûts comme les frais généraux peut montrer les faits sous des jours différents selon la façon dont on l’opère.

Attention ! On ne peut échaper complètement à cette approche, car c’est celle qui est de toute façon demandée règlementairement par les services publics.

Dernier travers du “cost accounting” : les stratégies budgétaires tendent à emmener ce type de gestion vers une sorte de “cycle en V” de la gestion budgétaire. C’est comme ça que l’on se retrouve à préparer le budget de l’année suivant dès le mois de Juillet !

Throughput Accounting

Ce mode de gestion prend un angle différent : celui de gérer l’investissement en fonction des goulots d’étranglement ! C’est une sorte de vue systémique de l’investissement.

agileFrance2013-10BeyondBudget04

L’un des avantages par rapport au cost accounting : c’est de sortir du cycle en V ! Mais ce n’est pas encore parfait, car l’investissement n’est pas rapproché de la valeur du flux auquel il est subordonné.

Lean Accounting

Le Lean Accounting adresse ce dernier reproche. Ici, le point de départ est la valeur client, ce qui va déterminer un prix au produit. En fonction de celui-ci on décide de la marge, donc du coût ! C’est le “target costing”. Pierre et Pascal semblent confiants sur l’approche, mais j’ai quand même l’impression que ça peut vite tourner à la quadrature du cercle…

Un autre point différenciateur important, c’est que le contrôleur de gestion lean fait partie de l’équipe !

Beyond Budgeting

Cette approche est plus difficile à appréhender, plus proche de l’agilité tel que nous l’entendons (donc plus intéressante, il faut donc que j’y travaille). Elle s’appuie sur 12 principes qu je ne vais pas répéter ici, car ils figurent dans le “hands out” ci-dessous.

L’idée est de sortir des comportements biaisés introduits par le contrôle de gestion.

Ce que j’en ai pensé

Nous avons tout un univers à explorer ici.

Les références bibliographiques du hands-out lèvent un coin du voile. Hélas cette session est un peu courte pour vraiment nous permettre de saisir les 4 approches. Elles montrent, dans leur progression, une “agilification” croissante des concepts. C’est excellent ! J’ai un peu l’impression cependant que ces concepts m’ont filé entre les doigts. Il faudrait que je révise.

L’idée de faire un atelier est excellente. Et le cocktail pour le “cost accounting” a bien marché. Hélas le côté atelier s’est arrêté ici. Il faudrait imaginer la suite des exercices pour chacune des 4 étapes…

Comme je l’ai dit : c’est relativement nouveau pour moi … mais aussi important. Je ne regrette pas d’avoir choisi cet atelier.

A demain !

Une journée bien remplie, comme vous avez pu le voir. Il est temps de cloturer celle-ci

agileFrance2013-11FinJeudi02

A très bientôt pour la journée de Vendredi !

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 !

Retours sur Agile France 2013, 1ère partie (en images)

J’avais fait l’impasse sur l’édition 2012, je suis revenu pour l’édition 2013. Cette année encore Agile France promettait un programme attrayant : promesse tenue ! Le “take away” de ces 2 jours de conférences ne rentre guère dans mon sac à dos, c’est un semi-remorque qu’il va me falloir. Une fois de plus, je vais vous distiller cela en plusieurs parties.

Place à l’action, ou plus précisément à la première session de la journée.

agileFrance2013-01Keynote02

Peter Stevens : From Value to Values

Why management has to change and how IT is inspiring the solution

Nous étions quelques un à avoir eu l’occasion de croiser Peter Stevens lors d’une Scrum Beer il y a environ 2 ans. Cette fois, il nous faisait la keynote de la conférence et venait nous parler du Stoos Network. J’avais une première fois évoqué ce mouvement à l’annonce du Stoos Connect, puis plus récemment pour parler du Stoos Satellite Paris.

C’est bien du Stoos Network dont Peter Stevens est venu nous parler. Selon lui, le monde se divise en 2 types de sociétés:

  • Celles qui enchantent leurs clients.
  • Les autres.

Vu comme ça, c’est un peu simpliste. Creusons un peu. Aujourd’hui, les compagnies ayant un fort “focus client” sont celles qui gagnent de l’argent. Car il n’a jamais été aussi facile de changer de fournisseur ou de service. Votre service de téléphonie ne vous plait plus, résiliez-le dès aujourd’hui pour prendre un nouveau plan ! Il y a 30 ans, Peter Stevens nous confiait qu’en Suisse, un abonnement téléphonique nécessitait un dépot de garantie équivalent à un demi-mois de salaire ! Nous avons donc changé de logique :

  • Autrefois : “you take what we make”.
  • Aujourd’hui : “I choose what I want”.

Pour autant, ce changement de polarité ne s’est pas accompagné d’un changement de paradigme dans la logique de l’entreprise.

agileFrance2013-01Keynote03

L’entreprise moderne continue de choisir son cap en fonction des dividendes qu’elle peut reverser à ses actionnaires. C’est une logique qui n’est en fait pas celle permettant d’obtenir les meilleurs résultats car elle part du mauvais point.

Pour enchanter le client, il faut augmenter la vitesse de réactivité, faire grandir la capacité d’innovation. L’économie d’aujourd’hui est une économie de la créativité. Toutes choses que le mode de fonctionnement “commande / contrôle” hérité du Taylorisme et du Fordisme ne permettent pas.

Il doit y avoir une meilleure façon de faire, c’est le constat que différents courants de pensée du réseau Stoos (radical management, tribal leadership, beyond budgeting, management 3.0, etc…). Et elle s’inspire de l’agilité.

Pour Peter Stevens, l’élément le plus important du manisfeste agile se situe en haut de celui-ci :

We are uncovering better ways of developing software by doing it and helping others do it.

Stoos Network est un “mouvement de mouvements” qui promeut l’entreprise non comme une structure pyramidale, mais comme un réseau “apprenant” de personnes, dont les managers seraient les servants.

Aujourd’hui, l’agilité dans les projets informatiques est confrontée à une frustration de par les conflits qui l’opposent à un management classique. Stoos est la continuité de ce mouvement vers l’organisation de l’entreprise.

Je n’ai pas trouvé la présentation de Peter Stevens, mais un support qui s’en approche de très près.

J’ai été un peu déçu par cette keynote. Bien que quelques exemples (visibles sur les supports) aient pu nous donner à réfléchir, elle est pas mal resté dans les généralités.

Géry Derbier : Le leader en tant qu’hôte

J’avais suivi de loin l’intérêt de Géry pour le host leadership, mais sans m’y intéresser plus avant, car on ne peut pas être partout, n’est-ce pas ? Mais Géry étant mon futur collègue, j’essaie de le pister un peu…

Déjà, ça commence par le coincer en face de mon objectif !

agileFrance2013-02Gery01

Cette session était en fait un atelier participatif. On parle toujours du “servant leadership” par opposition au “leader command & control”. Certes, mais comment cela peut-il se matérialiser ? Il y a-t-il des parallèles avec de choses que nous connaissons qui pourraient nous aider ?

Il se trouve que oui !

Que se passe-t-il quand nous participons à une fête que nous jugeons réussie, que fait l’hôte pour rendre cela possible ? C’est à ce travail de reflexion que nous a invité Gery aujourd’hui. Par petits groupes, nous avons cherché à décortiquer les ingrédients d’une fête réussie

agileFrance2013-02Gery03

Une reflexion pas très facile à mener en un temps limité. Je vous livre en vrac les points qui sont remontés :

  • Favoriser l’émergence, laisser de la liberté pour permettre la créativité.
  • Avoir une (des) réactions en chaine. A l’image de ce qui se passe quand on commence à danser.
  • Créer le lien entre les personnes. C’est vrai surtout quand nombre d’entre elles ne se connaissent pas. C’est moins le cas dans des réunions de famille.
  • Le pouvoir de l’invitation. On ne vient pas sous la contrainte, c’est un acte volontaire.
  • Donner la permission, ou comme le dira Olivier Pezziardi “pas faire chier les gens”.
  • Ne pas chercher à obtenir un résultat. On créé les conditions, le résultat vient en second.

Mais est-il possible de considérer un projet de la même manière ? Sommes-nous invités à nous joindre à un projet ? J’aurais tendance à répondre “oui”. En fait, cela se passe beaucoup dans la tête: nous sommes invités si nous avons envie de nous sentir l’être. Mais c’est juste un avis personnel. Je vous invite à lire le white paper accessible sur le site host leadership.

Cyrille Martraire : Code legacy : Faire évoluer ou réécrire ?

Cyrille est un adepte fervent du DDD et un membre actif de la communaute du software craftmnship. Aujourd’hui il vient évoquer avec nous les stratégies de travail sur le code hérité (legacy code). Cette présentation s’appuie sur un projet mené chez Sungard autour d’un système d’asset management. Nous parlons ici d’une application vieille de 20 ans lourde de 20 millions de lignes de code avec des procédures stockées, des EJB2, etc…

agileFrance2013-03Martraire02

Mais qu’appelle-t-on “code legacy” ? Pour Michael Feathers, du code hérité n’a pas de tests. Si l’on se calque sur cette définition, du code hérité n’a pas besoin d’être vieux pour être considéré ainsi !

Alors, faire évoluer ou récrire ?

Il faut regarder les choses avec lucidité: espérer que tout soit “beau” un jour est illusoire. Ca n’arrive pas !

Le postulat de départ est donc : on garde tout ! Mais pour faire évoluer en gardant l’existant, il faut se munir de tests, d’une manière ou d’une autre. Comment faire ?

Je vous présente le “Software Testing Ice-Cream Antipattern” ! On commence par le haut: si on a rien, on fait des tests manuels. Puis on essaie d’automatiser les tests par l’IHM. Dès que le découpage en couches devient à peu près présentable, on passe à des tests d’intégration pour tester les API. Enfin quand le niveau de découplage interne le permet (le plus souvent jamais) on met en place des tests unitaires !

softwaretestingicecreamconeantipattern

Bien sûr, c’est très coûteux, et l’orateur évalue le différentiel de vélocité de 1 à 4 par rapport à du code neuf écrit en TDD.

Et s’il faut réécrire, doit-on réécrire ?

Pas toujours. C’est la fameuse question du “make vs buy”. Si le processus métier habillé avec le logiciel est un différenciateur de l’entreprise, alors il faut faire ! Comment se différencier en pratiquant la même chose que les autres ? Si ce n’est pas différenciateur, alors il faut essayer d’acheter. Oui, mais le logiciel sur étagère ne corresponds pas exactement à ce que je fais … N’essayez pas d’adapter, même si l’éditeur dit que l’on peut, même si de nombreuses société qui sont prêtes à vous vendre du conseil disent que l’on peut (et qu’elles peuvent vous “aider”). Ou alors, faites-le à minima, faites votre possible pour plutôt adapter vos processus au logiciel. De toute façon, ce ne sont pas eux qui vous rendent différenciant, ce sont des centres de coût.

Visualiser

Il est bien rare que l’on doivent intervenir partout en même temps dans du code hérité. En fait cela concerne le plus souvent un volet précis de l’application : une phase de traitement, de nouveaux instruments financiers, etc…

La première étape que nous propose Cyrille est de visualiser le flux métier. A l’image de ce que l’on montre lorsque l’on construit une story map (là c’est moi). Il s’agit de donner de la structure. Sur celle-ci s’appuient des fonctions secondaires et des concepts. C’est le travail péparatoire qui va nous permettre de passer à la suite. Ce que Martin Fowler appelle l’Asset Capture.

A partir de là, il va falloir identifier le ou les assets concernés par l’évolution.

Comment intervenir

Quand on part d’un legacy à priori inconnu, il y a une démarche logique pour aborder la bête :

  1. Lire la documentation
  2. Interroger les anciens qui la connaisse peu ou prou.
  3. Utiliser l’application.
  4. Lire le code.
  5. S’essayer dessus en fixant des bugs.

Le principe de base des évolutions, est de ne pas essayer de faire plusieurs choses en même temps. Il faut y aller prudemment, s’insérer dans l’existant même si on n’aime pas ce que l’on voit. Des conseils souvent prodigué dans les Reengineering Patterns.

Comment s’organiser

Comment pensez-vous procéder : en opérant une réécriture iso-fonctionnelle ? Sachez-le, personne ne paie pour cela.

Une réécriture s’accompagne toujours d’une certaine dose d’évolutions. Oubliez l’idée d’une équipe refonte constituée de pur techos, il va falloir une vrai équipe projet regroupant des compétences diversifiées (analystes, testeurs, etc…).

Maintenant il faut se mettre au boulot !

Strangler application

Le pattern préféré de Cyrille est le Strangler Application Pattern, lui aussi décrit par Martin Fowler. Comme son nom l’indique, ce pattern consiste à “étrangler” progressivement l’application existante en envoyant les traitements qui ont été réécrits vers la nouvelle application. Le point faible étant ce dispatching qui doit alors exister dans l’ancienne application, nécessitant un refactoring pas nécessairement négligeable… Les deux points clés de l’approche sont:

  • Le décomissionement des concepts : on travaille concept par concept, et on switch complètement l’un d’entre-eux quand il est prêt dans la nouvelle application. C’est donc mieux quand les concepts sont assez atomiques.
  • Le “feature toggle” qui doit permettre le basculement vers la nouvelle application. Attention, parfois cela se passe mal, il est alors souhaitable dans ce cas de pouvoir revenir en arrière.

Bubble context

Le développement de nouveaux concepts s’opère dans une “bulle” isolée des adhérences avec l’existant, du moins autant que faire se peut. C’est l’Autonomous Bubble Context décrit par Eric Evans.

Isolé du monde legacy, le développement s’opère comme un nouveau développement, en TDD & BDD. Entre l’ancien et le nouveau monde, une Anti-Corruption Layer isolée vers le haut par une API et par le base par une SPI, opère comme un sas entre les deux environnements.

Quelques points clés à ne pas oublier :

  • Se faciliter la vie en ayant un certin niveau de mapping avant l’existant. On pense surtout ici au mapping avec la base de données.
  • Décréter le “freeze” de l’existant : toute évolution doit s’opérer dans une Bubble Context. On touche seulement à l’existant pour opérer des renvois vers la bubble context.
  • Ne pas oublier qu’une bulle n’a qu’un temps. Avec le passage du temps, elle-même deviendra du legacy à son tour un jour.

Pour résumer la stratégie de réécriture, l’orateur nous résume la chose :

Réécriture = Frontières clairement définies + stratégie d’étranglement + intégration minimale.

Je n’ai pas exactement le support que Cyrille a utilisé, mais un très proche. Le voici 

Lectures recommandées

Essentiellement 3 ouvrages à connaitre. Ils sont tous sur mes étagères mais n’ont pas encore fait l’objet d’une note de lecture publiée :

Vous pouvez également lire l’excellent retour de Vincent Uribe sur cette session, sur le blog Soat.

Break !

Le début de matinée a déjà été bien rempli. Il est temps de faire une pause. C’est une occasion pour reprendre contact avec les uns et les autres. On est là aussi pour ça.

agileFrance2013-04BreakJeudiMatin02

C’est aussi la pause pour la publication de mon retour d’Agile France. Nous sommes agiles, on va faire tout ça de manière itérative, que diable ! Rendez-vous bientôt pour la suite de mes périgrinations agilistes.