Philo SI

Le ROI (Return On Invest) , en français "retour sur investissement" est une question sans cesse présente dans l'entreprise et pourtant rarement exprimée:
- Si j'investi X dans une action, quels sont les gains que je vais en retirer et en combien de temps ceux-ci dépasseront-ils ma mise de départ ?

On utilise un comportement analogue au niveau personnel, guidés par le rapport plaisir/énergie : je dépense une quantité d'énergie mais j'en espère en retour un gain en plaisir à plus ou moins long terme. Si le retour "long terme" est supérieur à ma durée de vie, la quantité d'énergie investie est inutile (et je détruis ma planète … mais c'est une autre histoire).

Le retour sur investissement en entreprise se traduit par des gains plus importants que les dépenses engagées, à un horizon intéressant dans le cycle de vie de l'entreprise. Cela nécessite une bonne idée de ce que sera l'avenir dans cet horizon du ROI. Et l'époque étant ce qu'elle est, les certitudes ne sont plus ce qu'elles étaient.

La question est alors récursive, le temps que l'on passe à discuter du ROI est il bien investi ?

L'Agilité nous donne une règle qui n'existe pas dans les autres modes de gestion de projet : éviter de prédire ce qui va se passer, se baser sur ce que l'on sait davantage que sur ce que l'on croit.

Je n'emploie pas souvent le terme de ROI mais la question du rapport dépense/gain est implicite en permanence dans les actions du projet Agile. Cette question n'est pas facile pour les équipes, elle fait appel à de la projection pour estimer ce qui pourrait se passer dans un cas ou dans un autre mais elle demande de vérifier ce qui nous semble être évident. Il faut souvent accepter de reconnaître que l'on ne sait pas (et cette réflexion ne doit pas prendre davantage qu'une poignée de secondes !).

La production Agile amène à une sorte de conscience permanent du ROI, mouvement naturel finalement, qui introduit dans le choix des actions la notion de meilleur "probable" comme critère de décision. Ce probable n'étant pas une certitude, l'étape d'après est hypothétique, et la meilleure décision est celle qui est parfaitement adaptée à l'action présente tout en laissant les options ouvertes pour l'avenir. Point final.

Le point problématique de la documentation en mode Agile est un bon exemple des difficultés que pose cette vision pragmatique des choses. Faut-il de la documentation dans un projet, si oui, laquelle ? C'est un point sensible, une question qui se pose à chaque fois qu'un nouveau client découvre l'agilité.

Pourquoi pose-ton cette question ? Parce qu'on n'a jamais réussi sans doute à poser correctement le ROI sur la documentation. Si on peut dire ce que ça coûte, on ne sait pas ce que cela rapporte. Il y a une sorte d'évidence à cette nécessité de rédiger avant de développer. Le besoin évident n'est pas celui auquel on pense, la documentation permet davantage de se rassurer que de bien communiquer.

Posons la question au métier et voyons sa réponse : je vous donne un premier livrable dans 2 mois.
Pour le même effort on peut vous fournir :
- des spécifications complètes et détaillées ainsi que le PAQ et le schéma de la base de données,
- ou bien une première version du logiciel pleinement opérationnelle qui vous permettra déjà de faire les devis automatiquement même s'il ne permettra pas encore d'enregistrer les commandes ?

- d'accord posé de cette façon bien évidemment … sauf que si on a pas la documentation vous ne pourrez pas développer.
- si, on sait le faire. On a l'expérience, on a juste besoin que vous soyez accessible pour répondre aux questions de l'équipe chaque jour. Ça peut paraître contraignant mais vous verrez vite que c'est très efficace et que ça va vous plaire.
- admettons, mais quand même, à un moment ou à un autre il faudra bien la documentation de toute façon.
- oui bien sur, pas de problème , vous nous direz simplement quand vous en avez absolument besoin et on suspendra le développement pour rédiger la documentation en priorité.
- ah oui mais alors je vais devoir payer pour la documentation plutôt que pour du développement !
- hé bien étudiez le ROI généré par la documentation et vous fixerez le budget documentation en conséquence. On s'adaptera...

