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

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux


 Discussion forum

Sur le même sujet
Le , par Arsene Newman, Chroniqueur Actualités
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 ?

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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de gangsoleil gangsoleil
http://www.developpez.com
Modérateur
le 07/04/2014 10:46
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.
Avatar de el_slapper el_slapper
http://www.developpez.com
Expert Confirmé Sénior
le 07/04/2014 12:49
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.....
Avatar de pmithrandir pmithrandir
http://www.developpez.com
Expert Confirmé
le 07/04/2014 13:00
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.
Avatar de gangsoleil gangsoleil
http://www.developpez.com
Modérateur
le 07/04/2014 13:32
Citation Envoyé par pmithrandir  Voir le message
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é.
Avatar de Luckyluke34 Luckyluke34
http://www.developpez.com
Membre chevronné
le 08/04/2014 10:02
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 ?
Avatar de marsupial marsupial
http://www.developpez.com
Membre confirmé
le 08/04/2014 11:14
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".
Avatar de Carhiboux Carhiboux
http://www.developpez.com
Expert Confirmé Sénior
le 08/04/2014 11:21
Citation Envoyé par Luckyluke34  Voir le message
On parie que dans 5 ans il nous ressort le même article sur Lean ?

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.
Avatar de Zirak Zirak
http://www.developpez.com
Membre Expert
le 08/04/2014 11:51
Citation Envoyé par Carhiboux  Voir le message
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.
Avatar de valkirys valkirys
http://www.developpez.com
Membre Expert
le 08/04/2014 12:14
Citation Envoyé par Arsene Newman  Voir le message
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 .

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

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
De plus à part le passé je ne vois pas trop quoi mesurer pour estimer l'avenir .
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.

je serais moins idiot ce soir.
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 08/04/2014 13:20
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 .

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?
Offres d'emploi IT
Spécialiste réseau windows server 2012
Mission
STYLSTAIR - Alsace - Erstein (67150)
Parue le 04/09/2014
Ingénieur système windows h/f
CDI
Sogeti - IDF - EUPS - Ile de France - Issy les Moulineaux (92136)
Parue le 11/09/2014
Administrateur réseau h/f
Intérim
Kobaltt - Pays de la Loire - Laval (53000)
Parue le 19/09/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula