Jagodzinski JF

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:

Impossible : ce qui ne peut pas être,
possible : ce qui peut être,
nécessaire: ce qui ne peut pas ne pas être,
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.

2 comments

L'agile n'est pas encore mort

Friday, October 7, 2011 10:13:51 AM

Philosophie, Agile, Méthode

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

No comments

Inspiration for Agile coaches

Tuesday, September 27, 2011 7:29:30 AM

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.

No comments

High performance tree - métaphore de la performance

Wednesday, August 10, 2011 4:43:41 PM

Agile, Coaching

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.

No comments

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

Wednesday, May 18, 2011 2:25:31 PM

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

No comments

Attracteur étrange

Thursday, March 17, 2011 3:52:02 PM

Philosophie, Agile

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/

No comments

Les modèles impressionnistes

Sunday, February 13, 2011 10:52:13 AM

Philosophie, Agile, Modèle

Je ne peints pas les couleurs sur la toile, je les peints dans l'œil de celui qui regarde

Je n'ai pas retrouvé la source de cette citation, elle vient d'un peintre impressionniste je crois, peut-être Monet.

Les impressionnistes ont mis au point une nouvelle façon de transmettre l'information sur les paysages qu'ils peignent. Il ne cherchent plus à reproduire fidèlement une idée, ils cherchent à reproduire un sentiment, des impressions.

Le passage à l'Agilité s'accompagne de mutation semblables. Et c'est peut-être même l'entreprise moderne qui chemine vers ces nouveaux modèles de transmission de connaissance.

C'est un des points d'achoppement (il y en a beaucoup) de l'approche Agile relativement aux approches classiques. Notre éducation comme nos pratiques d'entreprise nous ont amené à confondre la réalité avec notre modèle. Et aussi à croire en nos modèle davantage que dans les signaux qui nous viennent de la réalité.

Le chemin est subtil qui nous amène là. Notre coté cartésien nous fait nécessité à croire qu'il existe des lois d'organisation des choses autour de nous. Par notre capacité de réflexion abstraite on est capable de les connaître (et de les modéliser et de les transmettre grâce au modèle). Ce n'est pas tout à fait faux, disons que c'est vrai dans certaines limites.

C'est comme la théorie de Newton. Les corps s'attirent en proportion de leur masse qui est invariable. Ça marche bien tant qu'on néglige la vitesse (et elle est négligeable dans notre monde de perception immédiate). Cette théorie à été vraie pendant plus de 2 siècles, jusqu'à l'arrivée d'Einstein.

Parfois nos modèles sont vrais absolument. Les modèles mathématiques le sont quand ils sont fondamentaux.

Que dans ce triangle je sache à priori que la somme des angles est égal à 180° est incontestable.

Cependant, à contrario, il n'y a pas de réalité matérielle qui corresponde absolument à ce modèle. Même pas parmi les triangles que construisent les hommes. Les mécaniciens le savent bien qui ont inventé la "tolérance de côte", une mesure est juste "à quelque chose" près.

Dans le monde du système d'information il n'y a pas de tolérance de côte. Mais il y a des modèles. Et on y croit.

Dans le monde de l'Agilité il y a aussi des modèles. Mais on y croit pas plus que ça.

On fait des formations qui expliquent de façon théorique les principes Agiles, mais le modèle reste basique. C'est à travers les jeux que l'on fait ressentir les problématiques.

Le monde Agile est particulièrement féru de jeux. Chacun génère son information au travers de ses sens davantage que par la raison. C'est aussi ça l'approche empirique. La perception de l'information d'abord par notre coté animal.

Nihil est in intellectu quod non prius fuerit in sensu

Il n'y a rien dans l'entendement qui ne soit venu initialement au travers de nos sens. - John Locke (pas celui de "Lost", le philosophe du XVIIeme)

Pour autant il ne faut pas se laisser abuser. Le jeu peut générer des perceptions, pourtant c'est aussi un modèle, un modèle impressionniste mais un modèle. Le temps y est condensé, les données simplifiées, les positions codifiées.

