Le fondamentalisme sous agile nuit à la santé des entreprises

Le fondamentalisme sous agile nuit à la santé des entreprises
Selon le PDG d’un éditeur de logiciels adepte des méthodes agiles

Mars Cyrillo est le PDG de CI&T, entreprise spécialisée dans le développement logiciel pour le compte de quelques grands noms du top 100 des entreprises. Aujourd’hui, il revient sur le développement agile, lequel a été adopté par son entreprise au cours de l’année 2005, après avoir utilisé pendant de longues années une autre approche de développement : RUP (Rational Unified Process).

L’un des premiers constats que fait Cyrillo est : « Nous admettons qu’au début, nous avons pris trop à la lettre le manifeste agile. Nous sommes alors devenus une sorte de fondamentaliste qui veut suivre et implémenter d’une manière stricte la philosophie en l’imposant à ses clients ».

Puis il évoque d’autres constats qui sont venus s’agglutiner au premier, suite au développement de l’entreprise : « Nous avons réalisé que nous nous dupions en pensant que nous pouvions suivre à la lettre le manifeste. Nous étions plus fragiles qu’agiles. » Et « le défi était de savoir comment rendre l'information et les processus de décision effectifs dans un environnement où il est tout simplement impossible d'avoir toutes les parties prenantes dans des réunions quotidiennes. »

Ainsi, pour le CEO de CI&T et sur la base des valeurs agiles qui mettent en avant chacun deux points de vue opposés (un point de vue à gauche et un second à droite), un suivi à la lettre de ces valeurs conduit à une sorte de fondamentalisme où les équipes de développement se concentrent uniquement sur le premier point de vue, délaissant le second. Or, les signataires du manifeste mettent l’accent sur le premier sans oublier l’importance du second.

Cette situation mène par exemple certains fondamentalistes à ne pas documenter leur programme, même si cela est nécessaire dans certaines situations (valeur n° 2) ou encore à ne pas fixer clairement de deadlines, évoquant pour cela la valeur n° 3, où il est question de collaboration avec le client, plus que de négociation contractuelle.

Cyrillo va plus loin encore dans ce constat. Il cite certaines déclarations régulièrement faites par ces fondamentalistes, dont les propos n’ont pas réellement leur place :

• « Le développement logiciel est une forme d’art qui ne peut être mesurée. » ;
• « La mesure de la productivité relève du passé et de la production de masse. Les artefacts utilisés par les chefs de projets ne servent qu’à stresser les développeurs. » ;
• « La mesure de la productivité est un risque parce que les équipes trouveront toujours des solutions pour prouver artificiellement qu’elles sont productives. ».

A titre d’exemple, il explique ce qui suit : « Des métriques peuvent être utilisées pour mesurer les performances du processus utilisé, quant aux équipes de développement, elles doivent pouvoir calculer, mesurer et contrôler leur productivité. Une équipe qui n’en est pas capable ne peut pas comprendre ce qui l’affecte et par conséquent ne sera pas capable de s’améliorer en continue. »

Enfin, le CEO livre quelques détails sur les clés du succès sous agile, tout en garantissant la croissance de l’entreprise comme le suivi des principes lean qui offrent, selon lui, la meilleure approche philosophique, combinée à n’importe quelles méthodes agiles telles que SCRUM, Kanban.

Source : CI&T

Et vous ?

:fleche: Qu’en pensez-vous ?
:fleche: Pensez-vous être un fondamentaliste ou plutôt un adepte qui se donne une certaine flexibilité ? Pourquoi ?

Toute forme de fondamentalisme est a proscrire, bien evidemment.

Maintenant que cette lapalissade est rappelee, je trouve interessant de voir qu'on commence a trouver de plus en plus de "critiques" d'Agile, constructives ou non, en meme temps. Je pense que ca montre surtout qu'on est en train de passer de la phase "on est cool on fait de l'Agile/Scrum" a une phase de prise de recul, d'analyse, au cours de laquelle on se rend compte que oui, il y a des bonnes choses dedans, mais que non, tout n'est pas merveilleux, et il ne faut pas l'appliquer aveuglement.

C'est quand même paradoxal, cette mise en Abyme : le principe de base de l'agile, c'est de ne pas trop s'attacher aux principes, et on s'aperçoit que s'attacher trop à ce principe est nuisible..... :ptdr:

Pour ma part, je serais intéressé qu'il nous explique comment évaluer une équipe de dev.
Après plusieurs mois a réfléchir a la question, j'en suis arrivé a la conclusion que ce n'était pas faisable sur des critères mesurable et qu'il fallait faire confiance a l'humain, quitte a multiplier les évaluation pour limiter les effets de copinage.

