Catégorie : Job

Fin de l’Agilité ? Une histoire de marché !

Eric Lannemajou4 commentaires
Jean Pillement. 1728-1808. Lyon. Marine,tempête et naufrage. Seascape, storm and sinking. 1789 Quimper. Musée des Beaux Arts.
Jean Pillement. 1728-1808. Lyon. Marine, tempête et naufrage. 1789 Quimper. Musée des Beaux Arts.

Je remarque personnellement que le nombre d’articles sur la mort de « l’Agilité » augmente dans mon fil d’information LinkedIn1 2 3. Je ne reviendrai pas dans cet article sur ce que cela signifie, ni si l’Agilité est vraiment morte, si cela peut mourir… Je souhaiterais vous proposer mon interprétation autour de la vision économique du marché de l’Agilité et plus précisément de celui du coaching Agile.

Modèle des évolutions d’un marché économique jusqu’à la consolidation

Tout a commencé quand j’ai appris que PMI avait racheté Agile Alliance4. Tout ceci m’a rappelé un phénomène de consolidation et m’a ramené quelques années en arrière dans mes cours d’économie. Les évolutions des marchés économiques ! Pour ceux qui ne sont pas experts voici un modèle présentant les différentes phases que peut suivre un marché économique jusqu’à la phase de consolidation des acteurs :

Naissance du marché :

  • Le marché émerge, souvent à la suite d’une innovation ou d’un changement structurel.
  • De nombreux acteurs se lancent, testant différents modèles économiques.
  • Forte concurrence, avec des barrières à l’entrée relativement faibles.

Croissance rapide (expansion) :

  • Augmentation de la demande et forte croissance des revenus.
  • Les acteurs investissent massivement dans le développement de leur offre.
  • Apparition des premières spécialisations et différenciations entre entreprises.

Saturation et concurrence intense :

  • Le marché atteint un point de maturité où la demande commence à ralentir.
  • Les acteurs en place cherchent à défendre ou augmenter leurs parts de marché, entraînant des pressions sur les marges.
  • La concurrence devient de plus en plus féroce.

Consolidation des acteurs :

  • Les entreprises moins compétitives ou marginales disparaissent ou sont rachetées.
  • Les grandes entreprises acquièrent leurs concurrents pour augmenter leur part de marché, réduire leurs coûts et accéder à de nouvelles ressources ou technologies.
  • Le nombre d’acteurs diminue, laissant place à quelques leaders dominants.

Appliqué au coaching agile

Si je pose maintenant l’hypothèse que les offres liées à l’agilité et plus particulièrement au coaching Agile suivent ce modèle, cela donnerait donc les phases suivantes :

Naissance de l’Agilité entre 1990 et au début des années 2000

Quelques experts commencent à travailler avec des boucles courtes de mise en production et de retours (feedback) afin de répondre aux besoins d’adaptabilité des entreprises. Ils consignent et partagent leurs apprentissages à travers des cadres de travail comme Scrum, Crystal, XP, Kanban… En 2001, 17 d’entre eux, principalement nord-américains, se réunissent et définissent le manifeste pour le développement Agile de logiciels5. On voit alors apparaître les premiers coachs agiles, souvent d’anciens développeurs ou chefs de projets passionnés par cette approche. Cela leur permet notamment d’accompagner les équipes en tant que formateurs et mentors. La concurrence est faible, car la demande est en pleine expansion. Vers 2010, le rôle de coach agile est formalisé par Lyssa Adkins dans son livre Coaching Agile teams et le framework Scrum est défini dans le guide Scrum par Ken Schwaber et Jeff Sutherland, ses créateurs. En France, quelques ESN (appelées SSII à l’époque), principalement de petite et moyenne taille et spécialisées en développement logiciel, se lancent dans l’aventure.

Croissance rapide entre 2010 et 2015

L’agilité devient un mot-clé dans les entreprises, et la demande en coaching explose. Le cadre de travail Scrum s’impose comme le cadre agile le plus utilisé, et des organismes de formation tels que Scrum Alliance, Scrum.org multiplient les certifications (Scrum Master, Product Owner, etc.). Les petites structures (freelances, cabinets de conseil spécialisés) se développent, tandis que les grandes entreprises de conseil (Accenture, Deloitte, Capgemini, etc.) commencent à intégrer l’agilité dans leurs offres. Des expérimentations de cadres agiles sont menées dans des domaines autres que le développement logiciel. Par ailleurs, plusieurs cadres de travail agiles à l’échelle viennent compléter et appliquer les pratiques et valeurs du « Manifeste Agile » au sein des organisations : LeSS en 2008, SAFe en 2011, Nexus en 2015, etc.En France, plusieurs grandes entreprises du CAC 40, notamment dans les télécoms, les grandes banques et les assurances, lancent leur transformation agile. Ces entreprises mettent en place des centres d’excellence Agile pour accompagner ces transformations, et elles embauchent ou forment des coachs agiles en interne. Les coachs agiles ne viennent plus exclusivement du monde du logiciel. Leur posture évolue, intégrant davantage de pratiques liées au « coaching » (questionnement, facilitation, etc.) et au rôle d’agent du changement.

Saturation et concurrence intense après 2015

Le terme « agile » est devenu un mot-valise dans lequel les puristes et les passionnés ne se reconnaissent plus. Les signataires du « Manifeste Agile » n’hésitent pas à proposer d’autres alternatives, comme Heart of Agile de Alistair CockBurn en 20156 ou encore Developers should abandon Agile de Ron Jeffries. Les grandes entreprises qui amorcent leurs transformations s’appuient sur les cadres de travail les plus utilisés, tels que SAFe et Scrum. Cependant, les retours d’expérience sur les transformations « agiles » restent mitigés.

La crise de la Covid-19 en 2020 transforme le paysage des entreprises avec l’apparition du travail en mode hybride, combinant présentiel et télétravail via des outils comme Zoom, Microsoft Teams, ou Google Meet, ainsi que l’utilisation de tableaux numériques tels que Miro, Mural, et Klaxoon. La demande ralentit dans certaines régions ou secteurs où l’agilité est déjà bien implantée, tandis que la concurrence s’intensifie entre les indépendants et les petites structures, souvent locales. Les grandes entreprises intègrent désormais le coaching agile dans des offres plus globales, centrées sur la transformation digitale. Plusieurs acteurs rencontrent des difficultés à se différencier en raison de formations similaires et d’approches trop génériques. La pression sur les prix augmente, rendant difficile la survie des petits acteurs isolés.

Consolidation des acteurs vers 2025

Les grandes entreprises de conseil acquièrent des cabinets spécialisés en coaching agile pour renforcer leur expertise, tandis que les principaux acteurs du marché rachètent des structures plus petites (comme PMI et Agile Alliance). Les ESN non spécialisées dans les transformations changent de stratégie et ne mettent plus en avant les offres de coaching agile. Les coachs indépendants peinent à rivaliser face aux grands cabinets ou à se distinguer dans un marché saturé. Les prix sont tirés vers le bas, et les clients privilégient les grandes enseignes pour minimiser les risques, comme en collaborant avec des cabinets reconnus tels que Deloitte ou Accenture. Plusieurs publications sur les réseaux sociaux prévoient une mutation du marché de l’agilité : Agile Is Undead…A Synthesis de Jurgen Appelo, ou encore des analyses annonçant la fin de l’agilité. On observe également une standardisation croissante des approches, avec des cadres de travail comme SAFe et Scrum devenus des références dominantes. L’intelligence artificielle et l’écologie émergent comme de nouveaux critères différenciants, venant compléter ou remplacer les anciennes pratiques.

Les périodes mentionnées dans ce paragraphe reflètent mon interprétation et ont été enrichies par une analyse avec l’aide de l’IA.

Après la consolidation

Voici le futur proposé par une IA sur le marché du coaching Agile. J’ai l’impression pour ma part que certains points sont déjà d’actualité.

Oligopole dominé par les grandes structures :

  • Quelques grands cabinets (EY, McKinsey, etc.) dominent le marché, avec des approches standardisées.
  • Les labels ou certifications (Scrum Alliance, SAFe, etc.) deviennent incontournables pour être pris au sérieux.

