Philo SI

Jean-François Jagodzinski - Le Blog

Subscribe to RSS feed

Donner du feedback c'est parler au Prince

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...

Scrum master le métier oublié

Avec la diffusion de l'agilité et de Scrum en particulier on commence à réaliser que des métiers apparaissent ou se révèlent.

Les acteurs de l'agilité passent les messages : Développeur n'est pas une position d'attente, sorte de purgatoire entre la sortie d'école et l'entrée dans le sérail de l'entreprise, c'est un métier qui mérite considération. De même Product Owner n'est pas une fonction temporaire que l'on ajoute à un Chef de service surbooké.

Le message est différent pour ce qui concerne le Scrum master. Scrum master n'est pas vraiment un métier. C'est un rôle plutôt. D'ailleurs on peut le faire tourner, changer de Scrum master à chaque Sprint. Et puis le Scrum Master n'a pas de livrable, autant dire qu'il ne produit rien, c'est embêtant coté balance comptable, on cherche donc à l'associer à mi-temps (ou davantage) à la production.

On se trompe. Scrum master c'est un métier. Il est légitime et nécessaire. Peut-être manquons nous de certaines données pour bien le comprendre.

Le Scrum master est un gestionnaire d'énergie. Il a une fonction simple : maximiser l'énergie du groupe consacrée à l'activité. Pour autant son résultat n'est pas mesurable, l’activité est la résultante d'un système complexe dont on ne peut pas attribuer la valeur à l'une ou l'autre des parties. C'est dur, mais il va falloir que les entreprises apprennent à vivre avec la complexité.

Vous avez peut-être constaté que les développeurs développent mieux quand ils sont concentrés sur le travail à faire. Dans ce cas l'énergie est dirigée vers l'activité. Que quelqu'un entre dans la pièce et appelle l'attention (en parlant fort, en pleurant…) et le flux d'énergie va changer de direction, l'activité s'arrête et l'on gère l'intrusion. La quantité d'énergie disponible dans l'équipe est constante, une personne comme un groupe ne va pas créer de l'énergie par magie. Il y a simplement transfert de l'énergie disponible d'un type d'activité à un autre en fonction des circonstances de la vie.
Le rôle du Scrum master est de limiter les gaspillages d'énergie du groupe. Pour ce faire il est investi de fonctions d'appareil (surveillance de processus, surveillance de la frontière externe), de lead (vous n'aviez pas déjà essayé ça ?) de régulation (j'en entend qui ne disent rien...) … son énergie à lui est consacrée à l'écologie de l'écosystème.
Dit autrement, les actions que l'on demande aux Scrum master ont un sens par rapport à l'écosystème et à son efficacité, c'est à dire la quantité d'activité produite relativement à la quantité d'énergie dépensée.
Simplement connaître les règles Scrum et les faire respecter permet d'assurer le cadre de sécurité de base. C'est insuffisant pour amener une équipe à être performante.

Il est rassurant de constater que l'on a déjà expérimenté et abandonné (enfin pas encore partout) nombre de méthodes pénibles telles que l'esclavage, le fouet, le chantage…
La voie choisie actuellement repose sur des constats davantage humanistes. Il semble que si les individus se retrouvent dans une position qu'ils apprécient ils produisent avec plaisir les uns pour les autres. La question revient alors à mettre en place les conditions favorables. Le cadre Agile est une base pratique mais il ne dit pas tout. Il est nécessaire d'en connaître bien davantage sur la dynamique d'équipe, les relations interpersonnelles, la théorie des systèmes, l'accompagnement du changement, la motivation… pour savoir naviguer dans la brume des relations humaines.

Bref, il va nous falloir des Scrum master professionnels.

Read more...

L'entreprise Agile sera fractale

,

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...

Les enseignements du jeu de billes rouges au Cara

La soirée du CARA du mois dernier portait sur le thème de la rémunération des équipes Agiles. Pour introduire la soirée, j'ai animé le "jeu des billes rouges" initialement créé par E. Deming.