Citation:

---

Envoyé par pmithrandir

Pour ma part, je serais intéressé qu'il nous explique comment évaluer une équipe de dev.
Après plusieurs mois a réfléchir a la question, j'en suis arrivé a la conclusion que ce n'était pas faisable sur des critères mesurable et qu'il fallait faire confiance a l'humain, quitte a multiplier les évaluation pour limiter les effets de copinage.

---

L'evaluation des developpeurs est effectivement quelque chose de complexe, mais je ne vois pas bien le rapport avec le fait que l'application a outrance d'une methode, quelle qu'elle soit, n'est pas benefique au developpement logiciel, et donc a la sante globale de l'entreprise -- ou tout du moins a sa profitabilité.

L'article repose sur le procédé assez connu de l'homme de paille : on établit une caricature d'agiliste "fondamentaliste" qu'on affuble de tous les maux, pour ne pas avoir à débattre de manière pragmatique sur une approche raisonnée. Les critiques restent assez vagues pour paraitre pleines de bon sens. Certaines seraient intéressantes si elles étaient argumentées, d'autres sont juste des vérités toutes faites. Ex : "Those are all myths that can be proven wrong." => OK, la démonstration SVP ?

La référence à l'article de Dave Thomas, un des signataires du manifeste agile, est utilisée à total contresens : D. Thomas ne critique pas les gens qui prennent trop le manifeste au pied de la lettre, mais ceux qui ne le prennent pas assez. Ceux qui ont marketé l'agilité au point de la vider de tout son sens.

En face de cela, l'auteur ne détaille aucune solution concrète, juste un mot : Lean, qui serait selon lui "la meilleure façon d'implémenter agile" et générateur "d'une qualité et d'une performance de rendement jamais vues avant".

On parie que dans 5 ans il nous ressort le même article sur Lean ? :mrgreen:

L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs dans le rythme infernal mis par l'obsolescence programmée. Obsolescence causée par la pression mise par le monde de la finance et du ROI suite à la "bulle internet".

Citation:

---

Envoyé par Luckyluke34

On parie que dans 5 ans il nous ressort le même article sur Lean ? :mrgreen:

---

Probablement.

D'autant que pour avoir vu des collègues "subir" le lean, je peux vous dire que des fondamentalistes, il y en a de ce coté là aussi...

Bilan, six mois après 4 mois de lean (donc avec des demies journées entières avec un gugusse qui ne connait rien à votre taf au dessus de votre épaule qui note le moindre de vos fait et geste, super agréable...), je crois que quasi aucune "bonne pratique" du lean n'a été conservé. Et à chaque fois que le mot "lean" est prononcé dans ce service, l'ambiance se tend instantanément.

Bref, les méthodologies toutes faites, c'est de la poudre aux yeux. Chaque societé, chaque service, chaque client à ses spécificités. On ne peut pas appliquer une recette toute faite. Si c'était le cas, ça se saurait.

Citation:

---

Envoyé par Carhiboux

Probablement.

D'autant que pour avoir vu des collègues "subir" le lean, je peux vous dire que des fondamentalistes, il y en a de ce coté là aussi...

Bilan, six mois après 4 mois de lean (donc avec des demies journées entières avec un gugusse qui ne connait rien à votre taf au dessus de votre épaule qui note le moindre de vos fait et geste, super agréable...), je crois que quasi aucune "bonne pratique" du lean n'a été conservé. Et à chaque fois que le mot "lean" est prononcé dans ce service, l'ambiance se tend instantanément.

Bref, les méthodologies toutes faites, c'est de la poudre aux yeux. Chaque societé, chaque service, chaque client à ses spécificités. On ne peut pas appliquer une recette toute faite. Si c'était le cas, ça se saurait.

---

Il faut aussi prendre en compte la façon dont a été appliqué le Lean.

Nous avons fait cette démarche dans notre société (mais je ne suis pas dans une SSII qui fournit du service), et nous avons augmenté notre productivité, amélioré un certain nombre de nos processus, etc etc

Mais pour cela, nous avons été somme encore suivi par une société spécialisé dans le domaine depuis plus d'un an, qui a étudié avec nous nos besoins, nos contraintes, et qui a pris le temps de comprendre nos processus dans les grandes lignes afin de pouvoir y appliquer les principes du Lean de la façon la plus adéquate, car comme tu le dis, chaque société à ses spécificités, peut-être n'êtes vous pas tombez sur les bons intervenants.