... mais ne vous penchez pas sur le ROI de la documentation maintenant, le temps que vous allez investir à calculer votre ROI risque d'être perdu, attendez d'être certain de ce dont vous avez besoin.

Read more...

Je l'avoue, je suis un peu démuni face à toutes les théories qui cherchent à donner des modèles chiffrés à l'agilité et à Scrum en particulier.
Je regarde avec intérêt toutes les expériences. Je note avec intérêt le fait qu'un ratio ait pu être tiré d'un certain nombre de sprints sur ce projet ci ou que l'on ait constaté la véracité d'une théorie sur le coût de correction des bugs sur ce projet là.
Mais je suis mitigé sur les généralisations qui s'en suivent souvent implicitement.

C'est une tendance naturelle de l'humain de vouloir rationaliser et trouver des lois générales à partir d'expériences (ce que l'on appelle en philosophie l'induction). Je me demande s'il n'est pas imprudent de généraliser si rapidement à partir d'éléments factuels (les projets, les équipes, le degré de pratique) si différents, d'ailleurs sans les considérer tous ensembles.
Et tant qu'a chercher des modèles, je crois qu'il faudrait intégrer dans notre réflexion ceux de notre temps et ré-interroger les vérités dogmatiques pré-agile.

Il y a un terme utilisé en écologie qui est absent de l'entreprise et qu'il faudrait je pense intégrer dans notre réflexion : "écosystème"

La notion d'écosystème concerne une communauté d'êtres vivants ainsi que les conditions de son environnement. Il est caractérisé par ses interactions dans ses aspects biotiques et abiotiques (Source wikipedia).
La composante biotique se rapporte à l'intéraction du vivant sur le vivant (compétition, prédation, symbiose...), la composante abiotique se rapporte à l'action du non-vivant sur le vivant (sol, climat,...).

Les modèles écologiques ne se traduisent pas simplement. Enfin pas toujours. Je veux dire par là qu'ils peuvent être temporairement simples et prédictifs et puis basculer dans quelque chose d'imprévisible. Ce n'est pas que l'équation soit complexe, au contraire elle peut-être trés simple. Mais elle est fortement liée aux conditions initiales de l'expérience. Ce type de modèles est appelé chaotique.

Un bon exemple est donné par la fonction logistique de Robert May . Le diagramme de bifurcation ci-dessous montre les variations possibles dans la production du vivant en fonction de son environnement(aspects biotiques et abiotiques confondus). La population est exprimée en % de la capacité maximale du territoire considéré.
On peut lire en ordonnée (nommée "x") le % de population animale de l'année prochaine (calculée à partir d'une population actuelle de 25%) en tenant compte du facteur correctif ("r") qui matérialise les conditions particulières propre à l'environnement.

Lorsque le coefficient traduisant le facteur environnemental est inférieur à 3,5 les choses sont assez simples et prévisibles. Par la suite ça se gâte sérieusement et au dela de 3,57 toute infime modification, que ce soit du coefficient "r" ou bien de la population initiale, affiche un résultat qu'on ne pouvait prévoir.

Si l'on veut apporter un regard neuf sur notre travail, il peut-être intéressant d'aborder la réflexion sous cet aspect. D'un point de vue du projet informatique, la partie environnementale (non vivante) se rapporterait aux éléments tangibles (locaux de l'entreprise mais aussi équipement du projet - serveur d'intégration par exemple). La partie biotique serait composée des relations entre membres de l'équipe, hiérarchie, client ..etc

L'écosystème du projet est sensible à ces 2 composantes.

Un bon environnement de travail, un équipement de haut niveau, est facteur de facilité de travail mais aussi de motivation. Cette partie est assez simple à identifier en général, les actions d'amélioration sont souvent facilement quantifiables, cette partie est plutôt rationnelle.

