En effet, l’un des buts principaux de l’agilité est de marier aussi étroitement que possible la technique, le fonctionnel et le commercial afin de parvenir à délivrer le plus rapidement possible un produit apportant un maximum de valeur ajoutée au client.
En clair, l’agilité permet de passer d’un jeu individuel à un jeu collectif.
Ainsi, tout le monde est alors responsable et doit donc en conséquence faire de son mieux pour parvenir à atteindre l’objectif.
Alors que dans un cadre plus traditionnel, le commercial, le fonctionnel (qui ne fait souvent qu’un avec le commercial), le chef de projet et les développeurs se passe successivement la responsabilité du projet.
Et fort logiquement, c’est forcément les développeurs qui portent finalement l’intégralité de la responsabilité, d’autant que les trois premiers font tout leur possible pour leur passer le plus rapidement possible afin de couvrir leurs fesses.
En effet, puisque statistiquement, 80 % des projets sont des échecs, ils ont tout intérêt à se débarrasser le plus rapidement possible de ceux qui leur sont confiés afin de ne pas porter le chapeau en cas de problème.
Le commercial a de plus une motivation supplémentaire pour se débarrasser de cette responsabilité du projet le plus rapidement possible, puisqu’il est commissionné sur le montant de la vente lors de la signature du contrat.
Il a donc tout intérêt à faire signer le client le plus rapidement possible, car il fait d’une pierre deux coups : il se débarrasse de la responsabilité et il engrange la monnaie !
Le chef de projet doit de son côté repasser le bébé le plus rapidement à ses développeurs afin de pouvoir collecter le plus rapidement possible les métriques qui lui permettront de démontrer par sin (A + B) * cos(π) que ses développeurs sont responsables des retards malgré tous ses efforts.
Dans un cadre agile, les choses sont très différentes.
Tout d’abord, le commercial et le fonctionnel sont contraints de faire un travail de fond beaucoup plus important, pour qualifier correctement les besoins du client fonctionnellement et en terme de valeur ajoutée.
Cela suppose donc de discuter avec le client et surtout de le forcer à prendre conscience précisément de son besoin, ce qui est loin d’être facile.
Il faut en effet faire usage de psychologie pour ne pas le froisser et prendre suffisamment son temps pour ne pas qu’il se décide à la hâte pour se débarrasser de ce problème épineux quitte à faire par la suite sans cesse la girouette.
Il devient de plus nécessaire d’emmener un technicien en avant-vente, afin de savoir précisément ce qu’il est possible de faire techniquement parlant, afin de ne pas vendre du rêve au client.
Tout cela prend donc du temps et il faut de plus trouver un client qui comprenne et accepte la démarche, ce qui n’est pas si courant par rapport à ceux qui griffonnent un « cahier des charges » sur un morceau de nappe entre la poire et le fromage durant le repas offert par le commercial pour boucler l’affaire.
Les délais sont donc allongés, ce qui veut dire que le commercial n’aura pas sa commission aussi vite qu’en dehors du cadre agile.
Pire, certains qui n’avaient rien à faire dans un cadre traditionnel se retrouvent alors à devoir travailler et même à devoir assumer leur choix, puisque les développeurs ne peuvent plus être les coupables désignés par défaut du moindre aléas sur le projet.
De plus, dans un tel cadre, la notion hiérarchique devient rapidement très floue, et il arrive très souvent que les « mâles alpha » le vivent très mal.
Un chef de projet peut ainsi se sentir dépossédé de ses prérogatives, tandis qu’un patron qui n’a alors plus la possibilité d’imposer son rythme ou sa vision des choses peut avoir l’impression de perdre le contrôle.
Si l’on ajoute à tout cela le fait que le dialogue entre le client et l’équipe chargée du projet doit perdurer tout au long de sa réalisation, l’agilité peut être perçue comme une contrainte et non comme un avantage aux yeux de ceux qui n’en tirent finalement aucun avantage personnel malgré une responsabilité plus importante, une charge de travail augmenté et des avantages monétaires plus espacés dans le temps.
Car fondamentalement, au contraire des développeurs bien souvent habitués à travailler collectivement car la nature même de leur métier les y incitent, les commerciaux, les fonctionnels et même les chefs de projet sont fondamentalement des travailleurs individuels qui n’ont pas du tout l’habitude de s’inscrire dans une dynamique collective.
L’utilisation de l’agilité suppose donc une grosse remise en question de leur façon de travailler, et entre la résistance naturelle de l’Humain au changement et les problèmes d’ego ou de caractères, elle devient bien souvent finalement plus un problème qu’une solution.
Les personnes dans ce cas cherchent alors à contourner la philosophie agile plus ou moins ouvertement, afin de retrouver leur confort antérieur.
En clair, elles recommencent à jouer individuellement plutôt que collectivement, mais comme tout pratiquant de sport collectif le sait bien, il suffit d’un individualiste dans une équipe pour l’empêcher de marquer.
L’échec du projet à plus ou moins court terme est alors inéluctable.
De là à dire que l’agilité ne fonctionne pas et qu’elle est donc vouée à disparaître, il n’y a qu’un pas, et ce pas est d’autant plus facile à franchir qu’une fois que cette idée aura fait son chemin, il sera alors possible de revenir aux méthodes traditionnelles, tout aussi inefficaces, mais tellement plus confortables à tout point de vue pour les individualistes.
Ce n’est donc pas le fait que l’agilité soit une mauvaise méthode qui causera la perte de l'esprit agile.
Si ce dernier doit disparaître, c'est parce que les intérêts individuels seront parvenus à garder le dessus sur l’intérêt collectif.
18 réactions
1 De bdelespierre - 20/03/2014, 14:36
Je pense que tu as mis le doigt sur le noeud du problème: mis à part l'entreprise et le projet lui-même, les méthodes agiles avantagent surtout les développeurs et "pénalisent" les autres. C'est sans doute pour ça que je n'ai jamais de ma carrière vu une méthode agile comme SCRUM ou KanBan être appliquée à la lettre ni être une franche réussite d'ailleurs. Jusqu'ici, j'ai surtout l'impression que chacun fait un peu sa tambouille maison, quitte à déroger aux règles fondamentales tout en brandissant avec conviction la banière agile.
Cela étant dit, je suis convaincu qu'une autre facette du problème est qu'une même personne (responsable produit, projet ou technique) est souvent contrainte de courrir plusieurs lièvres à la fois. Dans le contexte agile, j'ai surtout l'impression que ça génère du bruit d'information sans parler des luttes acharnées entre différents responsables qui tentent de s'accaparer de la "bande passante technique". Ce genre de situation est bien souvent liée à un problème d'effectifs et de priorisation (ce qui semble être le nerf de la guerre au vue des nombreuses réunions qui sont uniquement dédiées au rangement du backlog) mais aussi, à mon sens, à la méthode agile qui ne permet plus au responsables de replanifier les tâches au beau milieu du sprint.
Bref, pour avoir fait les deux, en situation de sous effectif sur un projet comportant beaucoup de code legacy, je préfère encore travailler en waterfall qu'en agile.
2 De NiKo` - 20/03/2014, 20:44
Bonjour, voulez-vous m'épouser ?
3 De Cyrano - 21/03/2014, 06:33
Une illustration de circonstance : http://www.commitstrip.com/fr/2014/...
Bon ok, je suis déjà dehors :D
4 De mageekguy - 21/03/2014, 09:51
@NiKo` : Si je n'étais pas déjà marié et que tu étais une femme, j'envisagerais très sérieusement d'accepter ta proposition
5 De yquenechdu - 21/03/2014, 15:23
"Depuis quelque temps, l’agilité prend du plomb dans l’aile"
Depuis quand l'Agilité est associée aux seuls développeurs ou à l'IT ? Vous confondez allègrement pratiques ou méthodes Agile avec l'esprit Agile.
Depuis quand un article d'une personne sans un seul élément factuel permet de tirer de telle conclusion ?
Je vous recommande fortement de revoir l'histoire de l'Agilité, elle a été inventé 20 ans (http://books.google.fr/books/about/...) avant le manifeste et les sociétés dites Agile fonctionnent très bien et au contraire, leur patron et employé n'en disent que du bien : Goretex, Virgin, Asea Braun Boveri, Favi, groupe Hervé, etc.
@ bdelespierre depuis quand il est écrit que les pratiques Agile doivent être respectées à la lettre ? L’agilité ne saurait être un état stable et définitif, mais une propension, une aptitude, un cadre général à maintenir et alimenter constamment
6 De mageekguy - 21/03/2014, 15:39
@yquenechdu : j'ai la prétention de ne parler que de ce que je connais.
Et dans mon univers (les développeurs et l'IT, comme tu le décris), il y a des signes qu'il n'est pas possible d'ignorer montrant que l'agilité est de plus en plus mal perçue par certains.
C'est un fait (sans parler de ce que je vis quotidiennement et de ce qu'il m'est rapporté), et il ne me plaît pas, pas plus qu'à toi visiblement, mais il est indéniable et l'ignorer serait à mon avis la pire des idioties.
Quand au reste de ton commentaire, je n'ignore rien de l'origine de l'agilité, et je sais très bien qu'elle est très appréciée au sein de certaines entreprises, et je peux même te dire qu'il existe des entreprises au sein de mon univers (tu sais, l'IT et les développeurs, tout ça tout ça) qui parvienne très bien à la mettre en œuvre pour leur plus grand bonheur.
Sauf que malheureusement, ces dernières sont l'exception plus que la règle et il existe malheureusement bien plus d'entreprise informatique se disant agile car c'est à la mode et permet de vendre que d'entreprise réellement agile et qui parviennent donc à en retirer un bénéfice.
Et comme dit précédemment, c'est un fait, et il ne me plaît pas, mais il est indéniable et l'ignorer serait à mon avis la pire des idioties.
7 De bdelespierre - 21/03/2014, 15:59
@yquenechdu si l'agilité est effectivement un état d'esprit, les méthodologies agiles elles tolèrent moins, d'après l'expérience que j'ai pu en faire, qu'on prenne des libertés avec. Je te souhaite de ne jamais devoir travailler dans un cadre où le scrum master est également product owner ni dans une boîte qui change de méthodo tous les mois. Le problème est que ces entreprises se disent Agile mais ne le sont pas dans les faits. Qu'importe, c'est l'image d'Agile qui en prend un coup.
8 De plop - 21/03/2014, 18:41
Bof, je pense surtout que l'immense majorité de gens qui s'intéressaient à l'agilité parce que c'était la mode sont partis suivre la tendance suivante, et vont cesser de faire semblant d'adhérer aux valeurs de l'agilité pour faire briller leur CV.
9 De mageekguy - 21/03/2014, 20:45
@bdelespierre : Scrum ou tout autre "méthode" agile encourage au contraire les modifications, et elles sont en vérité plus un cadre très souple qu'il faut adapter à son contexte et à ses besoins en fonction du feedback de l'équipe et des clients afin d'obtenir une amélioration continue que des méthodes à appliquer scrupuleusement sans sortir du droit chemin.
Je pense d'ailleurs qu'une partie des échecs imputés aux méthodes agiles viennent du fait que les entreprises concernées n'ont pas su faire cette adaptation et ont appliqué les préconisations (c'est encore mieux que cadre souple) agiles au pied de la lettre.
Et dans ce contexte, au lieu de mettre de l'huile dans les rouages et améliorer l'efficacité, l'agilité peut devenir au contraire un véritable frein, et du coup, l'agilité devient aux yeux de ceux qui l'expérimente de la merde en barre en longueur de 10 mètres.
Il y a au final assez peu de gens qui comprennent que les préconisations agiles n'ont qu'un seul et unique but : permettre à l'équipe de prendre le contrôle en s'auto-organisant en fonction des problématiques qu'elle rencontre au cours de sa vie, et encore parmi ceux qui le comprennent, peu parviennent à les mettre en œuvre correctement justement à cause de ce transfert de contrôle à l'équipe.
Pour eux, c'est comme si le général de l'armée transférait son autorité à ses trouffions, et peu leur importe que ces trouffions soient pourtant les plus à même à mener le combat parce qu'ils ont été formé pour gagner et que de plus ils sont en première ligne et savent donc en conséquence quoi faire pour parvenir à la victoire bien plus efficacement que n'importe quel gradé tranquillement planqué dans son blindé à 50 km du champ de bataille et qui ne voit les combats qu'à travers le périscope de son véhicule.
La mise en œuvre de l'agilité suppose une remise en question du fonctionnement de l'entreprise, notamment au niveau de ceux qui ont le pouvoir, donc les moins enclins à le lâcher, alors que ceux qui n'en ont pas en récupère.
Tant que les mentalités n'évolueront pas suffisamment pour que cela soit accepté, parvenir à faire de l'agilité de manière constructive est un très gros challenge et un travail de longue haleine.
Et je suis extrêmement bien placé pour le savoir.
10 De mackwic - 22/03/2014, 01:40
Je ne peux pas m'empêcher d'être surpris par le coté binaire de cette lecture de la situation. Est-elle vraiment si noire et blanche ?
Les devs n'ont-ils vraiment *aucune* part de responsabilité dans cet "échec" ?
Je ne me suis confronté qu'une seule fois au Scrum. Au début c'était génial, puis assez vite c'est devenu intenable. Pourquoi ? Je n'ai pas toutes les réponses, j'étais trop partie prenante, mais voici quelques questions dont la réponse aurait surement pu changer la donne:
- combien de temps les devs doivent-ils passer avec le PO pour discuter du bien fondé de l'user story ? De son scope réel ? Je crois pas que cette étape soit mentionné dans la plupart des formations Scrum (corrigez moi si je me trompe).
- à quel moment rend-on visite à notre cher ami l'Architecte pour qu'il nous donne de ses bons conseils sur un grand design général et cohérent ? Non je n'en suis pas capable, quand je suis en Scrum je me surprends à laisser la base de code grandir de façon organique et je ne trouve pas le temps de placer un refacto correct. Comment faites-vous ?
- J'ai l'impression que le Scrum Master doit être une réincarnation de Jésus. Amour de son équipe, Pardon pour le retard sur le sprint, Saint Esprit pour la compréhension IT-Business nécessaire, et j'en passe. Le fait que les interactions soient plus nombreuses et plus courtes laisse place à plus de frictions humaines (le daily Scrum peut être particulièrement culpabilisant !). Est-ce vraiment gérable à long terme par une seule personne ?
- La qualité était assurée par quelques outils automatiques (linter, CI, mesure dette techno, et de nombreux tests). C'est confortable, mais ça ne couvre pas vraiment ce qu'on appelle Qualité Logicielle (http://fr.wikipedia.org/wiki/Qualit...). Comment nous développeurs, pouvons nous intégrer un process de mesure de la qualité dans l'agilité ? On ne peut pas juste dire que c'est le client qui va combler les trous, et blâmer la méthodologie.
De toutes ces questions, je note deux choses:
1) l'agile n'est pas quelque chose de simple. C'est au contraire une pratique qui demande de la confiance, de la sérénité et une grande rigueur dans sa pratique. Des conditions qui feraient réussir n'importe quelle méthodologie intelligente (dont le cycle en V).
2) Ce serait malhonnête de ma part de dire que seuls les non-devs de ma boite sont responsables des multiples retards dont on a été victimes. On a clairement accumulé une dette technique astronomique, avec des migration de donnés qu'on arrivait plus à suivre, et cela uniquement parce qu'on a multiplié les itérations selon les bons vieux principes du Scrum.
Ceci dit, je reste persuadé que c'est la direction à creuser, et la voie de la "bonne" conception logicielle. Je suis juste dubitatif sur cette descente en flèche de l'Agile Corporate, comme si l'Agile Technocrate que nous pratiquons était dénué de défauts.
Pour mon prochain projet, je tenterait bien quelque chose plus radicalement Lean...
11 De lucascorbeaux - 22/03/2014, 11:26
Bonjour,
Article très intéressant, merci pour le partage. Par contre je dois admettre que si je rejoins le fond à 100%, j'ai du mal à voir le rapport avec l'agilité et (dans une moindre mesure) l'opposition agile / waterfall.
Je ne pense pas qu'il y ait de bonne ou mauvaise méthode, si j'ai besoin de prévisibilité, d'industrialisation et de rationaliser le déroulement d'un projet, j'opterais pour une approche waterfall. Si a contrario je veux favoriser l'innovation bottom-up et de maximiser la valeur du produit, j'opterais pour une approche agile quel que soit son nom ou les adaptations nécessaires à la faire fonctionner dans ma structure.
Dans les deux cas, il sera capital que mes équipes partagent une vision commune du produit, et soient drivées par le projet plutôt que par leurs intérêts personnels et leur petit "confort" (j'utilise les guillemets car à mon sens ce genre d'ambiance n'est confortable pour personne).
Ce qui est décrit ici est pour moi davantage une faute grave imputable au top management, soit pour l'avoir laisser s'installer, ou pire l'avoir incité. Pour faire simple et direct, amener cet état d'esprit dans ses équipes projets (ou le laisser s'installer) est clairement une marque d'incompétence caractérisée, ou d'un profond laxisme.
Pour le coup, je ne pense vraiment pas qu'on puisse parler de disparition de l'esprit agile si on ne considère que les endroits où il n'a jamais vraiment existé. On pourrait peut-être parler de la disparition des wannabe agile plutôt, mais est-ce une mauvaise chose ?
12 De mageekguy - 22/03/2014, 14:15
@mackwic : Bien sur qu'il y a parfois du gris, et parfois il est même gris clair ou gris foncé.
L'objectif du billet tient dans sa conclusion : démontrer que l'agilité ne peut mourir que parce qu'elle impose une telle refonte des mentalités qu'il est impossible pour certain d'embrasser ses principes.
Et bien sur que les développeurs ont une responsabilité dans les échecs, puisqu'ils font parti de l'équipe, mais encore une fois, ce n'est pas le propos, qui est de dire que dans l'entreprise, il existe une culture de la déresponsabilisation en amont du développement qui fait que les développeurs sont souvent perçus comme les seuls et uniques responsables.
Cela ne veut aucunement dire qu'ils sont pour autant blanc comme neige, juste qu'il ne devrait pas être seul à porter le fardeau.
Quand aux discussions sur le bien-fondé d'une user story entre le PO et les développeurs, elles n'ont pas lieu d'être si ce n'est pour demander des précisions permettant de mieux comprendre l'objectif à atteindre.
Ce travail de qualification d'une user story est le domaine du PO et il a du normalement avant de la transmettre aux développeurs la définir fonctionnellement et en terme de valeur ajoutée afin de la placer au bon endroit dans le backlog.
En clair, ce qui est en amont du backlog ne regarde pas le développement.
Quand à l'architecture, elle se défini collectivement, au cours des réunions de sprints, charge ensuite aux tests unitaires et fonctionnelles exécutés via l'intégration continue, puis aux démonstrations du produit de la valider ou non en fonction du feedback remonté.
Le refactoring prend lui sa place durant la phase d'écriture du code, via le TDD, et la mesure de la qualité peut se faire par le pair programming, la revue de code, ou tout simplement par le fait que le client est satisfait du produit livré (évidemment, faire de la qualité au sens ISO du terme dans un contexte agile est par contre bien plus délicat et c'est quasi un projet dans le projet).
Quand au rôle de Scrum Master, il est parfaitement gérable à long terme, d'autant que lorsque l'équipe a bien intégré les principes agiles, son rôle devient de plus en plus mineure.
Après suffisamment d'expérience, des équipes agiles sont même parfaitement à même de fonctionner sans Scrum Master.
Et donc oui, l'agilité n'est effectivement pas simple à mettre en œuvre, et ceux qui le pensent s'en morde bien souvent les doigts.
Quand au cycle en V, même avec toute l'intelligence du monde, il restera toujours moins apte à gérer les changements dans le développement d'un produit qu'une méthodologie agile conçu dans l'optique de justement absorber plus facilement ces changements.
Et lean et Scrum, même combat : mal appliqué, ils sont tous deux des armes de destruction massives de projet.
13 De blogdevphp - 22/03/2014, 19:14
Au cours de ma carrière, j'ai vu la méthode Agile appliquée lors d'une mission. On travaillait sur un sprint de deux semaines où les tâches étaient distribués par le scrum master. Pendant ce sprint, on ne s'éloignait pas d'un iota des tâches qu'on nous avait confiés. On faisait aussi le poker pour fixer le niveau de difficulté des tâches.
C'était la première fois pour moi et les choses se passaient bien. On avait même un product owner qui vérifiait nos développements afin de voir s'ils correspondaient aux demandes émises. J'ai été étonné de cette bonne organisation car j'étais habitué aux méthodes agiles adaptés à la sauce de chacun.
Cela peut marcher s'il y a ecoute entre chacun des acteurs, si le champ d'action des protagonistes est bien défini et enfin si après chaque sprint, on parle des choses à améliorer.
14 De Anonymous blog - 23/03/2014, 11:36
Quelle est la cause de la disparition de l'espr...
(…)
15 De Aurélien - 25/03/2014, 15:15
Merci beaucoup pour cet article. J'apprécie particulièrement ta conclusion
"Si ce dernier doit disparaître, c'est parce que les intérêts individuels seront parvenus à garder le dessus sur l’intérêt collectif."
Au final, peu importe la méthode d'organisation. Quand on travaille avec des gens qui ne savent/veulent pas travailler en équipe, cela ne marche pas
16 De Anonymous blog - 29/04/2014, 10:11
Quelle est la cause de la disparition de l'espr...
(…)
17 De Kyoku57 - 30/04/2014, 16:46
Je vais apporter un commentaire complètement inutile:-)
On voit dans le lien que l'auteur avait fait une faute de genre pour le mot "Quel" et qu'il s'est rattrapé en corrigeant son titre après coup.
CONCLUSION : L'auteur de ce blog est donc bien un humain.
Je vous remercie pour votre attention.
18 De MouseTIC - 05/05/2014, 13:45
Voila un article qui résume à lui seule, toute la difficulté de mettre en place des principes Agiles, quand ca vient des techos pas de soucis mais quand ils faut changer les habitudes des commerciaux, chef de projet voir les DA, qui ne sont pas habituées à travailler en équipe, cela devient juste impossible.
J'ai eu la malchance de travailler de travailler dans un "équipe" où le savoir c'était le pouvoir, donc faire accepter ce changement, c'était juste impossible.