Le seul le vrai terrain de jeu c'est celui du projet.

Pour se donner des repère les équipes Agiles réalisent aussi des modèles, le "burndown" par exemple.

Celui-ci montre sur un graphique le reste-à-faire sur le cycle de production en cours.
Suivant les équipes l'unité de reste-à-faire varie, c'est la force de l'agilité de ne pas contraindre sur les détails, mais on démarre encore souvent avec des estimations de reste-à-faire en temps.

Le reste-à-faire estimé chaque jour est tracé sur une courbe. Au début du cycle on avait tracé une courbe de référence qui montrait notre hypothèse initiale.
L'écart entre les 2 courbes montre l'écart entre la théorie de départ et la théorie revue quotidiennement.

Ne nous y trompons pas, cet indicateur malgré ses allures mathématiques est purement impressionniste.
Son utilité est de générer une impression dans l'équipe. Celle-ci va confronter cette impression avec d'autres ressentis. Des discussions vont s'ouvrir et donner lieu peut-être à des ajustements dans la réalisation travail.

Pourtant les tentations sont grandes de se raccrocher à un modèle théorique juste. Certaines équipes le peaufinent pour tenter de le rendre plus précis(en intégrant les temps quotidiens réels de présence des équipiers par exemple).
Ce n'est pas seulement inutile, c'est nocif. C'est comme vouloir tracer des contours des objets sur un tableau de Monet. On n'ajoutera rien, on perdra juste nos sens en donnant les rênes à notre raison.

C'est un défi intéressant . Il va falloir apprendre à faire avec. Les modèles de l'entreprise du XXIéme siécle seront impressionnistes c'est certain. C'est en tout cas la seule façon de récupérer la liberté de mouvement.

No comments

Communication et modèle

Wednesday, February 2, 2011 11:20:27 AM

Philosophie, Modèle, Projet, Méthode ...

On ne sait pas transmettre nos idées par duplication de cerveau à cerveau. C'est bien embêtant.

On a donc du avoir recours à différentes techniques qui nous permettent de communiquer les idées. On sait bien que nous communiquons par divers moyens, voix, gestes, expression, écrits… On connaît moins qu'il existe des niveaux d'échange différents selon les différentes idées que l'on cherche à communiquer.
En fait on peut reconnaître 4 niveaux de communication qui correspondent à 4 niveaux d'idées.

Au premier niveau le message permet de faire passer les informations sur soi "au secours!".
Au second niveau le message apporte une information simple à la communauté "Attention!".

Ces 2 niveaux sont partagés par les animaux et sans doute également par les plantes si on en croit les études les plus récentes.
Les circuits qui permettent de gérer cette information sont donc basiques, primaires, "hardcodé" dirait-on dans notre monde informatique. Ils sont très rapides et peu sujet à l'erreur.
Au troisième niveau notre message porte sur la description. C'est un messages complexe adressé à la communauté "la nourriture est abondante dans le champs de l'autre côté de la rivière". C'est un niveau essentiellement humain mais on peut penser que certains animaux le partagent (je pense à l'abeille).
Au quatrième niveau notre message porte sur l'argumentation. Niveau exclusivement humain qui met en œuvre notre matière cérébrale particulière, le neocortex, ça fonctionne moins vite mais ça a son efficacité.

On est assez fiers de notre capacité d'abstraction. Les animaux savent bâtir un modèle mental de leur environnement, très peu savent le transmettre à leurs congénères, mais aucun ne sait argumenter avec ces derniers sur l'opportunité d'aller chercher sa nourriture plutôt ici que là.

Nous si. On excelle dans ces 2 disciplines que sont la description et l'argumentation.
Enfin, on excelle… on sait communiquer des messages à ces niveaux.

Mais comme on ne sait pas répliquer nos pensées dans le cerveau de notre interlocuteur on utilise différents modèles. Pour que ces modèles soient efficaces, il faut une parfaite adéquation de toutes les parties quand au code utilisé. Si j'articule un son, par exemple "chaise", il faut que ce son évoque dans l'esprit de mon interlocuteur la même idée que j'ai présentement à l'esprit.

