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 !
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.
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.
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 !
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 !
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.
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.
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 !
Software Freethinker 