Et puis comme dans tous changements dans les habitudes, il y a aussi une bonne partie de réfractaires, qui peuvent aussi, freiner voir fausser la mise en application du principe du Lean, car cela demande une certaine remise en cause de soit-même et de notre façon de travailler.

Citation:

---

Envoyé par Arsene Newman

L’un des premiers constats que fait Cyrillo est : « Nous admettons qu’au début, nous avons pris trop à la lettre le manifeste agile. Nous sommes alors devenus une sorte de fondamentaliste qui veut suivre et implémenter d’une manière stricte la philosophie en l’imposant à ses clients ».

« Nous avons réalisé que nous nous dupions en pensant que nous pouvions suivre à la lettre le manifeste. Nous étions plus fragiles qu’agiles. » et « le défi était de savoir comment rendre l'information et les processus de décision effectifs dans un environnement où il est tout simplement impossible d'avoir toutes les parties prenantes dans des réunions quotidiennes. »

---

Croire au Père Noël et se rendre compte qu'il faut se retrousser les manches n'a pas grand chose à voir avec une méthode agile ( ou une autre méthode ).

Citation:

---

Envoyé par Arsene Newman

Ainsi, pour le CEO de CI&T et sur la base des valeurs agiles qui mettent en avant chacun deux points de vue opposés l’un à l’autre (un point de vu à gauche et un second à droite), un suivi à la lettre de ces valeurs conduites à une sorte de fondamentalisme où les équipes de développement se concentrent uniquement sur le premier point de vue, délaissant le second. Or, les signataires du manifeste mettent l’accent sur le premier sans oublier l’importance du second.

---

Pas compris :aie: .

Citation:

---

Envoyé par Arsene Newman

Cette situation mène par exemple certains fondamentalistes à ne pas documenter leur programme, même si cela est nécessaire dans certaines situations (valeur n°2) ou encore à ne pas fixer clairement de deadlines évoquant pour cela la valeur n°3 où il est question de collaboration avec le client, plus que la négociation contractuelle.

• « Le développement logiciel est une forme d’art qui ne peut être mesurée. »
• « La mesure de la productivité relève du passé et de la production de masse. Les artefacts utilisés par les chefs de projets ne servent qu’à stresser les développeurs. »
• « La mesure de la productivité est un risque parce que les équipes trouveront toujours des solutions pour prouver artificiellement qu’elles sont productives. »

« Des métriques peuvent être utilisées pour mesurer les performances du processus utilisé, quant aux équipes de développement, elles doivent pouvoir calculer, mesurer et contrôler leur productivité. Une équipe qui n’en est pas capable ne peut pas comprendre ce qui l’affecte et par conséquent ne sera pas capable de s’améliorer en continue. »

---

:help: c'est sérieux ? Pas de documentation du code, pas de limites de temps ( = incapacité à découper le travail donc ils n'ont pas compris les besoins... ), quand à l'incapacité à "calculer" son efficacité celle là est la meilleur !!!
Visiblement cette personne emploi le mot équipe sur un groupe qui n'en est pas une, qui ne connait pas les besoins du client et est incapable de faire du bon boulot ( ils n'ont font pas à mon avis ) et de s'en rendre compte :aie:
De plus à part le passé je ne vois pas trop quoi mesurer pour estimer l'avenir :traine: .
Bon on a compris ils ne font pas de l'agile.

Citation:

---

Envoyé par Arsene Newman

Enfin, le CEO livre quelques détails sur les clés du succès sous agile, tout en garantissant la croissance de l’entreprise comme le suivi des principes lean qui offrent, selon lui, la meilleure approche philosophique, combinée à n’importe quelles méthodes agiles telles que SCRUM, Kanban.

---

:mouarf: :merci: je serais moins idiot ce soir.

Je suis d'accord pour dire que le dogmatisme vis à vis d'une méthodologie est néfaste, surtout qu'autour d'agile il y a aussi un petit versant commercial bien rôdé. Si vous me croyez pas, constatez par vous mêmes que presque tous les sites qui parlent d'agile proposent des services de consulting ou de coaching d'équipe.
Bref dans cet article, ça manque vraiment d'exemples concrets, on y apprend que ce qui marche pour les start-ups de 5 personnes marche pas forcément pour les équipes de 500, merci c'est vrai qu'on s'en douterait pas :mouarf:.

Le seul point où on a droit à un peu plus de précision c'est sur l'implication de l'utilisateur dans le processus. Là il nous dit que ce n'est pas évident d'avoir quelqu'un à disposition en permanence et qu'il y avait souvent des complications à cause du manque d'alignement des différents interlocuteurs (enfin comme je le comprends même si c'est pas dit aussi clairement). C'est aussi un problème connu, qui n'a jamais rencontré plusieurs personnes lors d'une séance, et vu à quel point ça se met à partir live lorsque chacun jette sur la table sa propre idée de ce que le produit devrait être? C'est même pas imputable à une méthodologie, c'est plutôt je sais pas moi... un fait anthropologique?

Citation:

---

Envoyé par Zirak

Il faut aussi prendre en compte la façon dont a été appliqué le Lean.

Nous avons fait cette démarche dans notre société (mais je ne suis pas dans une SSII qui fournit du service), et nous avons augmenté notre productivité, amélioré un certain nombre de nos processus, etc etc

---

Peut être que vous aviez plus de "marge de progression" que le service donc je parle alors. C'est possible. Ou alors comme tu le dis, ils sont tombés sur des mauvais accompagnants. Très possible aussi.

Citation:

---

Envoyé par Zirak

Mais pour cela, nous avons été somme encore suivi [...] Et puis comme dans tous changements dans les habitudes, il y a aussi une bonne partie de réfractaires, qui peuvent aussi, freiner voir fausser la mise en application du principe du Lean, car cela demande une certaine remise en cause de soit-même et de notre façon de travailler.

---

Oui, il y a clairement cela aussi.

Quand le lean vient "d'en haut" et que cela n'a comme objectif que d'augmenter les marges de la SS2I, c'est vrai que c'est pas trop fédérateur comme projet! :mouarf:

Oui, après comme je le dis, ne faisant pas parti d'une SSII, la démarche n'était pas forcement la même également, mais le côté réfractaire car cela vient d'en-haut, c'est un des premiers trucs dont nous ont parlé les consultants qui nous suivaient, que le changement, cela faisait peur. :D


Je travaille dans une société qui fabrique quelque chose de concret, avec une chaine de montage plus ou moins automatisée, ce n'est pas que du "service", il y avait donc aussi plus de possibilité de voir réellement le gain.

Mais dans le principe du Lean, de développer son environement de travail de façon à tout avoir à portée de main sans bouger, de chercher les "gâchis" afin d'améliorer les processus, etc etc, Au final, ce n'est pas évident à faire car comme je le disais, chacun a ses petites habitudes, et n'a pas forcement envie de changer son train-train (ni se faire remarqué que c'est à son poste que le processus perds le plus de "gain" car pas optimisé etc etc...).

Sauf que, que cela soit pendant le processus (réflechir sur son poste, ses améliorations possibles, etc etc) ou après (travailler avec des processus plus optimisés, avoir de meilleurs communications au sein des différents services, etc etc), cela rend le travail plus agréable, surtout lors de ce moment où l'on se rend compte que : "tiens je viens de faire ça en 15mn, avant cela me prennait 1h30", on a moins l'impression de travailler dans le vide :)


Après d'un point de vue SSII, c'est vrai que le principe doit être un peu différent, nous le plus gros du changement s'étant plus déroulé au niveau production que bureaux, je ne vois pas trop comment cela s'adapte à une société de service.

Agile? Le truc adapté pour du développement amateur entre potes, mais qui se casse la gueule face à la nature productiviste de l'entreprise? A force de sprinter sous le chrono attentif du chef de la galère, on perd en endurance :aie: Ca me rappelle le cas de l'ouvrier qui suggère tellement d'optimisation de son processus de travail, qu'il ne ménage plus de temps de pause, et forcément :weird: La cadence de travail à court terme sabote celle à moyen et long terme. Pointeuse, ouvrier, développeur, promotion, rivalité pour le poste de grand chef...

@herdans : c'était ironique ?

Les méthodes agiles ont été conçues précisément pour l'entreprise, pas pour du dev entre potes, et préconisent au contraire d'autres approches plus "tayloristes" un rythme durable :

Citation:

---

Business people and developers must work
together daily throughout the project.

---

Citation:

---

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

---

http://agilemanifesto.org/principles.html

Maintenant, comme toute autre méthodo, elles peuvent être mal utilisées et totalement détournées de leur esprit initial...

Ironique? Non, réaliste.

Le but de la plupart des entreprises est de produire à moindre coût. Pas forcément de le faire bien. Les informaticiens ont pour vocation à produire du code correct, les autres parties impliquées veulent un résultat rapide, sinon la facture grimpe en raison du temps supplémentaire générateur de coût. Les clients vont pressurer les chefs de projet, qui vont eux même cravacher les informaticiens pour éviter les surcoûts (get shit done) inhérents à un travail plus long. Forcément en rabotant, la qualité en pâtit. Les informaticiens vont bâcler le truc pour respecter les ordres du très haut.