Le fait qu'une équipe s'entende bien ou pas, qu'un "prédateur" se manifeste, qu'un "leader" soit en vacances, que la confiance soit là ou qu'elle n'y soit plus,... sont des éléments irrationnels. Il n'y a pas de loi simple qui puisse de l'une de ces causes quantifier un effet.
On saurait sans doute dire dans quel sens l'un de ces éléments fait avancer le curseur "r" mais on ne sait pas dire de combien (et quid s'il y a plus de 2 élèments?). Difficile d'identifier l'impact. Pire, on pourrait croire que l'impact est faible alors qu'il vient de pousser le curseur en zone rouge...vers les 3,56 disons.

Je ne sais pas qu'elle est la fonction qui permettra de modéliser la production agile. Mais il me semble clair qu'elle sera plus proche de celle de May que de la droite euclidienne ou de la courbe en cloche de notre ami Gauss.

C'est pourquoi le rôle du Scrum Master n'est pas de mettre en pratique des lois tirées sur les nombres mais d'observer et d'être attentif en permanence aux conditions de l'écosystème. Il remet toujours en question son jugement, il n'intervient pas en dogmatique mais dose ses interventions en fonction de l'état (biotique / abiotique) de l'environnement.

C'est une fonction davantage sensible que rationnelle.

Read more...

Vous la connaissez ?

Nathalie Kosciusko-Morizet est la Secrétaire d’Etat chargée de la Prospective et du Développement de l’économie numérique.
Je la suis sur Twitter depuis que Tristan Nitot (président de Mozilla) a parlé dans son blog d'un twit plutôt sympa que NKM avait fait à l'occasion d'une rencontre avec l'équipe Mozilla.
Et je suis sur Twitter depuis que Eric Lefevre-Ardant (à qui je dois d'être Scrum Master) a publié sur son blog un avis intéressant sur ce moyen de communication.

Pourquoi je vous dit tout ça ? Parcequ'il y a une heure NKM vient de twitter le message suivant

Vous m aimez? Prouvez le sur http://htxt.it/Sae2 (il y a environ 1 heure depuis HelloTxt)

Quand vous suivez le lien vous arrivez sur http://www.agora-politique.com/ ou il y a un sondage sur la popularité des membres du gouvernement.

Voici le résultat :


... on appelle ça le Buzz, efficace ?

Depuis le dernier billet il s'est passé pas mal de choses, j'ai beaucoup gambergé mais pas beaucoup écrit. Deux rencontres aux CARA on apporté comme d'habitude leur bouffée d'air agile d'altitude.

Je viens de terminer le "Cygne Noir" de N. N. Taleb. Je vous mets un lien vers le blog d'Alexandre Delivré qui résume le propos de Taleb de façon très agréable. C'est un livre qui évoque des choses plus profondes que le résumé de la plupart des chroniques ne le laisse percevoir.

A la rencontre du Cara de mars, Jérôme Barrand nous a présenté en avant première (bon ok, on était pas en "avant première", on a été les cobaye ) la poursuite de sa réflexion sur le management agile. J'ai un petit problème de cohérence par rapport à l'approche de Jérôme. Je suis totalement en phase avec ses fondamentaux mais je n'arrive pas à adhérer complètement à l'énoncé des axes du management agile... Bon, on verra. Je ne demande pas mieux que de constater que je me trompe en voyant que les manager viennent vraiment à l'agilité par ce biais.
Il y a un point cependant sur lequel je resterai en désaccord, c'est la mise à l'écart du système d'information au prétexte que c'est un point "technique".

Quoiqu'il en soit Jérôme a évoqué le désir (partagé avec d'autre agilistes) de "changer le monde".

Change le monde c'est une perspective sympa...

...mais je ne crois pas que le monde nous attende pour changer.

En fait je crois que le monde à déja changé, et c'est la que je rejoins N.N. Taleb, les Cygnes Noirs changent le monde, les gagnants raflent la mise et les autres subissent.
Un Cygne Noir, c'est un événement imprévisible (rien dans le passé ne nous permet de savoir qu'il a des chances de se produire), qui a un impact majeur, et que notre nature nous porte à analyser après coup comme une chose que l'on aurait pu prévoir.

