Philo SI

Le feedback est un élément important dans les organisations Agile. D'abord parce qu'il est nommé comme légitime et même réclamé par les cadres Agile, ensuite parce que la pratique génére la demande. D'une organisation où le feedback est ignoré à une autre où il est de règle, le balancier s'égare parfois dans une zone limite, je vois souvent des demandes de ROTI (1) dont à titre personnel je serai incapable de tirer une conclusion quand à l'amélioration possible.

Le feedback est essentiel quand on considère les systèmes auto-organisés comme le sont des équipes Scrum par exemple. En réalité c'est vrai pour tous les groupes humains.
Nous adaptons en permanence notre comportement à notre environnement, à la présence des autres, aux signes positifs ou négatifs qu'ils nous renvoient… Tous ces feedbacks sont implicites.
Lorsque l'on demande, comme une règle d'organisation, d'exprimer du feedback, on demande que celui-ci soit explicite. Le premier réflexe est donc d'exprimer tout haut ce que l'on disait tout bas en enrobant un peu et en ne disant peut-être pas tout. Parfois on se force un peu pour trouver quelquechose. Nos expériences et notre éducation ainsi que notre personnalité nous portent plutôt à vouloir corriger les défauts que nous voyons (c'est notre point de vue) chez notre interlocuteur, à formuler de vagues compliment si c'est OK, ou parfois à devenir dithyrambique si on a été subjugués.
Toutes ces réponses constituent du feedback, elles sont justes quand elles sont sincères, elles sont pourtant difficiles à exploiter pour celui qui les reçoit.

Les formations Scrum, les coachs agiles et les divers ateliers que l'on peut pratiquer dans cette communauté très active et en partage, invitent les participants ou les équipiers à donner d'abord du feedback positif. Ensuite nuancer le feedback négatif en le formulant comme axe d'amélioration. C'est bien, c'est actionnable, ça matérialise un axe de travail que chacun peut adapter à soi-même.

Certains ont cependant du mal à embrayer, peut-être parce qu'ils n'en captent pas le sens ou bien trouvent cette attitude artificielle. Pourquoi est-ce qu'il faudrait faire ça ? D'accord, c'est plus agréable, moins conflictuel...est-ce que c'est vraiment ce que l'on cherche (on retrouve ici le mot "bisounours")? Est-ce que cette attitude est la meilleure pour permettre au système de s'améliorer ? Pouquoi …?

Oui c'est la meilleure.

Chacun d'entre nous a toute une palette de réponses possibles selon les situations. On pourrait imaginer qu'il a plusieurs niveaux en nous, chaque niveau étant spécialisé sur un type de réponse. Par exemple quand je rencontre un collègue qui me dis "comment vas-tu ?" je répond "bien merci". Si quelques minutes après je déjeune avec ma femme qui me pose la même question je répond "m'en parle pas, journée de m….". Et si l'après-midi je rencontre un ami coach qui, après que j'aie répondu "bien merci" à sa question "comment vas-tu ?", enchaîne en me disant : "super ! Et en particulier alors, dans cette journée, qu'est ce qui te donne la sensation d'être bien ?" je vais m'interroger sur les zones positives de ma journée…

Dans le premier cas j'aurai répondu au niveau du "masque social", dans le second au niveau du "crapaud", dans le troisième je vais me tourner vers "le prince" pour trouver ma réponse (2).
Le masque social est ma protection, elle s'active automatiquement et ne donne pas de prise contre moi. Mon crapaud est ma part sombre, insatisfaite de moi, insatisfaite des autres, insatisfaite du monde, mes croyances archaïques négatives. Le prince est le héro que j'ai été dans mon enfance, quand je jouais au chevalier, que j'étais fort, juste, invincible. Ce prince a été blessé, forcément, il s'est protégé avec le masque et a vu naître son crapaud.
Quand on adresse un système humain, par définition complexe et auto-organisé, l'amélioration se fait par le positionnement de chacun des agents impliqué... c’est-à-dire depuis chacun. Et chacun a plusieurs réponses possibles.

Donner du feedback est difficile parce que l'on risque en permanence la connexion avec les crapauds (mon crapaud en tant fournisseur de feedback et ton crapaud qui le réceptionne). Tout ce que l'on peut dire peut facilement être interprété par ces bestioles (je ne suis pas à la hauteur, j'ai encore raté, ils ne comprennent pas…). Et mon crapaud n'a pas tellement de bons conseils pour m'aider à m'améliorer.

On gagne de l'énergie en doublant le crapaud.
L'enjeu du feedback est l'amélioration de notre système, il passe par un meilleur positionnement de chacun et cela passe par la confiance et l'estime. Le prince est le bon interlocuteur pour ça. Donner du feedback positif n'est pas un artéfact agile. C'est un exercice, difficile, qui a pour but de parler à la partie de l'autre capable de générer l'énergie et les solutions pour progresser, c’est-à-dire à son Prince. Et pour faire cela j'ai également besoin d'aller chercher le Prince chez moi.

N'écoutez pas les crapauds qui coassent "bisounours". Là n'est pas le sujet, la question n'est pas d'être gentil, elle est d'être efficace.
La prochaine fois que vous donnez du feedback faites l'essai de commencer par "ce qui m'a plu dans ce que tu as fait…." et de finir par "peut-être que ce qui pourrait aider à être encore meilleur …" C'est un bon moyen de parler entre Princes et Princesses.

(1) ROTI veut dire "return on time invested" , il consiste à demander aux participants d'évaluer par un chiffre entre 1 (mini) et 5 (maxi) la valeur qu'ils ont retiré d'un événement au regard du temps qu'ils y ont passé.

(2) L'auteur de cette métaphore est Carlo Molsoï, François Délivré la développe ici : http://www.academie-coaching.com/pdf_delivre/sfcoach_0407.pdf

Read more...

J'ai été interviewé récemment par une étudiante de Grenoble École de Management sur la problématique de la gestion des portefeuilles de projet en mode Agile. Cela à été l'occasion de revenir sur les principes que nous avions discutés avec mon ami Jean dans une présentation que nous avions faite à Agile Grenoble en 2010.

J'ai un peu exploré depuis les approches complexes, en particulier au travers des conférences et écrits de Joel de Rosnay. Il introduit dans "l'homme symbiotique" la notion d'entreprise fractale qui me semble tout à fait intéressante à intégrer dans la réflexion.

Précédemment il y a eu l'organisation taylorienne ordonnée, hiérarchisée, programmée. J'ai dans l'idée que demain nous aurons une organisation plus proche de ce que la nature met en œuvre, la reproduction de modèles collaboratifs à différentes échelles.

La notion de fractale permet de reconnaître le principe d'invariant d'échelle. A des échelles différentes, les même formes sont reconnaissables. Vous vous souvenez peut-être de cette publicité où la caméra placée dans l'espace partait d'une vue grand angle sur les planètes pour zoomer sur notre terre, une maison, un individu, sa peau … jusqu'à présenter une image de sa structure atomique semblable à celle de départ.
Semblable mais pas identique, ce sera une caractéristique des nouveaux modèles d'entreprise que de reconnaître la particularité. Jusqu'ici, les modèles cherchaient à généraliser en gommant le particulier pour ne retenir que le commun. Les entreprises fractales réussiront si elles exploitent correctement la richesse de leurs capacités particulières.

On dit en parlant de forme fractales que "le tout est dans la partie et la partie est dans le tout". Dans une entreprise fractale, une équipe fonctionnera comme une entreprise, et l'entreprise fonctionnera comme ses équipes.

Le modèle Agile a commencé à poser les bases de ce fonctionnement. Les équipes sont engagées dans la production d'un logiciel fini avec le client. Ce sont des équipes entrepreneuriales. Elles ont cet esprit d'entreprise, engagées vers la réussite, ne laissant aucun obstacle les ralentir, elles ont autonomie et pouvoir. Tout du moins elles le devraient. Elles ré orientent régulièrement la production en prenant en compte les signaux émis par l'environnement du produit.

Quand l'entreprise intégrera la logique fractale, elle comprendra comment il faut reproduire le modèle de fonctionnement de la base vers les niveaux supérieurs.
Au niveau de la gestion des portefeuilles par exemple. Les équipes de terrain livrent régulièrement des produits finis. Les portefeuilles seront donc tôt et régulièrement garnis de produits disponibles dans une version, incomplète peut-être, mais utilisable dans les fonctionnalités développées (les plus importantes ayant été développées en premier).
Dans une organisation fractale, une équipe de gestion de portefeuille aura une structure semblable à celle des équipes de production Agiles : autonomie, sens de l'entreprise, client embarqué, priorité à la valeur client… leur produit sera un backlog de versions des produits en cours de développement. Elle ré orientera régulièrement la production en prenant en compte les signaux émis par l'environnement de l'entreprise.

Au niveau supérieur l'organisation héritera de ces principes. Le management tel qu'on le connait aujourd'hui est certainement amené à se métamorphoser. L'entreprise Agile sera fractale (et réciproquement, l'entreprise sera dans les hommes et les hommes seront dans l'entreprise.

Read more...

Contingence n'est pas un terme du vocabulaire courant. C'est dommage, parce qu'il désigne un état de fait qui, lui, est très courant: celui qui fait apparaitre les choses que l'on n'attend pas.
On utiliserait davantage le mot "hasard" au quotidien pour désigner cela. Pourtant le sens porté par le mot est très différent.

En philosophie on définit 4 états de faits ou d'existence:

1. Impossible : ce qui ne peut pas être,
2. possible : ce qui peut être,
3. nécessaire: ce qui ne peut pas ne pas être,
4. et enfin, contingent :ce qui peut tout aussi bien être ou ne pas être.

Chaque fois que je prépare un exposé de l'agilité pour un public non initié, j'en profite pour retravailler mes fondamentaux et rafraîchir mes idées.
Cette fois je suis remonté aux sources pour comprendre comment était parti le mouvement Agile et j'ai trouvé cet article d'InfoQ trés éclairant et qui illustre bien la notion de contingence.

Nous découvrons de meilleures manières de développer du logiciel en le faisant et aidant d'autres à le faire.

Les 17 développeurs qui se sont réunis en 2001 à Salt Lake City n'étaient pas venu dans l'idée de créer une révolution organisationnelle planétaire.

La réunion de 2001 était la fin d'une décennie de travail pour nous tous, ce n'était pas le commencement de quelque chose ou la fin de quelque chose, c'était le milieu de quelque chose. … C'est la fin de l'histoire , pas le commencement de l'histoire.

Ils étaient surtout venus échanger à propos de technique . Il se trouve que beaucoup d'entre eux connaissaient le langage Smalltalk (premier langage objet) et avaient donc une longue expérience de l'approche objet qui poussait une nouvelle façon de réaliser les programmes.

Nous faisions des programmes, avançant par cycles ou quelque chose comme ça… sans même savoir comment le faire… mais nous avons senti que c'était très important… utilisant notre connaissance respective et la mettant ensemble d'une manière qui était constructive plutôt que contestataire.

Ils ont cherché un mot pour qualifier leur façon de développer , ils ont longtemps utilisés le terme "Léger" mais celui-ci portait une mauvaise image. Ils ont cherché autre chose, proposé d'autres mots, une quinzaine, qu'ils ont soumis à un vote. Finalement le terme "Agile" est sorti, sans faire l'unanimité d'ailleurs.

Lié au développement de l'approche objet, les années 90 voyaient apparaître la notion de "pattern" - terme difficile à traduire en un seul mot. Les "pattern" sont des habitudes de comportement (en programmation ou autre) que l'on peut isoler et identifier comme conduisant de façon régulière à un même type de résultat.
L'idée de trouver des "pattern" pour qualifier leur travail est donc venu naturellement dans la continuité des centres d'intérêt du moment.

Le Web était en ébullition en 2000 mais moins banalisé qu'aujourd'hui. Il était assez naturel pour des développeurs de publier les idées sur la toile. Ils l'ont fait sans soigner particulièrement la présentation, en html 2.0, technique qui datait déjà de quelques années.
Ils ont eu l'idée de permettre au visiteurs de signer le manifeste, ce qui a sans doute eu un impact particulier en faisant passer ce dernier de la consultation au ralliement.

Ce que nous décrivions était ce que tant de personnes faisaient ou voulaient faire de toute façon. Alors ils sont venus sur le site Web et ont signé de leur nom , il y a eu des centaines de personnes qui sont venues et se sont inscrites. Ce n'est pas que nous avons poussé quiconque, beaucoup de personnes l'attendaient, au moment où c'est apparu elles ont dit : oui ! c'est ça que je voulais voir arriver.

Voilà beaucoup d'élément qui entrent en résonance et contribuent à l’essor de l'idée Agile. Mais cela reste insuffisant cependant. Il existe des milliers de communautés dans lesquelles quelques milliers de gens partagent des affinités et échanges des pratiques. Cela ne suffit pas à révolutionner l'industrie ou la société.

Un ingrédient supplémentaire est venu s'ajouter au mouvement, la rencontre avec un autre besoin.

Les recommandations techniques des 17 amenaient certainement des changements culturels, mais ils n'en mesuraient pas totalement l'importance. Pourtant, centrer le travail sur le logiciel fait passer le processus documentaire au second plan. C'est juste l'inverse de l'approche projet traditionnel.
En 2000 l'armée américaine avait sorti une étude dans laquelle elle concluait, sur un échantillon de 35 milliards de dollars de projets réalisés, que 75% de l'argent avaient été alloué en totale perte.
L'industrie du logiciel américaine était en recherche de nouveaux modèles. L'Agile Manifesto tombait bien.

Alors que les créateurs étaient conduits par les forces technologiques et publiaient donc le Manifeste Agile principalement dans cette perspective, l'industrie était captée par le message culturel donné par le Manifeste. Il semblait apporter une réponse aux questions qu'elle se posait au même moment quand à l'efficacité des projets.

Convergence d'idées et de besoin. Mais il manquait encore un point d'accroche, un endroit de rencontre. Et c'est l'Agile Alliance qui l'a apporté.

En 2002… nous pensions : toutes ces personnes veulent pousser le Manifeste Agile, elles veulent nous rejoindre… rejoindre qui ? Il n'y a rien à rejoindre. Et j'ai dit : pourquoi est-ce que nous ne commencerions pas quelque chose ? nous pourrions l'appeler Agile Alliance ou quelque chose comme ça, et ce sera quelque chose que les gens pourront rejoindre et à laquelle ils auront la sensation d'appartenir…

10 ans après, 35% des entreprises américaines désignent l'Agilité pour caractériser le processus projet qu'elles utilisent [Forester 2009].

La contingence est un processus de génération dans les systèmes complexes. Il n'y a pas "une" volonté qui conduit à la naissance d'un système. Il y beaucoup d'éléments, beaucoup de rencontres, de relations et d'opportunités. Il y des stimuli et des réponses, chacune pouvant déclencher d'autres stimuli et d'autres réponses.

Beaucoup d'amorces de systèmes ne se développent pas ou meurent.

Mais parfois, il apparait quelque chose qui se développe et s'étend: une chose qui est et qui aurait pu tout aussi bien ne pas être.

Read more...

If your organization requires success before commitment, it will never have either.

~ Seth Godin

A la suite de mon article sur High Performance Tree Lyssa Adkins m'a fait le plaisir de le poster sur son site et de lui donner une publicité par le biais de son mail hebdomadaire "inspiration for Agile coaches" envoyé aux "alumni" (anciens élèves) de sa formation.
Une occasion pour moi de partager avec vous l'inspiration du jour.

Dear Jean-François,

Success before commitment...the chicken and the egg. I am reminded of this quandary when people say, "We have been talking about colocating for about a year now and people just don't see what they'd get out of it, so we're still in our cubicles."
Of course you don't see what you're going to get out of it until you DO IT. People need to commit, at least to an experinemt for a sprint or two, to see the benefits for themselves. Standing back demanding to know what success is guaranteed to occur before we try is a sure way to keep the cube walls up. (And many other walls up, some thicker and taller than cube walls)

This is true about anything in agile: It's only an experiment, and we will inspect the results.

Lyssa

New agile coach stories to share:Jean-François Jagodzinski tells us how he uses the High Performance Tree (in French!)
Thanks for sharing, Jean-François.

Don't miss the chance to learn about "setting the stage for high performance" in the
Coaching Agile Teams class + the new class, The Coaching Stance.

Read more...

Le sujet du contrat au forfait sur les projets Agiles est discuté depuis longtemps, j'y ai moi même consacré un peu de temps il y a quelques années et j'en ai aussi parlé en conférence.

Je passe sur les différents points de vue quand aux détails ou au limites du terme "forfait" pour arriver au cœur du sujet : la volonté pour un client de déléguer la réalisation d'un logiciel à un fournisseur.

Il semble que la question fondamentale sur laquelle tout le monde s'accorde est celle de la relation entre la façon de définir le contrat et les comportements qui vont en résulter.
L'idée, c'est que le type de contrat en usage dans le domaine du logiciel ne laisse pas la place aux comportements en phase avec les pratiques Agiles. Partant, un autre type de contrat doit être recherché pour permettre aux pratiques Agiles de trouver leur place dans la sous-traitance. CQFD

Cette idée, que le contrat est le problème à adresser "à priori", est fausse. Ce n'est pas au contrat de permettre l'adoption de nouveaux comportements, c'est juste l'inverse.


"The machine that changed the world" relate la façon dont les processus de production dans le domaine automobile ont modelé le visage de l'industrie telle qu'on la connait.


L'histoire démarre avec l'apparition de la production de masse chez Ford (suivi de la bureaucratie qui l'accompagnera chez GM). Les solutions choisies ont été guidées par des idées et des tempéraments. Les contextes ont changé, les hommes ont disparus, le génome des sociétés a gardé le code.


Changement de lieu et de contexte quelques décennies plus tard. Les japonais se lancent dans l'automobile. Ils ont perdu la guerre, ils se trouvent avec des contraintes politique, géographiques et financières qui n'ont rien à voir avec celles du temps de Ford.

Pour réussir ils doivent penser autrement, c'est le départ d'une nouvelle idée d'organisation de la production qui sera (beaucoup plus tard) nommée "Lean".

Chacun de ces systèmes de production a bien entendu fait appel à la sous-traitance.

Ils l'ont fait chacun dans une idée particulière de la relation qui leur semblait la meilleure pour réussir selon leur philosophie.

Dans le contexte de la production de masse le donneur d'ordre fait le design, le donne aux fournisseurs potentiels et les met en concurrence. Il leur demande leur meilleur prix pour la fourniture d' un nombre de pièces définies (10000 par exemple).

Le prix, la qualité et la capacité (fiabilité) à livrer sont les critères de sélection.
Coté fournisseur, les solutions sont recherchées autour de l'adaptation des standards existants de façon à minimiser les frais. Innovation et créativité coté produit ne font pas partie du deal. Coté acheteur, le prix est essentiel, le changement de fournisseur est fréquent et se fait souvent avec un préavis réduit.

Les bases de la relation sont claires coté fournisseur comme coté acheteur. Il est évident que c'est chacun pour soi (en particulier dans les moments difficiles quand les ventes d'automobiles déclinent). La relation est comprise par chacun comme étant de court terme par essence.

De par sa logique différente, Toyota à fait d'autre choix lors de la mise en place de son usine de Takaoka. Le processus, plus fragile (pas de stock tampon, besoin d'adaptation des modèles…), nécessitait une relation fournisseur plus robuste. Des accords plus proches du partenariat que de la sous-traitance sont établis, souvent accompagnés de prises de participation.

Mais revenons au monde du logiciel...

Les contrats dans le monde du développement logiciel sont nés (la faute au génome sans doute) avec l'état d'esprit des pratiques de la production de masse.

Les deux même principes en sont à la base : on a vu à l'œuvre le "chacun pour soi" avec l'externalisation des développements dans les pays émergents notamment.
Il est par ailleurs évident pour tout le monde que la relation client - fournisseur (SSII) n'a pas vocation à être durable.
Ces paradigmes de base ont assis la relation dans une confiance très relative. Le mode de contractualisation à été copié et à peine adapté de celui du monde industriel.

Il y a bien sur quelques variantes liées à la nature immatérielle de la fourniture (grosse différence avec le cœur de la production de masse). Mais curieusement les variantes sont moins dans la démarche suivie ou l'adaptation des contrats que dans l'adoption mimétique des comportements.

Plutôt que d'aborder les caractères immatériel, créatif, unique... du produit logiciel comme une spécificité à laquelle il faut adapter le contrat, on va faire l'inverse : on va chercher à recomposer une image "matérielle" (objective) du produit.

L'organisation cliente va fournir l'équivalent du design de la production de masse (Cahier des charges détaillé, parfois maquette) et mettre en compétition les fournisseurs sur la partie réalisation du produit. Le prix, la qualité et la capacité à livrer dans les temps sont les critères de sélection (le client considérera au passage qu'il a la capacité de réaliser un contrôle qualité sur le produit).

Pourtant, le système d'information étant non matériel, ces critères sont purement subjectifs. Il n'y a pas de masse à mesurer, de temps d'usinage moyen constaté, de chronométrage des assemblages, de stocks de sécurité, d'atelier à visiter, de soudures à radiographier … rien qui permette d'avoir la moindre indication un peu objective quand à la vraisemblance des engagements annoncés.

Qu'a cela ne tienne on va y remédier.

Par le biais de rationalisations plus ou moins élaborées (de la méthode maison aux "standards" ayant mobilisés des armées de spécialistes - points de fonctions par exemple) tout le monde va tenter de donner un figure objective à ces conjectures subjectives.

On bascule alors dans un monde un peu ubuesque où à force de manipuler des hypothèses et de les transformer en forme de modèles on va progressivement arriver à y croire.
C'est la principale raison du temps nécessaire à la prise de décision. Partant de la croyance il faut passer à la persuasion (de soi) puis à la conviction (des autres). Plus il y a de personnes concernées, plus le processus est long.
Mais la décision finale reposera quand même sur une simple question d'envie. Elle sera guidée par une sorte de principe ataraxique (c'est-à-dire au mieux le plaisir, au pire la recherche d'absence de douleur).
Le plaisir pourra être celui de jolis chiffres, celui d'une cohérence intellectuelle abstraite, celui de la réussite d'avoir mis en adéquation notre fournisseur préféré avec les chiffres qu'il nous donne…
En tout état de cause on aura réussi à mettre fin à une inquiétude avec la meilleure bonne conscience possible.

Le procédé consistant à se conforter dans une prise de décision est très ancien. C'est simplement la façon de faire qui est moderne. La décision sur l'emplacement de Byzance à été décidé grâce au vol des oiseaux (ornithomancie), aujourd'hui nos runes sont des chiffres dans un tableau excel (je propose donc le terme d'excelomancie).

Beaucoup de tentatives que l'on voit pour mettre au point un contrat Agile se heurtent à l'excelomancie. En d'autre termes, elles relèvent de ce qu'on appellerait en Lean de l'optimisation locale. Il s'agit de rendre un dysfonctionnement supportable plutôt que de mettre le système en cohérence.









Adressons les comportements, les contrats suivront

Read more...