Optimisation des services :

  • Les grandes structures proposent des offres intégrées : coaching agile, transformation organisationnelle, et outils technologiques.
  • Innovation dans les méthodologies, intégrant des tendances comme l’agilité à l’échelle, l’agilité business et l’agilité durable (sustainability).

Barrières à l’entrée élevées :

  • Pour les nouveaux coachs ou cabinets, il devient difficile d’entrer sur le marché sans certifications coûteuses ou partenariats avec des grands noms.
  • Les clients recherchent des preuves de résultats ou des références solides, limitant les opportunités pour les petits acteurs.

Disruption possible :

  • Si un nouveau cadre ou méthodologie plus efficace émerge (par exemple, un modèle hybride ou post-agile), les leaders pourraient être remis en question.
  • L’intelligence artificielle et l’automatisation pourraient également bouleverser le marché, avec des outils capables de guider des équipes sans intervention humaine.

Cycle de renouvellement :

  • Si l’agilité évolue vers de nouvelles approches (post-agilité, human-centric agility), un nouveau cycle peut émerger, avec de nouveaux acteurs et méthodes.

Pour conclure

Pour conclure, mon interprétation est que le marché des offres de coaching agile est entré dans une phase de maturité, ce qui se traduit pour moi par :

  • Des entreprises qui ont créé des centres d’expertise agile et embauché des coachs agiles en interne.
  • Un marché plus difficile pour les indépendants, avec une baisse des prix sur les offres de mission.
  • Une consolidation des acteurs du marché : rachat d’Agile Alliance par PMI et acquisition de SAFe par un fonds d’investissement en 2021.
  • Des acteurs cherchant à se différencier par le recours à l’intelligence artificielle, ou en adoptant une conscience écologique croissante.

Je pense néanmoins, et c’est un parti pris, que les transformations d’entreprises restent d’actualité dans un monde plus que jamais imprévisible et changeant. L’entreprise ne peut plus se contenter de se percevoir comme un système isolé de son écosystème et des limites planétaires.

En m’appuyant sur la spirale dynamique7, décrite comme un « modèle imagé de l’évolution par stades de la conscience humaine et des systèmes de valeurs.« , j’ai l’impression qu’un certain nombre d’entreprises n’ont pas encore atteint un fonctionnement leur permettant d’appréhender la complexité des niveaux les plus avancés. Ces entreprises auront besoin d’acteurs extérieurs à leur culture pour les accompagner dans cette progression vers des niveaux de conscience et de fonctionnement plus adaptés.

Et vous, qu’en pensez-vous ?

PS : Merci à Régis Schneider et Julien Karoubi 8 pour leurs retours constructifs et leurs apports sur le sujet.

PS1 : Je vous partage également un article de Pablo Pernot sur le sujet9

  1. https://www.linkedin.com/pulse/agile-isnt-dead-its-failing-reflections-industry-brad-nelson-qq1oc/?trackingId=z2SRE8qrQG6nisTRlX2cpw%3D%3D ↩︎
  2. https://www.linkedin.com/pulse/forget-agile-dead-heres-whats-really-happening-project-upright-giwsc/?trackingId=FKKtwPA1ReuXkBxGTkAdBA%3D%3D ↩︎
  3. https://www.linkedin.com/pulse/agile-undead-synthesis-jurgen-appelo-54wne/?trackingId=8zBF4WZnST2%2FuA47rV6lLQ%3D%3D ↩︎
  4. https://www.linkedin.com/posts/julienkaroubi_et-si-et-si-le-bashing-des-frameworks-activity-7281248797505019904-PESe?utm_source=share&utm_medium=member_desktop ↩︎
  5. https://agilemanifesto.org/iso/fr/manifesto.html ↩︎
  6. https://heartofagile.com/?lang=fr ↩︎
  7. https://fr.wikipedia.org/wiki/Spirale_dynamique ↩︎
  8. https://www.linkedin.com/posts/julienkaroubi_crossing-the-chasm-cest-le-moment-activity-7278904877840228352-AqFY?utm_source=share&utm_medium=member_android ↩︎
  9. https://pablopernot.fr/pdf/2021-regard-agilite-20-ans.pdf ↩︎

Quelques petites réflexions autour du WSJF

Eric Lannemajou5 commentaires

L’histoire et la théorie

WSJF ou Weighted Shortest Job First rendu populaire grâce au framework Agile à l’échelle SAFe permet entre autre de prioriser les fonctionnalités à développer et est défini de la manière suivante dans SAFe :

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs

La formule mathématique pour prioriser les éléments est la suivante :

Regardons maintenant rapidement les composantes du coût du retard qui est la somme de 3 éléments : la valeur utilisateur/métier, le coût lié aux contraintes de temps, le coût évité grâce à l’information (risque et opportunités) apportée par la fonctionnalité. Pour simplifier, on part alors du principe que plus on met de temps à mettre une fonctionnalité sur le marché (ou entre les mains de l’utilisateur final) , plus il devient urgent de livrer celle-ci afin de ne pas bloquer les autres items à développer.

Sans chercher trop longtemps sur le net, vous pouvez trouver ici un excellent article qui explique la provenance de cet outil ainsi qu’une vidéo ci-dessous de Don Reneirtsen son inventeur expliquant le coût du retard.

Le WSJF répond au premier principe Lean Agile de SAFe qui consiste à prendre des décisions se basant sur une vue économique. Vous pouvez utiliser le WSJF pour motiver toutes vos décisions concernant les fonctionnalités à réaliser, du moins c’est ce que dit la théorie. Mais en pratique ?

Les réflexions autour de la mise en pratique

Voici en vrac quelques réflexions et constats sur les ateliers WSJF :

  • La simplification par la suite de Fibonnaci dans le coût du retard
  • La simplification du délai de mise en oeuvre par la charge de développement
  • La fausseté des chiffres
  • Les biais cognitifs
  • La satisfaction client
  • Les fonctionnalités techniques

La simplification par la suite de Fibonnaci dans le coût du retard

Lorsque Don Reinersten a défini le coût du retard, il l’a envisagé avec une vision économique et c’est en toute logique que chacun des éléments du coût du retard s’exprime en devise financière et qu’ils peuvent donc être facilement additionnés puisqu’on effectue une opération sur des nombres ayant la même unité de mesure. On est ici dans une estimation absolue et non dans une estimation relative (on n’estime pas les éléments les uns par rapport aux autres). Donc pas de problème dans la théorie.

Mais en pratique, il est très difficile de pouvoir estimer le coût du retard en espèces sonnantes et trébuchantes. Heureusement qu’un certain framework à l’échelle a pensé à tout et propose de simplifier les valeurs du coût du retard en estimant de manière relative chacune des composantes de ce dernier. On va donc pour chacune des 3 composantes rechercher l’élément le plus petit et estimer les autres de manière relative par rapport au premier en utilisant la suite de Fibonnaci simplifiée (1,2,3,5,8,13,20,40). Voici un exemple avec deux fonctionnalités pour vous expliquer :

Valeur utilisateur/métier :

  • Fonctionnalité A : valeur estimée 1000 € c’est la plus petite de la liste donc elle prendra la valeur de référence 1
  • Fonctionnalité B : valeur estimée 100 000 €, elle est 100 fois plus importante que A donc avec la suite de Fibonnaci simplifiée elle sera probablement à 40.

Valeur du coût lié aux contraintes de temps :

  • Fonctionnalité B : perte de 10 € par semaine où la fonctionnalité est absente. C’est la plus petite et prend la valeur de référence 1.
  • Fonctionnalité A : perte de 1000 € par semaine où la fonctionnalité est absente. C’est 100 fois plus important que la fonctionnalité B donc on attribuera probablement la valeur 40 à cette fonctionnalité.

Valeur liée à l’information apportée par la fonctionnalité : A = B = 1

Coût du retard :

  • Fonctionnalité A : 1 + 40 + 1 = 42
  • Fonctionnalité B : 40 + 1 +1 = 42

On a donc le même coût du retard pour les deux fonctionnalités et si on s’arrête là, on ne peut pas prendre de décision sur cette valeur. Alors que si nous étions resté sur des considérations purement économiques , nous aurions probablement choisi de réaliser la fonctionnalité B avant A. On voit ici que le changement d’échelle entre les composantes amène à additionner des éléments qui n’ont finalement pas la même grandeur car exprimés en relatif. Au passage, les résultats perdent leur unité.

La simplification du délai de mise en oeuvre par la charge de développement

Le dénominateur est normalement le coût de mise en oeuvre de la fonctionnalité souvent simplifié par le coût de réalisation. Si on reste sur une évaluation économique, on a donc un coût du retard exprimé en devise par unité de temps (ex 500 €/semaine) et en dénominateur un coût qui correspond à un délai. Donc en multipliant le temps de réalisation par le coût du retard nous aurions le coût du retard pour le délai de mise en oeuvre. Vous suivez toujours ?

Prenons un exemple :

  • Une fonctionnalité A me fait perdre 1000€ par jour où elle n’est pas mise à disposition des utilisateurs. Si il faut 15j pour la mettre à disposition des utilisateurs alors je perdrai 15 000 euros (1000 * 15). Si au contraire il ne faut que 2j pour la mettre à disposition, je ne perdrai que 2000€.

Donc plus le délai de mise à disposition de la fonctionnalité est petit, moins je perds d’argent.

L’ambiguïté est encore une fois apportée par la simplification : le fait qu’une équipe puisse développer la fonctionnalité en 1 semaine ne signifie pas qu’elle pourra être mise à disposition dans le même délai. J’ai déjà rencontré des équipes programmes qui devaient attendre plusieurs mois pour voir livrée une fonctionnalité de quelques jours parce qu’elles n’avaient pas la main sur la priorisation de l’équipe de réalisation. Et je vous passe le fait que la suite de Fibonnaci simplifiée va encore rendre l’opération encore plus fausse. Vous pouvez trouver d’autres justification ici

La fausseté des chiffres

Nous avons donc des résultats complètement faux et ils sont faux car :

  • Une estimation est fausse de base et donc tous les chiffres fournis sont faux
  • L’opération mathématique est fausse car on ne tient pas compte des ordres de grandeur

Pourtant les chiffres et les mathématiques nous invitent à penser que ces résultats sont d’une exactitude implacable. Un petit peu comme dans les sondages. Un petit biais cognitif ici ? Au passage, j’en profite pour dénoncer le fait que certaines personnes pendant l’atelier savent très bien tirer parti de ces approximations pour infléchir les résultats vers les fonctionnalités qu’ils souhaitent voir développées en premier. Avec ces constats, je rappelle souvent aux participants que les résultats du WSJF ne sont pas une vérité immuable et que ce n’est qu’un outil d’aide à la décision.

Les biais cognitifs

Voici 2 biais cognitifs parmi les nombreux biais qui peuvent se manifester dans une séance de WSJF :

Le biais des coûts irrécupérables : l’exercice a pour vertu de se baser sur une vision économique et de contrer le biais des coûts irrécupérables; le biais des coûts irrécupérables est celui qui nous pousse à continuer à investir dans un élément même si il n’apporte plus de valeur parce que nous avons trop investi dedans :

  • Exemple : vous attendez un bus depuis 10 min et il n’arrive toujours pas, le tableau des horaires indique un retard de 20 min supplémentaires. Vous continuez à attendre à cause des 10 min que vous avez déjà dépensé au lieu de choisir un autre moyen de locomotion qui pourrait vous amener plus vite à votre destination.

En effet, imaginons qu’une fonctionnalité a été développée à moitié à la fin d’un incrément (cf SAFe). Il y a de fortes chances que lorsqu’on va recalculer le WSJF pour cette fonctionnalité, le délai de mise à disposition chute et donc que la fonctionnalité remonte mathématiquement dans la priorisation. Si cette fonctionnalité métier pour une raison ou une autre perd de la valeur utilisateur/métier alors le numérateur baisse et le résultat fera descendre le résultat du calcul.

Le biais de conformité : l’atelier doit permettre à tous les acteurs présents de s’exprimer librement lors du poker planning des items. après un premier tour de vote, on peut voir apparaître un biais qui force les personnes qui n’ont pas vraiment d’avis à se ranger dans le camp de la majorité.

La satisfaction client

Bon, faisons fi du calcul et des biais, vous obtenez une liste d’items ou de fonctionnalités priorisées et vous vous dites donc que vous allez donc prendre les premières et les développer pour le Minimum Marketable Produit (produit minimum répondant au besoin utilisateur). Mais au final, qu’en est-il de la satisfaction client ? Est-ce que les fonctions produisant un effet wahou sont effectivement dans cette liste ? Comme on aurait pu les trouver à l’aide du diagramme de KANO ? Pas certain que la valeur utilisateur du coût du retard ou la valeur liée à l’information ait inclus cet aspect. Qui par la même sera très difficile à chiffrer…

Les fonctionnalités techniques

Autre difficulté rencontrée : que faisons nous lorsqu’un item à prioriser n’apporte pas directement de valeur au client ? Dans le cas de fonctions purement techniques par exemple ? Problème de découpage vous me direz ? Mais parfois des API Back Office doivent être développées et mises à disposition avant que les services consommateurs puissent être disponibles. Dans ce cas, c’est la composante liée à l’information qui porte la valeur du composant. Encore une fois, cette valeur est difficile à estimer… Le WSJF va permettre grâce aux différentes composantes du coût du retard, de redonner du poids à tous les items qui ne sont pas visibles de l’utilisateur (comme les items techniques) mais qui sont néanmoins nécessaires à toutes les autres fonctionnalités.

Le WSJF, cela fonctionne !

Donc au final, nous avons des items difficiles à estimer, des estimations fausses, des opérations fausses…Et pourtant cela fonctionne quand même le WSJF ! Oui cela fonctionne ! Alors comment ? Et Pourquoi ?

Briser les silos et transmettre la stratégie de l’entreprise!

Le WSJF est selon la théorie une instance de décision et sa vertu réside surtout dans le travail préparatoire sur les items et des personnes effectuant ce travail. En effet, nous allons pendant ce travail préparatoire à la recherche des coûts, faire collaborer les personnes du marketing avec les architectes, les développeurs, les sponsors… Ces personnes vont se retrouver ensemble dans des séances de WSJF qui peuvent parfois durer plusieurs heures alors qu’elles n’auraient peut être pas pu avoir cette occasion d’échanger. Le format de l’atelier doit en théorie permettre à chacun de s’exprimer librement… Ces échanges et recherches autour de la valeur sont aussi le moyen de faire passer des informations sur la stratégie de l’entreprise !

Le consensus et l’alignement !

Tout le monde va se retrouver dans un même atelier et choisir de s’aligner autour d’une liste d’items. Que celle-ci soit juste ou fausse, importe moins que l’alignement et le consensus autour de cette dernière. Le consensus est obtenu après plusieurs échanges; charge quand même à l’animateur de faciliter les débats : à la vue des approximations, inutile de débattre plusieurs heures pour trancher entre une valeur de 1 ou 2 même si on passe du simple au double. L’exercice d’alignement fait prendre conscience à tous les acteurs, des enjeux et contraintes de chacun. La DSI prend connaissance des enjeux métiers et contraintes de temps liées au marché et le métier à son tour est informé des contraintes liées à la réalisation des fonctionnalités.

Donc le véritable sens ou but des séances de WSJF seraient moins de prioriser des items que de faire collaborer des personnes entre elles et de les faire commencer à s’aligner sur des objectifs . Du moins c’est mon interprétation de l’exercice !

Encore une suggestion avant de terminer, pourquoi ne pas intégrer dans le coût du retard une composante indiquant le coût carbone de la fonctionnalité ? Je pense que cela pourra bientôt être fort utile. Qu’en pensez-vous ?

Remerciements : Merci à Anne Doublier, Maud Guyot et Yann Tisseyre pour leurs retours et aide sur cet article.

Ressources :