Agile requiert un niveau de confiance, et d'équilibre entre les différentes parties, qu'il est impossible à mon avis d'atteindre dans le privé. Le chef va faire l'interface entre le dév, et le client, avec en ligne de mire une date de livraison irréaliste . Mais les client/chef n'ont pas le temps de vérifier faute de disponibilité, donc bonjour les dégats, on arrive à l'éternel effet tunnel, avec détection du problème en bout de chaine, proche de la deadline ultime :aie:

Citation:

---

Envoyé par marsupial

L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs

---

C'est faux. Ceci n'est qu'une conséquence de l'application de la méthode.

L'origine vient de 2 constats simples, constats que tu observeras dans la nature:
1) On résout plus facilement un problème en le découpant
2) On résout plus rapidement un problème en faisant appel à l'intelligence collective

Le fondamentalisme ne nait que lorsqu'on oublie ce pourquoi on fait une chose.

Pour revenir à la problématique de métrique/benchmark d'une équipe, à ma connaissance, impossible de faire de l'agile sans utiliser la métrique de base, la vélocité. Et c'est un très bon indicateur pour mesurer l'évolution de la performance d'une équipe agile. Par contre, c'est une métrique qui ne peut en aucun cas être utilisé pour comparer les performances de 2 équipes différentes tant elle est subjective.
Et c'est de là que vient la frustration des manager. Comment s'assurer que j'ai payer le bon prix pour le service reçu??? Et donc des fortunes sont dépensées pour métriques que l'on peut aisément contourner. Par chez moi ce sont les points de fonctions qu'on utilise

Pour ma part, j'estime qu'être heureux cela n'a pas de prix. Et si je ne suis pas content, je vais voir ailleurs. Mon niveau de stress est proche du 0. :)

Loin d'être expert, je me pose une question.

Est-ce qu'on ne nuit pas à l'efficience collective en s'enfermant dans quelque chose d'imperméable, d'impénétrable ?

La méthode Agile n'est pas en cause, c'est plutôt l'utilisation et l'interprétation qu'ils en ont eu qui nuit le plus.

La méthode Agile et autres méthodes de management, gestion de projet sont des outils, des pistes de reflexion.
Certaines ne matchent pas avec certaines secteurs d'activités, certaines équipes ou certains managers.

Je pense que le principal dans tout cela est d'avoir la connaissance des méthodes de management et que suivant le projet, l'équipe, les individualités en place, le manager doit choisir certains points d'une méthode ou de plusieurs pour tirer le meilleur de son équipe.

Citation:

---

Envoyé par marsupial

L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs dans le rythme infernal mis par l'obsolescence programmée. Obsolescence causée par la pression mise par le monde de la finance et du ROI suite à la "bulle internet".

---

Citation:

---

Envoyé par notia

C'est faux. Ceci n'est qu'une conséquence de l'application de la méthode.

L'origine vient de 2 constats simples, constats que tu observeras dans la nature:
1) On résout plus facilement un problème en le découpant
2) On résout plus rapidement un problème en faisant appel à l'intelligence collective

---

Vous avez tous les 2 faux :aie:

L'origine vient tout simplement d'une longue et extensive pratique du cycle en V... sur de gros projets dans de grosses équipes.. ou à avoir eu à développer en parallèle à de grosses équipes en cycle en V.

J'ai déjà mis quelque part - mais je peux le remettre - des stats du milieu des années 90 où 91% des projets échouent, et sur les 9% qui marchent, ils n'ont que 47% des fonctionnalités demandées.. (voir ces stats ici)

C'est partant de ce constat, et en ayant l'habitude d'équipes où la production de documents internes, d'erreurs de traductions, et de réunions à plusieurs niveaux parce que le découpage était taylorien, entraînant des prises de décisions sur plusieurs mois, voire années, que les auteurs ont créé le Manifeste..

Et à peu près n’importe quelle personne sensée ayant travaillé sur ce genre de projet vous le dira..


Quant à l'article, son fond était prévisible dès le départ : je l'ai déjà dit X fois, l'agilité est un état d'esprit, et avec des bons, voire excellents, c'est encore mieux.. voire indispensable..

Donc, ce que je me suis tué à dire sur ces forums depuis maintenant 7 ans, c'est que les méthodologies agiles sont aussi nocives que n'importe quoi d'autre, si on en fait une religion.. Ce qu'on en a fait, par un élan marketing comparable à la mode du tout OO, du C++, ou du Cloud, ou n'importe quel buzz-word..

Mais bon, l'info aime le buzz, et les manuels pour savoir comment faire..... :roll: