Philo SI

Jean-François Jagodzinski - Le Blog

Subscribe to RSS feed

Posts tagged with "Agile"

Naissance du mouvement Agile et contingence

Friday, December 9, 2011 1:23:31 PM

, , ,

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

2 comments

L'agile n'est pas encore mort

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

, ,

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

No comments

High performance tree - métaphore de la performance

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

,


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

No comments

Attracteur étrange

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

,

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

No comments

Les modèles impressionnistes

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

, ,

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.

Read more...

No comments

Communication et modèle

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

, , , ...

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.

Read more...

No comments

Le manager est il au dessus du cadre Agile ?

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

, , ,

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

Read more...

No comments

Le but de l'entreprise c'est le plaisir

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

, ,

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

La fin du mode projet

Thursday, July 8, 2010 10:15:35 AM

, ,

Je remercie Jean de m'avoir par son article décidé à enfin écrire ce billet.

Si je me souviens bien c'était en 2003, sur un projet important de refonte et d'uniformisation des systèmes Gestion comptable et Gestion commerciale dans un grand groupe pétrolier.
Un groupe d'utilisateurs référents avait été constitué pour la circonstance. Ils venaient des 6 coins de l'hexagone pour représenter les besoins de leur filiale. Ils avaient été rassemblés à Paris "La Défense" pour des ateliers de rédaction de spécification qui devaient durer un an.


Les chefs de projets informatiques pestaient devant la difficulté à faire comprendre aux référents utilisateurs qu'ils devaient travailler en "mode projet" (en fait tout décomposer en niveaux d'abstractions et en fonctionnalités selon les attentes des informaticiens). Ces super utilisateurs étaient pour la plupart issus de directions opérationnelles et leur environnement était plutôt le "mode production" .

Avant ça, je n'avais jamais réalisé pour ma part que je travaillais en "mode projet".

S'il est difficile à quelqu'un de basculer son comportement vers le "mode projet", c'est sans doute que ce dernier ne doit pas être trés naturel. Si faire des projets est un penchant humain, la façon d'aborder ceux-ci est loin d'être conforme à la méthode conçue dans le monde de l' informatique traditionnelle. J'ai d'ailleurs tendance à penser qu'il y a autant de méthodes que d'individus.

Le "mode projet" dont il est question dans le système d'information (mais pas que) est un comportement imposé, codifié, qui démarre par une étude théorique et qui termine par un tampon d'acceptation. Le chemin est balisé, il y a des passages obligés... bref ce mode de comportement doit obligatoirement être appris (et il n'est jamais totalement maîtrisé).

On peut parler longtemps du "mode projet" , en préciser le plan, la durée, les intervenants, le plan qualité, les risques… sans jamais définir quel est l'objet du projet. Le projet est un objet manipulable en soi.

On peut d'ailleurs définir quelques caractéristiques de cet objet : Il a une limite dans le temps, il est borné par un début et une fin, c'est une sorte de trou noir, l'information n'en sort pas naturellement…
Cet objet se manipule à l'aide de méthodes (il y en a plein) qui donnent les outils pour gérer le temps du projet, extraire l'information sélectionnée pour la diffusion…etc.

Ces méthodes ont toutes le même ADN de base , on y trouve inscrit les facteur temps (début-fin), information (validée), tâche(spécialisée), responsable(coupable), qualité (projet)... etc

Lorsqu'on aborde l'Agilité, on parle encore de projet. Méthode, pratique, nouveau type d'organisation….de projet.

J'accepte et j'utilise ce vocable principalement pour des raisons pratiques.

Pourtant, la mutation informatique vers l'Agilité (si elle réussit) remisera le "mode projet" au musée comme elle a remisé le langage procédural ou la base de données hierarchique (mais l'impact en sera sans doute bien plus grand).

Le mode de production Agile possède un génôme très différent de l'ADN des méthodes de projet. On y trouve des traces de temps (cycle), information(émulsion), taches(auto-affectées), responsable (collectif), qualité (produit) … etc.

Cet animal n'est pas équipé pour répondre au mode projet. Il est équipé pour attaquer la production logicielle comme celle d'un produit manufacturé. Un processus continu, une chaine de production qui adresse simplement des produits différents des assemblages matériels, des produits spécifiques au monde des théories (le monde 3 de Popper).

Cet ADN Agile est constitué de molécules "lean" adaptées au cycle de production matériel, ainsi que de molécules nouvelles, adaptées à l'injection de créativité tout au long du processus de production. Cet ADN évoluera avec la sélection naturelle mais jamais dans le sens du "mode projet".

Pour autant le projet n'est pas mort, il n'a pas vocation à disparaître. Il devrait même se renforcer, mais au niveau qui est le sien, celui de l'entreprise, celui des métiers.
Le projet c'est celui de l'entreprise, aborder un nouveau marché, simplifier la gestion comptable, réduire les coûts des opérations d'audit….

Le besoin de logiciel dans ces projets reviendra à lancer un nouveau besoin dans la chaine de production. Le lancement est standard, simple, rapide. La chaîne livre tôt et régulièrement du produit fini.
Bien sur, la façon de faire des projets va évoluer puisqu'elle était fortement empreinte des règles imposées par le "mode projet" du système d'information.

Cela va permettre d'adresser les besoins des projets métiers de façon plus rapide, plus intensive, de mettre en concurrence des solutions et de sélectionner ensuite les plus pertinentes, de répartir les budgets sur davantage de projets et de les pousser plus ou moins loin plus ou moins vite … et d'avoir la puissance des utilisateurs (ceux qui connaissent le micro management des informations) dans la boucle.

Mais ceci n'est pas encore écrit. Ou bien ça l'est ? Seulement si la fin des dinosaures était inéluctables...

Read more...

2 comments

A propos de l'erreur

Monday, June 21, 2010 2:02:13 PM

, , ,

Lorsque je donne une vision des problèmes auxquels nous devons répondre dans le cadre de nos projets informatiques, j'utilise souvent la représentation de Popper:


A gauche nous avons l'horloge, symbole de la détermination et du prédictible,
à droite un nuage, dont nous pouvons discerner les contour mais dont les détails et l'évolution nous sont impossible à connaître.

Nos problèmes, selon leur nature, se répartissent sur un axe qui va de l'un à l'autre.

Dans ma présentation, j'ai remplacé le nuage par la photo d' un vol d'étourneaux
au sein duquel un faucon essaie de chasser. J'ai mis à coté de la photo quelques règles de positionnement qui vraisemblablement régissent le vol de chacun des oiseaux.

J'explique que bien qu'il pourrait exister des règles, la modélisation du comportement de l'ensemble n'est pas réellement possible et certainement pas la bonne approche pour arriver à cerner le problème.

L'un des participants à une formation vient de m'interpeller à ce sujet en me disant que l'on était (maintenant) capable de modéliser cet ensemble, qu'il existait de littérature à ce sujet... etc.

La croyance en la modélisation du vivant me parait risquée.

Dans son roman "Je suis un chat", Soseki fait dire à son héros (qui est un chat donc) qu'il est surprenant que les hommes voient dans l'infinie diversité des être une preuve de l'existence de Dieu. "C'est étonnant" dit le chat, parce que ce qui serait réellement surnaturel, ce serait d'être capable d'avoir deux êtres totalement identiques.

La réalité de la question concernant notre vol d'étourneau n'est pas de savoir si l'on peut de façon rationnelle trouver des lois de positionnement par individu et les généraliser. La question est de savoir qui dans le groupe fera une erreur. Et c'est cette erreur d'un individu (ou de plusieurs peut-être) qui rendra le modèle inadéquate.
Je suis prêt à parier que c'est l'optique du faucon: miser sur l'erreur et peut-être même chercher à la provoquer

Lorsqu'on parle de projet, on parle de solutions à des problèmes posés. Et la complexité n'est pas dans l'objet mais dans les nombreuses interventions humaines qui sont impliquées. C'est la force de l'agilité que d'avoir compris qu'il est plus efficace de miser sur l'observation pour identifier les erreurs au plus tôt et les corriger plutôt que de chercher à modéliser pour prédire.

Pris dans ce sens, il n'est d'ailleurs pas impossible que l'on arrive à des modèles qui fonctionnent, une fois que l'on aura adressé les erreurs correctement...

Read more...

No comments

1 2 3 Next »