Le principe du jeu est de constituer une sorte de mini entreprise. Symboliquement la production est représentée par des billes. Celles-ci sont dans un conteneur et doivent être prélevées par des ouvriers à l'aide d'une palette spéciale qui contient 50 emplacements. Une fois les billes prélevées la palette est montrée aux contrôleurs. Il faut dire que s'il y a beaucoup de billes blanches (correctes), il y a quelques billes différentes (jaunes dans mon atelier) qui représentent les défauts. Les contrôleurs comptabilisent les défaut présents et valident ou non le lot produit.

La séance commence par l'explication du jeu. Prélever des billes et limiter les défauts. Seules 4 billes jaunes sont tolérées dans un prélèvement. Il y a différents rôles à occuper et une procédure à suivre.

J'ai ensuite recruté les collaborateurs : 4 agents de production, 1 contrôleur qualité, un contrôleur chef et un gestionnaire de production pour tenir à jour les tableaux de bord.

Nous avons fait 4 itérations. Voici le résultat de la soirée

Le nombre de défaut de la première itération est relativement important. Heureusement en tant que responsable du site j'avais eu l'opportunité de suivre des formations sur le teambuilding. J'en ai fait profiter l'équipe lors d'une séance courte mais efficace.

En conséquence, la seconde itération a été meilleure . A l'exception notable de Françoise qui a fait pire qu'à la première itération. On avait bien noté pendant le team building qu'elle avait été plutôt distraite et ne participait pas à fond. Y a pas de hasard…

Il fallait trouver quelque chose pour motiver l'équipe. Comme on était à la veille de Pâques j'avais apporté un gros lapin en chocolat. Celui qui réaliserait la meilleure performance pourrait l'emporter. Comme on peut le voir, la troisième itération présente l'écart le plus faible par rapport à l'objectif. Jean a même été largement en dessous de la tolérance, je l'ai félicité et il a reçu le lapin.
Mais la motivation a fait monter l'esprit de compétition et Françoise (encore elle) a essayé de tricher en plaçant les billes avec les doigts sur la palette. C'est tout à fait contraire à la procédure même si cela était très discuté. En tout état de cause, il y avait un patron, moi, pour faire respecter les consignes .

Ma direction n'était pas du tout contente. Le quota n'était pas respecté. Il fallait faire un exemple. C'est assez naturellement l'élément perturbateur qui a été licencié. Françoise nous a quitté et on a démarré la quatrième itération avec le reste de l'équipe. Sébastien a commencé à son tour à contourner la procédure. Les équipes Agiles sont décidément intenables ! Heureusement qu'on était à la dernière itération.

Au final l'objectif à été atteint, mes choix avaient portés leurs fruits. J'ai été promus à la direction nationale des sites.
Je dois remercier mon gestionnaire de production, Marc, pour son soutien et sa clairvoyance dans ces moments difficiles.

Voilà pour l'histoire de cette soirée.

Que faut-il en penser ?

Il y a dans le bac environ 1/4 de billes défectueuses (jaunes). Ca fait beaucoup. La capacité d'un joueur à influencer le résultat du tirage est très limité. Lorsqu'on retire la palette chargée du bac, on ne sait pas choisir celles qui vont rester dans les 50 emplacements. Le système est largement non maîtrisable.

Et pourtant on trouve des corrélations très intéressantes. Des corrélations qu'il est facile de considérer comme des conséquences. A chacune des actions, team building, récompense, licenciement il se passe quelque chose. Et je peux à chaque fois trouver un angle de vue capable d'expliquer comment mes actions ont eu des conséquences (positives dans notre expérience) sur la production.

C'est troublant non ? En tout cas cela pose beaucoup de questions. Quelle est vraiment la réalité dans notre entreprise ? De combien de croyances sommes nous l'objet ?

La discussion qui devait suivre portait sur la façon de gérer les évolutions de rémunération dans les équipes Agiles. On a eu du mal à sortir du jeu et à aborder correctement le sujet. Les discussions les plus intéressantes je les ai eu ensuite, autour du verre de fin de soirée. Et à faire tomber les croyances, on en est venu à quelques conclusions simples.

Mais je vous les donnerai dans un autre billet. Ce serait peut-être un peu trop pour aujourd'hui.

Read more...