Cela ne veut pas dire que l'apparition d'un Cygne Noir soit nécessairement soudaine. Un événement comme l'apparition de l'Internet est un Cygne Noir. Ce n'est pas le seul.

L'homme est essentiellement un système d'information mais la nature ne l'a pas doté de la capacité à gérer avec sagacité des flux d'information aussi important que ceux que le monde lui envoie aujourd'hui. Comme le dit Michel Serres (voir ce billet de l'année dernière) nous vivons une révolution de l'importance de l'apparition de l'imprimerie, et en confiant notre mémoire au système nous perdons notre tête.

Nos modèles vieillissants nous permettront ils de faire face à ces changements ? La science du chaos nous montre les limites de la pensée cartésienne, de notre capacité à appréhender le monde par décomposition en éléments simples et compréhensibles. Le scepticisme de Hume (notre vision du lien cause-effet n'est qu'une généralisation abusive de notre perception d'événements qui se suivent systématiquement) reprend finalement une nouvelle jeunesse à l'éclairage de cette même science.

Apprivoiser le doute plutôt que de pousser hors de leur limites des raisonnements destinés à satisfaire notre besoin de certitude.

Si la philosophie rationnelle ne positionne plus ses adeptes comme les mieux adaptés à l'environnement qui se prépare, les pragmatiques, les empiristes, les sceptiques..., seront ils mieux à même de s'en sortir puisqu'ils l'appréhendent d'une autre façon ?

Il ne s'agirait plus alors de "changer le monde" mais d'être dans le groupe de ceux qui seront adaptés à un monde qui a déjà changé. Et se reconnecter avec la connaissance sensible, c'est peut-être devenir plus "humain".

Read more...

Le terme d'agile est apparu pour nommer une attitude dans la gestion des projets informatique, peut-être au-delà, dans une façon d'être en tant que manager.

Le fait de donner un nom à ce qui n'en avait pas permet à la chose d'exister. Cette attitude "agile" faisait déjà parti du paysage depuis longtemps, c'est fondamentalement dans la nature de certains individus, qui, pour cette raison même, n'ont jamais beaucoup progressé en entreprise (sauf à mettre ces fondamentaux en sommeil).

Elle est faite de certaines caractéristiques (qualités et défauts) qui font qu'un individu s'épanouisse plutôt dans la collaboration, les relations d'égale à égale, la non compétitivité... et aussi sans doute d'autres choses. Peut-être qu'une forme de paresse qui concentre l'énergie sur ce qui est d'abord nécessaire est aussi utile, une réflexion sur la nature des choses et un peu de courage pour affronter ses principes sont sans doute les bienvenus.

Je travaille en ce moment à convaincre que des réponses agiles sur certains projets sont raisonnables. Les objections que je reçois sont normales, il est assez inconcevable de jeter à priori ses pratiques prédictives pour passer dans l'inconnu. Ça demande sans doute du courage de la part de ceux qui doivent "faire confiance".

Je regardais une émission sur Jean-Louis Trintignant ce matin.

Bel acteur, honnête homme en effet, je l'entendais parler simplement de choses simples qui me parlent bien.

Il parlait du théâtre que par opposition avec le cinéma il qualifiait, sans chercher à être péjoratif, de "conserve" ("cela peut-être de la bonne conserve, mais c'est quand même de la conserve"). Le théâtre au contraire est une représentation permanente.

Il parlait aussi de sa relation à la peur et de la nécessité de se mettre en danger.

J'aime bien me mettre en danger, j'aime bien oublier mon texte, ne pas savoir ce que je vais dire, et puis l'inventer au moment où je le dis...
Si on ne fait pas cet effort de tout oublier on ne peut pas être bien, on est un perroquet.

Certes, mais on maîtrise.

On maîtrise quoi ? Sa peur.

Read more...