Vous les rencontrerez là où ils sont.
Vous travaillerez là où ils travaillent.
Et quand vous partirez, ils SERONT encore là.

Le côté droit est le mauvais côté

En jetant un coup d’œil aux alentours lors de la conférence Agile2017, j’ai été troublé en regardant du côté de ce que Chet appelle « le salon de droite »1 appelé aussi la zone des exposants. La conférence et les commerciaux parle de plus en plus d’ « Agilité Métier », de plus en plus d’outils comme Jira, Rally et Version One, de plus en plus des grosses boîtes comme Deloitte et Accenture, de plus en plus d’« Agile à grande échelle » aux grandes entreprises. « Agile » est de moins en moins le développement Agile de logiciels, ce qui le sujet principal du Manifeste. Il s’agit de plus en plus de « gestion de projet agile » ce qui est, autant que je le sache, quelque chose qui n’existe même pas.

L'agilité métier n'a rien à voir avec le développement agile de logiciels

De manière similaire, lorsque j’effleure la surface d’Internet pour lire l’actualité sur Scrum er par conséquent sur l’« Agile »,2 je trouve qu’il y a de quoi s’inquiéter. Il est question à nouveau de « gestion de projet agile », et en plus c’est vraiment mal fait. Les organisations rebaptisent alors le poste des personnes en « Product Owner », qui vont passer au tamis leurs documents d’exigences existants pour les transformer en stories3, et qui vont commencer à demander à leurs équipes d’aller plus vite et encore plus vite. J’appelle cela le Dark Scrum, comme peuvent très bien s’en rappeler les lecteurs assidus de ce blog.

Cette attention à ce qui est mis en avant par le « côté droit » s’éloigne de l’essence des idées présentes dans le Manifeste Agile. Pire, cela aura comme conséquence - c’est ce que je dis généralement - de piètres résultats pour l’organisation ainsi que de la souffrance pour toutes les personnes qui font cette espèce d’« Agilité Métier ».

Ici, nous parlons de logiciels

Même s’il est exact que les approches Agile peuvent tout à fait être utilisées pour gérer les ventes de la boulangerie du coin, dans beaucoup de situations — dans la plupart des situations d’ailleurs, je crois — que les gens utilisent l’« Agile » pour gérer le développement logiciel. La situation actuelle est déséquilibrée : nous nous retrouvons avec beaucoup d’« Agile » et peu de « développement logiciel ».

Le développement Agile de logiciels c'est différent.

Le développement Agile de logiciels est différent de ce que les développeurs4 connaissent habituellement. Pour être efficace dans le développement Agile de logiciels, les développeurs et les équipes doivent apprendre et pratiquer certaines compétences de développement. Ces compétences ne sont généralement pas enseignées dans les écoles, et la plupart des développeurs n’y sont pas confrontés dans le développement ordinaire de logiciels. Même s’il existe des formations sur le développement Agile de logiciels, les formateurs qualifiés sont relativement peu nombreux.

Une formation c'est coûteux en temps et en argent.

Il faut une semaine entière pour suivre ne serait-ce qu’un cours correct pour débutant, et le coût d’une formation pratique de ce type coûte entre 2 000 et 3 000 € par étudiant. Cette première semaine ne fait qu’effleurer la surface des choses. Cela donne tout juste assez d’expérience et de connaissances en formation pour qu’un développeur ait un avant-goût des pratiques et avant-goût de quelle manière elles peuvent s’intégrer dans le style des livraisons rapides qui existent en développement agile de logiciel. Ces formations sont comme une invitation aux mois et aux années pour développer ses compétences. Il est impossible que vous appreniez le développement logiciel en une semaine, et il est impossible que vous appreniez le développement agile de logiciels en une semaine également. Les cours ouvrent des portes, ils ne font pas des miracles.

Le temps et l'argent sont difficiles à obtenir.

Vu le coût en temps et en argent, il est peu probable qu’une grande entreprise essayant « d’aller vers l’Agile » investira dans la formation de plusieurs centaines de développeurs. Même si cela vaut le coup si c’est fait, l’effet n’est pas immédiat et la dépense initiale peut s’avérer décourageante. Dans la plupart des entreprises, ce genre de choses n’aura pas lieu. Et pour être plus précis, cela n’a pas lieu.

Apprendre l'Agile prend un certain temps.

Une semaine de formation de « CSD » ou équivalent n’est pas suffisant. C’est une très bonne introduction et les développeurs en tirent une assez bonne connaissance de ce que sont les pratiques et de comment elles s’imbriquent les unes les autres. Mais de même qu’il faut des mois et des années pour être bon en développement logiciel, les pratiques Agiles doivent être mises en exécution pendant un certain temps pour se les approprier. La plupart d’entre nous bénéficierons d’une aide qu’elle soit sous la forme de formation complémentaire ou d’un coaching, au fur et à mesure de nous avançons.

Sans apprentissage technique, l'Agile fera souvent plus de mal à l'entreprise et au développeur.

Dans une certaine mesure, les approches « Agiles » aujourd’hui, avec la meilleure volonté du monde, sont en train de créer un environnement pour le développement logiciel qui ne sert pas de manière efficace l’entreprise, et qui s’avère souvent de manière littérale au travail et à la vie personnelle des développeurs travaillant avec ces approches. Les développeurs n’étant pas encore tout à fait compétents dans l’usage de ces pratiques, les progrès sont lents et les anomalies encore plus nombreuses. Les attentes du management ne sont pas atteintes. La pression augmente. La productivité continue de décliner. Il s’agit d’un cercle vicieux que j’appelle Dark Agile ou Dark Scrum.

Avoir de piètres pratiques techniques c'est comme construire sur du sable.

Le logiciel étant devenu un composant essentiel dans l’entreprise, en construire avec de piètres pratiques techniques c’est comme construire sur du sable. Les choses ne se passent pas bien. C’est dommageable pour les développeurs, pour l’entreprise, pour Scrum et l’Agile en tant que concepts, et pour les entreprises qui enseignent et soutiennent Scrum et l’Agile.

Le côté droit de l’Agile n’est bon pour personne.

Rappelez-vous donc de ça, il est nécessaire d'avoir des compétences spécialisées en la matière.

Revenons au sujet, les développeurs ont besoins d’acquérir des compétences pour travailler de manière incrémentale et itérative. Ils doivent être capables de commencer avec une conception très simple et de l’enrichir au fur et mesure que le développement avance. Ils doivent être capables de développer des fonctionnalités, pas seulement l’infrastructure, et ceci dès le début. Ils doivent être en capacité de livrer un logiciel opérationnel testé toutes les deux semaines. Ils doivent apprendre comment sélectionner la bonne quantité de travail à partir de la liste de courses du Client et comment l’accomplir de manière fiable. Ils doivent apprendre comment faire tout cela, toutes les deux semaines sans ralentir le rythme de livraison et peut être même l’augmenter.

Ce n’est pas facile. Ce n’est pas quelque chose avec lequel les développeurs sont nés. La manière actuelle d’essayer d’accomplir ce besoin est une formation que peu de gens sont en mesure de suivre, et il s’agit seulement que de l’introduction. Nous devons faire mieux que ça d’une manière ou d’une autre.

La direction prise par l'Agile actuellement n'aide personne.

J’ai déjà évoqué par le passé qu’un jour Kent Beck a raconté qu’il avait inventé XP pour rendre le monde plus sûr pour les programmeurs, et c’est cette idée-même qui motive pour beaucoup ce que je fais. La direction prise actuellement par Scrum et l’« Agile » peut améliorer légèrement la productivité, mais cette direction n’améliore pas la vie des gens dans les équipes de développement. Bien souvent, cela rend les choses pires.

L'auto-apprentissage librement choisi est essentiel.

À son crédit, la Scrum Alliance est en train de travailler pour mettre en place un apprentissage tout au long de la vie pour les personnes faisant du Scrum. Il y a des projets pour créer des documents d’introduction, de nouveaux cours, de nouveaux niveaux de certification5. Il y a un effort accru pour des formations à destination des responsables organisationnels et des dirigeants, ce qui pourrait conduire, à terme par ruissellement, à une vraie forme d’Agile. C’est bien, car la réussite des idées dépend de ce qu’apprennent les gens de plus en plus à propos de Scrum et sur la manière de l’appliquer.

La certification c'est lucratif.

Actuellement, un formateur donnant une formation certifiante ScrumMaster peut en faire autant qu’il le souhaite, sur la base de 1 000 € ou plus par stagiaire. Même les formation CSM les moins chères rapporte au formateur entre 3 000 € et 5 0000 € ce qui est plutôt une somme convenable pour 2 ou 3 jours de boulot. Du moins pour certains formateurs, les formations CSM ont été une vraie machine à sous. Je ne leur en veux pas, parce que les stagiaires de ces formations en ont bien plus que pour leur argent s’ils appliquent les idées données en formation. Ça vaut le coup.

L'économie doit évoluer.

Tout en essayant d’orienter les gens vers un apprentissage tout au long de la vie, il est peu probable qu’ils dépenseront quelques centaines d’euros tous les ans pour davantage de formations Scrum, même si cela pourrait en valoir le coup pour leur argent. La nécessité d’avoir une économie différente s’avère tout aussi vraie pour le management que pour la gestion de produits. Elle est d’autant plus vraie pour les personnes des équipes de développement. Peu d’entreprises sont prêtes à lâcher 2 000 € et une période d’une semaine de formations tous les ans pour dix mille développeurs. Pour pouvoir faire de l’apprentissage tout au long de la vie, les gens devront lire des livres, regarder des vidéos, prendre des cours en ligne, tout ça à un coût moindre que pour une formation traditionnelle en présentiel.

Malheureusement, vendre de l'Agile même de piètre qualité est quelque chose de très lucratif.

La formation et l’accompagnement de Scrum et Agile sont de gros business. Il y a eu une certaine tendance dans les entreprises Agile les plus importantes, et au fur et à mesure qu’elles deviennent plus grosses, la qualité de leur offre ne va pas toujours en s’améliorant. C’est simplement dû en partie au manque de personnes ayant réellement expérimenté les idées agiles jusqu’au bout. Si tout ce que vous avez vu est du « plutôt bon Agile », il est peu probable que vous allez prendre des personnes pour faire vraiment de l’Agile impressionnant. Et aujourd’hui, nous voyons des grosses entreprises de consultants « fusionner »6 avec ces entreprises consolidées. Cela peut faire se propager le gloubi-boulga Agile dans les entreprises de consultants, mais cela ne fera que rendre Agile de plus en ténu. Nous avons besoin d’un gloubi-boulga Agile plus fort, pas plus faible.

Vous les rencontrerez là où ils sont. Vous travaillerez là où ils sont. Et quand vous partirez, ils seront toujours là où ils sont.

Les grosses organisations « Agile » ont besoin d’énormes quantités d’argent. Elles ne peuvent s’appuyer uniquement sur des principes. Elles ne sont pas en mesure de demander les changements significatifs que le Real Agile™ demande. Par la nature-même de leur activité, elles vont engendrer des compromis entre ce qui doit être fait, et ce que leurs clients trouvent acceptables. Il ne faut pas se leurrer, même les entreprises de taille modérée parmi les entreprises Agile les plus importantes, font aussi des compromis. Même les individus font des compromis. Même moi je fais des compromis. Nous nous racontons à nous-mêmes que si nous nous faisons virer, le client n’en tirera aucun bénéfice, et si nous restons qu’il en tirera quelques bénéfices. Et nous avons raison. Et au fur et à mesure que nous le faisons, la qualité de l’« Agile » décline peu à peu.

Susciter chez l'autre, un désir ardent. – Dale Carnegie

Je crois que si « Agile » doit s’améliorer, cela doit être par l’action des personnes qui le font, non par les mains de ceux qui la vendent. Les commerciaux diront « ne confondez pas vendre avec installer » et concluront qu’ils peuvent dire n’importe quoi pour entrer dans la place, dire n’importe quoi pour y rester, et par conséquent qu’ils peuvent « faire un peu de bien ». Et peut-être feront-ils un peu de bien, je ne sais pas.

Par contre, ce qui est peu probable qu’ils arrivent à produire, c’est d’engendrer le vrai changement exigé par Real Agile™. Ce qui est peu probable de se produire, c’est d’envoyer des dizaines de milliers de développeurs sur le chemin de l’apprentissage de toutes les choses qu’ils ont besoin de savoir pour livrer vraiment les possibles bénéfices.

D’une manière ou d’une autre, nous devons susciter, chez les vrais pratiquants, un désir d’en savoir plus, de faire de l’ « Agile » de mieux en mieux, d’apprendre et de pratiquer et d’améliorer leurs compétences. Et en même temps, nous devons rendre les documentations existantes abordables, accessibles, et utilisables au rythme de chacun. Certains de ces critères sont déjà remplis. Je pense à des choses comme les vidéos et les ressources sur le web de personnes comme Joe Rainsberger, Jim Shore, Jeff Langr, et d’autres encore. Il y a toutefois de très bonnes choses du côté de chez Industrial Logic7.

Je ne devrais peut être pas le dire, il y a même un groupe Slack Agile Mentoring qui est très abordable, où vous pouvez discuter avec moi, Mike Vizdos et d’autres pratiquants de plus en plus nombreux.

À la place de dépenser des centaines d’euros pour une semaine avec Joe, Jim, Jeff ou même moi, vous dépensez « l’argent Pandora », « l’argent Spotify », « l’argent Apple Music Money», « l’argent Tidal », et vous accédez alors à une énorme quantité de documentation. Mais il va falloir beaucoup plus de documentation, et il doit y avoir un moyen pour trouver la documentation dont vous avez besoin, et qui soit idéalement, triée, passée au crible et organisée, afin que vous soyez quasiment certain de la manière dont elle s’inscrit dans les idées Agile, et à quel point elle peut être proche du cœur de ces idées.

De plus, cela va demander du temps d’offrir un support effectif de la part d’organisations comme la Scrum Alliance, de leurs formateurs et coachs. Ils vont devoir prendre conscience qu’ils ne peuvent pas pourvoir aux besoins des gens de manière rapprochée pour un coût de plusieurs milliers d’euros par jour, et que ce besoin doit être satisfait. Elles devront commencer à pousser - à vendre - des idées, du support et des produits qui ne leur apportent pas de revenus directs. Le bénéfice pour eux est dans le long terme. Si les idées Agile sont bien appliquées, elles auront tendance à fonctionner, les organisations connaîtront plus de réussite, et il y aura davantage de demandes pour de la formation en présentiel et l’accompagnement qui resteront ainsi relativement important.

Malheureusement, à moins que ces organisations et ces individus ne soutiennent ce modèle plus petit et plus incrémentale, les actions Scrum et Agile continueront à donner des résultats mitigés, continueront à engendrer du Dark Scrum™, et un marché très lucratif ne pourra pas se développer. Je pense qu’aujourd’hui c’est le chemin sur lequel nous sommes, et je pense que ce chemin doit changer.

Comment pouvons-nous faire en sorte que cela ait lieu ? Comment puis-je apporter mon aide ? Comment pouvez-vous apporter votre aide ?


Auteur : Ron Jeffries
Source : “Business Agile”: Built Upon Sand
Date de parution originale : 17 Août 2017


Traducteur : Nicolas Mereaux
Date de traduction : 19/03/2019


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. Chet donne ce nom à l’ensemble des produits qui se focalisent sur le « côté droit » du Manifeste Agile. Mais si, vous le savez, il s’agit des éléments que nous ne préférons pas par rapport aux éléments qui sont à gauche, comme les individus et leurs interactions plutôt que les processus et les outils. Oui, nous sommes bien d’accord que les processus et les outils ont de la valeur. Mais pas nécessairement de ces processus et de ces outils-là, enfin toutefois, la plupart de ceux rhabillant en plus moderne la manière de faire du siècle dernier. 

  2. Scrum, du moins son nom, représente la majeure partie des soi-disant projets « Agile » existants. SAFe peut en représenter un certain nombre, mais SAFe revendiquant Scrum comme faisant partie intégrante de lui, donc par conséquent « Agile » veut dire Scrum, du moins jusqu’à un certain point. 

  3. Les stories ne sont même pas une idée venant de Scrum : elles viennent d’Extreme Programming (XP). Et les stories ne sont pas non plus des espèces de paragraphes bizarres écrits sous la forme « En tant que … je veux … afin de ». Les vraies stories sont le regroupement de conversations, d’une carte qui sert de marqueur de rappel et de confirmation sous la forme de tests d’acceptation. 

  4. Dans cet article, j’utilise le terme de « développeurs » pour se référer à l’ensemble des membres d’une équipe de développement logiciel Agile pluridisciplinaire style Scrum. Cela comprend les gens ayant une orientation tests, une orientation base de données, une orientation UX/IHM, bref. J’ai toutefois principalement les programmeurs en tête, parce que c’est ce que je connais le plus. Néanmoins, lorsque j’évoque cela, j’inclus tout le monde dans l’équipe de dev, tous ceux qui ont besoins de nouvelles compétences pour renforcer leur rôle dans le développement Agile de logiciels. 

  5. Je n’aime pas les certifications. Cela ressemble à de la vente de cours, qui offre une certaine forme de pédagogie et j’aime bien la pédagogie. J’aimerais que nous arrivions à nous débarrasser des certifications, bien que je puisse apprécier quelques-uns, mais pas l’ensemble, des bénéfices qu’elles offrent. 

  6. Je me rappelle que la fusion Daimler-Chrysler avait été présentée par Daimeler comme une « fusion entre égaux ». C’était en fait une acquisition et cela a mis Chrysler sur le chemin de sa propre destruction. Elle est toujours sur ce chemin. L’étape suivante semble être une acquisition prochaine par une entreprise chinoise. Mais je digresse. Le point important est, que ce type de fusion ne devrait, selon toute vraisemblance, pas donner quelque chose de bon pour Real Agile™

  7. À ne pas confondre avec Industrial Light and Magic, qui ont eux aussi de bonnes choses de leur côté.