Naissance du mouvement Agile et contingence

, , ,

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...

L'agile n'est pas encore mort

, ,

Je viens de poster un commentaire à l'article de Sébastien Douche intitulé "l'Agile est mort" sur son blog.

Je vous poste le contenu de mon commentaire ici.


Oui. Je partage cette amertume.
L'idée Agile est belle et voir comment elle est travestie et revendue heurte notre idéal et remet en cause les perspectives de l'aboutissement que pourrait être un monde Agile.

Je parle au présent mais pas encore au passé parce que je suis d'accord avec toi "Il faut avoir une vision systémique du mouvement (Agile)".

Ce système est différent de l'autre. Ces 2 systèmes sont en concurrence pour la survie, c'est trés darwinien. Ces systèmes sont habités par des êtres humains. Certains ont tout à gagner ou tout à perdre dans l'un des systèmes (ils sont inadaptés à l'autre).
L'une des façons de faire disparaître le système concurrent c'est de le nier en tant que système différent et de l'assimiler. C'est la différence entre révolution et évolution. C'est ce qu'essaie de faire le monde traditionnel. Dans le même temps, c'est facile pour lui, il fait ça depuis toujours. Il y a eu 25 (ou 50 ?) méthodes en informatiques (Merise, SADT, SA/SD, RUP, TTUP parmi celles que j'ai pratiquées ) + des modèles comme ceux d'UML.
La première chose que fait une organisation quand elle adopte une méthode, c'est de supprimer ce qui ne lui convient pas. J'ai TOUJOURS vu ça. Et c'était normal dans l'esprit de l'organisation (la théorie et la pratique sont 2 choses différentes). Par conséquent sa façon d'aborder l'Agilité est tout à fait cohérente. Il n'y a pas de conscience particulière, c'est un mode de fonctionnement automatique de l'ancien système. Il grandit en mangeant les méthodes qui apparaissent (manger c'est désorganiser un organisme pour en récupérer uniquement la substance qui contribue à notre vie).

En ce sens véhiculer le concept en tant que "méthodes" Agiles et dévastateur.

Mais si on discute de ça aujourd'hui à grande échelle, c'est parce qu'il y a eu 2001 et le manifeste Agile. Je suis certain que des tas de systèmes d'organisation nouveaux sont apparus ici ou là et sont morts faute d'avoir été amenés en contact avec une masse suffisante d'adeptes.
Pour faire exister un concept il faut lui donner un nom. A partir du moment ou l'on pouvait associer un nom à "ça" (ce que l'on faisait sans le dire parce que c'était mal, ou bien entre nous, ou quand j'étais étudiant... ) en lui donnant une consistance plus globale mais simple (4+12 principes) il était plus facile de passer l'information. Autre message (subliminal) : vous avez le droit de faire ce que vous faites, et même on vous y encourage.
Le fait que les signataires soient devenus consultant... oui ben ils ont vieilli aussi. Ce qui est important c'est que le message d'origine n'est pas "nous avons réfléchi à une nouvelle méthode" (en tant que consultants) mais "nous découvrons une nouvelle façon de faire du logiciel en le développant et en aidant les autres à le faire" (en tant que développeurs donc).

Perso je ne jeterais pas le bébé avec l'eau du bain. On peut discuter des principes du manifeste, comme on peut le faire avec la charte des droits de l'homme (si, si, il y a des trucs dont je discuterais bien). Ils existent parce que leur contenu à été suffisamment inspirant pour amener des hommes à créer un nouveau système viable. Ils continuent d'exister tant qu'ils restent la base d'un système.

Scrum Alliance, certifications... oui ça me gêne aussi Est-ce que ça a participé à l'amplification du mouvement ? Est-ce que ça lui a été nuisible ? Est-ce que ça à été bon mais que ça ne l'est plus ? Est-ce que Schwaber va sauver le mouvement avec Scrum.org ? Est-ce que le PMI va participer à la digestion de l'agilité par l'ancien système ? ... à suivre, en tout cas ça ressemble plutôt à un système vivant (bactéries, globules blanc, virus... est-ce que notre système biologique est un havre de paix ?).

Les principes Agiles ne sont pas morts en tout cas. Un message très proche (sans l'étiquette "agile") est relayé en dehors du monde de l'informatique par des gens comme Stephen Denning (Radical management) ou les fondateurs de 37signals (Rework).

La question est : est-ce que ce message est en phase avec le monde à venir?

Et ça je ne sais pas, c'est une question de valeurs
- Si le monde actuel est principalement caractérisé par des jeunes qui se rencontrent via twitter pour mettre fin à une dictature, c'est possible
- Si le monde est principalement caractérisé par des jeunes qui cherchent l'adrénaline dans les frissons du CAC40, c'est compromis

En tout cas, moi j'opte pour la première représentation. Je me bat pour le nouveau système (mais j'ai pas de mérite c'est une question de survie je suis inadapté dans l'ancien).

Merci en tout cas pour m'avoir donné l'occasion de formuler ces idées qui traînaient dans un coin de ma noosphere

JF

Read more...

Inspiration for Agile coaches

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...

High performance tree - métaphore de la performance

,


Dear Lyssa,
When we met in June we discussed the high performance tree and I told you I was using it to set the vision of the Agile journey with the teams I coach. You asked me to write an article in French about the performance tree and I promised I would to it.
Done ! :-)
Thank you for who you are
Kindest regards
Jean-François


L'Agilité est un monde plein de métaphores. C'est tout à fait cohérent avec l'essence de l'Agilité. La métaphore parle à notre coté émotionnel et stimule des mécanismes de compréhension et de mémoire différents de ceux atteints par la voie rationnelle.

Le livre de Lyssa Adkins : Coaching Agile Teams est mon compagnon depuis un bon moment. Le coach Agile fourni des repères à une équipe, mais dans ce métier émergent il a bien besoin lui aussi de trouver les siens. Ce livre est une source d'inspiration pour moi, et j'ai repris, entre autres, la métaphore de l'arbre de haute performance que j'utilise régulièrement pour donner une vision à l'équipe et positionner le coach dans le contexte.

On ne passe pas à l'Agilité pour obtenir d'une autre façon les mêmes résultats que l'on aurait obtenus en mode traditionnel: notre but est d'être meilleurs, bien meilleurs même, et d'arriver à des résultats qu'on se croyait incapable d'atteindre. C'est une grande satisfaction personnelle pour chacun des équipiers que d'être dans une grande équipe .
Et ça change le regard des clients et de l'entreprise.

Le chemin vers la performance passe par la conscience et l'envie (l'augmentation de performance ne peut pas être un imposée par l'extérieur). Donner accès à l'une et favoriser l'autre sont deux des axes de travail du coach.

Le démarrage d'une nouvelle équipe est un moment privilégié. Les équipiers peuvent déjà se connaître, ou pas. Certains on déjà fait du Scrum, d'autre non. Certains ont 25 ans, d'autre 50…
Ils ont été formés la plupart du temps, mais parfois pas. Dans leur projets précédents ils ont pu réussir ou échouer. Dans une équipe Agile précédente ils ont mis en place des pratiques particulières qu'ils ont l'intention de reproduire dans cette nouvelle équipe, ce ne sera pas forcément l'avis de tout le monde…

Et puis il y a le coach. Certains découvrent que ça existe et s'interrogent sur sa place. D'autres pensent que cela va faire leur faire un peu d'ombre, l'Agilité ils connaissent, ils n'ont pas besoin qu'on leur explique.

Au démarrage d'une équipe j'anime différents ateliers pour permettre à une équipe de se découvrir et de se constituer. L'un des ateliers consiste à positionner clairement l'esprit dans lequel j'interviens, quelle est ma perspective et où est ma place.

L'un des 2 outils que j'utilise est l'arbre de haute performance.

Cet arbre a ses racines dans les 5 valeurs Scrum : l'engagement, le courage, l'ouverture (ou la franchise), le focus et le respect.

L'arbre de la haute performance se développe en s'alimentant sur ces valeurs. Si elles sont fortes l'arbre grandit et la ramure se développe pour aller chercher la lumière, l'arbre se renforce, ses racines grandissent en retour et tout l'arbre en profite.

Il devient un endroit engageant. Il contient les branches que l'équipe reconnaitra pour les avoir mises en place : l'autogestion, la direction par le consensus, le pouvoir de décision, la confiance en sa capacité à faire, la propriété de ses engagements et de ses résultats, la motivation par la confiance plutôt que par la crainte ou le ressentiment, les désaccords constructifs…

C'est cet arbre qui porte les fruits de la haute performance : la valeur métier est obtenue plus rapidement, la valeur obtenue est la juste valeur, les résultats atteignent un niveau insoupçonné, une équipe capable de tout affronter, une place ou chacun peut grandir.

Le coach n'a pas de place dans cet arbre , c'est celui de l'équipe. Sa place est à coté et c'est pour cela que dans le dessin je m'ajoute sous la forme du jardinier.

Je réutilise cette métaphore par la suite quand il s'agit de mettre en évidence les obstacles sur la route.
Il permet de repositionner la vision du départ et d'interroger l'équipe : "Est on satisfait des fruits que l'on obtient ?", "où est-ce que nos racines sont faibles ?" , "quelle branche devrions nous renforcer"…
Les équipes créent leur propre chemin et chaque arbre est différent.

Read more...

Forfait Agile - le contrat n'est pas le problème

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...

Attracteur étrange

,

C'est assez étonnant.

L'Agilité en gestion de projet c'est l'inverse d'à peu prés tout ce que l'on apprend concernant la façon de mener des projets.
Pourtant, la plupart du temps lorsque j'en parle, le concept est accueilli comme une évidence. Tout le monde le savait qu'il y avait une autre voie. Souvent d'ailleurs j'ai l'impression que cet accueil est accompagné d'un sentiment de soulagement. Ou bien même d'espoir.

Trop facile, ce n'est pas naturel, il y a une aspiration à croire.

Je découvre de mon coté qu'on approche de quelque chose. Je le sentais bien depuis plusieurs années mais j'ai quand même l'impression que le mouvement s'accélère.

On approche de quelque chose...mais je ne sais pas de quoi.

En observant et en cherchant à relier ce que je vois et ce que j'entends, le modèle qui me vient à l'esprit est celui de l'attracteur étrange. Mis en évidence par la science du chaos, un attracteur étrange ressemble à une force capable d'ordonner les événements divers autour d'un noyau (qui peut être multiple). Pour autant cet ordre est incompréhensible et le placement dans le champ de l'attracteur des événements à venir est non prédictible.


L'attracteur dont je parle est relatif au vivant. Il a un rapport avec l'information et l'information n'existe pas en dehors du vivant - la montagne ne sait pas qu'elle est sous la pluie. C'est une chose que l'on a sans doute oublié lorsqu'on a basculé dans la technologie. Les projets du système d'information ont un lien d'une façon ou d'une autre avec les êtres vivants.

Dans cet attracteur on trouve une lumière. On n'était pas assez proche pour la voir. On croyait pourtant être éclairés .



C'est l'histoire du gars qui cherche ses clés au pied du lampadaire :

Vous êtes sur de les avoir perdues ici ?


Pas du tout. Mais il n'y a que là que je voie clair






A la lueur de cet éclairage nouveau on découvre un droit de citer au désordre et on réhabilite le doute.
Au travers de la science du chaos on se retrouve autorisés à croire que nos modèles manquent d'humilité. Au travers du développement de la pensée complexe et de la vision d'Edgard Morin on se retrouve avoir le droit de dire que la simplification est mutilante.

La lumière de cet attracteur n'explique pas, elle attire, elle libère.

Un petit faisceau est pointé vers l'Agilité. Ordre et désordre, processus récursif de construction - déconstruction, auto-éco-organisation des groupes humains. Ces processus sont à l'oeuvre dans l'Agilité. Mais pas seulement, ils le sont aussi dans le web social, ils le sont dans certaines entreprises.

C'est passionnant. Selon toute apparence le mouvement Agile est en vibration cohérente avec le monde qui arrive.

...s'il arrive.


Provenance image : http://www.matierevolution.fr
http://www.wired.com/

Read more...