Avec mon fils qui vit dans la même maison que moi, il y a des chance que nos idées soient assez semblables. Avec d'autres ça dépend. On a de bonnes chances d'avoir nos idées en phase sur le nombre de pieds je pense, bois ou métal là nos idées pourraient ne pas se ressembler.

Modéliser lorsqu'il 's'agit d'éléments de notre environnement correspond toujours à généraliser. Et généraliser c'est perdre de l'information. Toujours.

Il existe une option.

Je peux t'apporter ma chaise. J'activerai alors la communication sur le niveau 2 "regarde!" et au niveau 3 je dirais juste un mot "chaise".
Quand on en parlera de chaise, je sais que l'idée que tu formeras est assez proche de celle que je forme moi-même.

Mais tu ne pourras quand même pas t'assurer qu'en en parlant à quelqu'un d'autre le message passe aussi clairement.

No comments

Le manager est il au dessus du cadre Agile ?

Sunday, September 26, 2010 12:54:17 PM

Procédure, Agile, Méthode, Projet

Une équipe que je coache s'est laissé imposé par le management métier le remplacement d'une story en cours de sprint. Le PO était en vacances, le manager de la partie métier a directement fait sa demande au management du SI qui a redescendu la demande à l'équipe.

Les équipiers sont mal à l'aise, mais disent ils, c'est difficile d'aller à l'encontre d'un ordre qui vient du management.

La question fondamentale n'est pas tant de savoir s'il fallait le faire. C'est plutôt pour l'équipe de juger de la force qu'elle a mise, de l'ensemble des mesures et des alternatives qu'elle a proposées pour défendre le cadre Scrum.

Je discutais de ce point avec le responsable des projets Agiles de l'entreprise. Son opinion est qu'il ne faut pas être trop rigoureux, tout au moins pas rigoriste.
L'Agilité c'est aussi l'adaptation. Il peut arriver qu'un PO demande un changement et s'il a de très bonnes raisons ont peut considérer sa demande.
Du point de vue de ce responsable on a trop souffert dans nos systèmes passés (projets à cycle en V) de l'excés de rigueur.

Je déteste la rigidité, la rigueur, les cadres imposés...je suis par nature un homme de service et de compromis.
Mais je ne suis pas de son avis

Scrum est fait de 2 choses :

Un espace de liberté au profit de la création et de l'adaptation au service desquels le chaos est sollicité.
Un cadre strict et une discipline forte qui permettent d'empêcher la propagation du chaos au projet lui-même .

C'est le principe du moteur à explosion . L'énergie est générée dans une chambre de combustion qui permet de la contenir.
La récupération de l'énergie est maîtrisée : celle-ci est dirigée pour générer une puissance utile.
Retirez la chambre de combustion et provoquez l'explosion, comme dirait notre ancien président ça fait pschiiiiit.

Nos problème passés venaient il vraiment de la rigidité du process ?
Parmi les raisons qui font que l'on prône la rigueur en gestion traditionnelle de projets on peut ressortir la longueur du cycle de production et la dépendance hiérarchique des tâches. Une gestion rigoureuse était mise en place pour tenter de garder la maîtrise des budgets et des délais.

La contrepartie en est que l'obtention d'un produit à la fois minimal et parfaitement adapté à l'utilisateur tenait du challenge.

Pour tenter de corriger les erreurs d'appréciation initiales, il existe un processus de gestion des exceptions. C'est ce que l'on appelle l'"escalade" auprès du manager.

Les managers ont le pouvoir de briser les règles pour arranger des écarts fonctionnels ou des reports de délai.
En réalité ce processus est un dysfonctionnement qui répond à un dysfonctionnement (mais qui a aussi bien d'autres logiques d'existence)

La philosophie Scrum est de proposer des cycles courts dans lesquels des fonctions finalisées sont livrées.
Le risque de ne pas produire une fonctionnalité prioritaire dans un délai compatible avec un besoin métier réel est sinon nul du moins très limité. Et dans le cas ou il est avéré, ce risque peut sans doute se gérer sans briser le cadre Scrum (par une solution dégradée temporaire).

Le recours à l'escalade doit être vue comme une facilité du projet traditionnel , dans lequel le manager a le pouvoir de déroger au processus.

En passant en organisation Agile le manager a délégué son pouvoir.

S'il veut favoriser la progression vers l'agilité alors il doit aussi se soumettre à la discipline que demande le cadre Scrum.

Comme disait un manager aux débuts de ma carrière : passées les bornes, il n'y a plus de limites.

Crédits : perso: Auguste - Musée du Vatican
http://lemondedekoulou.over-blog.com/40-categorie-705456.html
http://commons.wikimedia.org/wiki/File:Moteur_plan.PNG
http://commons.wikimedia.org/wiki/File:Tableau_SYMPHONIA.jpg

No comments

Le but de l'entreprise c'est le plaisir

Tuesday, September 14, 2010 9:31:23 AM

Philosophie, Agile, Entreprise

J'ai déjeuné avec Marc Vilcot (com-hom) au début de l'été et j'ai pris beaucoup de plaisir à notre échange d'idées. Nous avons des fondamentaux en communs c'est certain, mais son raisonnement est plus cartésien que le mien. Ou alors je suis plus utopiste.

Son article "Bien-être : une finalité pour l’entreprise ? " publié dans sa newsletter est intéressant. Il relève l'antinomie étymologique entre "bien être" et "travail" . Ce qui ne veut pas dire qu'il ne faille pas chercher à mettre ces concepts en cohérence. Simplement:

"Le but de l’entreprise est donc de « mettre en mouvement » l’individu en tenant compte de son potentiel. C’est pour cela que je préfère associer « piliers de la motivation » aux mots performance, efficacité, travail"

Il reste à agir sur les piliers de la motivation et Marc nous explique les moyens d'y parvenir.

Dans son article Marc ne cite le plaisir qu'une seule fois pour le rattacher à la notion de "bien-être". C'est normal, le terme plaisir est tabou du monde de l'entreprise depuis longtemps, justement parce que le plaisir c'est à la maison, pas au travail.

Pourtant je trouve que la notion de plaisir mérite un peu d'attention . Et c'est légitime. D'Epicure à John Stuart Mill, le plaisir est même l'objet de doctrines philosophiques qui traversent les âges.

Ce qui est plus intéressant encore, c'est que le système de Mill s'appelle "l'Utilitarisme" et il revendique la filiation et l'inscription dans la ligne de ses prédécesseurs:

d'Epicure à Bentham tous les auteurs qui ont défendu la doctrine de l'utilité on désigné par ce mot (…) le plaisir même, en même temps que l'absence de douleur, et bien loin d'opposer ce qui est utile à ce qui est agréable ou élégant ils ont toujours déclarés que le mot utile désigne également ces choses là.

L'utilitarisme soutien que la seule chose désirable comme fin est le bonheur. Le plaisir n'est pas un état alternatif, c'est le seul but de l'existence. Peut-il donc y avoir quelque chose d'utile qui ne concoure pas au bonheur des individus ?
Et bien…ça dépend. On peut bien sur relier ça à la motivation. Justement ! En jouant sur les plaisirs (être utile, savoir faire, progresser…) de chacun j'obtiens leur motivation et la boucle est bouclée.

Oui, on peut aussi se poser la question de savoir si le plaisir des uns est compatible avec celui des autres. Si l'entreprise structurée comme elle est permet encore cette réalisation. Et si le simple fait de parler de motivation n'est pas déjà un détour sémantique pour éviter de poser la question du plaisir.

Parce qu'il est bien évident que le but de l'entreprise est le plaisir. La question à creuser c'est.... le plaisir de qui ?

No comments

1 2 3 4 5 ... 9 Next »