Catégorie : Coaching

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 ↩︎

Sommes-nous une équipe ?

Eric LannemajouLaisser un commentaire
Felix Joseph Barrias – Les exilés de Tibere

Aujourd’hui, toutes les entreprises aspirent à former des équipes performantes ; la structure d’équipe semble être le saint Graal pour s’adapter à un marché en constante évolution et de plus en plus exigeant. Dans certaines circonstances, les équipes pourraient alors atteindre leur plein potentiel de performance. Cependant, même si cela peut sembler vrai dans le domaine du sport, mon expérience en entreprise me montre que c’est rarement le cas ! Je vous propose de revisiter le concept d’équipe afin de mieux comprendre comment favoriser leur croissance et les aider à exceller.

Nous explorerons d’abord l’étymologie du mot « équipe » et quelques définitions pertinentes. Ensuite, nous examinerons cette notion sous un angle systémique, pour enfin voir comment elle est abordée dans le manifeste Agile et le cadre méthodologique Scrum.

Origine et définition du mot « équipe »

En revenant à l’origine étymologique du mot « équipe », une recherche rapide sur internet révèle plusieurs significations. D’une part, on trouve une description désignant soit « une suite de chalands attachés les uns aux autres et tirés par des hommes […] »1 soit « un lien avec le mot équipage[..] Ce qui garnit en personnel humain, un bateau avec cette idée de travail en commun, de façon de s’aider les uns les autres[…] Efficacité de plusieurs personnes qui tendent au même but […]«  selon Alain Rey2.

Explorons la métaphore de l’équipage :

  • Les membres partagent un objectif commun, celui de faire avancer le bateau dans une direction définie.
  • Ils ne peuvent appartenir simultanément à deux équipages sur deux bateaux différents.
  • Ils effectuent des actions complémentaires et souvent interdépendantes pour faire avancer le bateau ou participer à la vie de l’équipage.

Ces principes ne s’appliquent pas aux traversées en solitaire comme le « Vendée Globe », mais demeurent vrais pour la majorité des équipes sportives. Toutefois, lorsqu’on transpose ces réflexions au monde du travail, cette analogie semble moins pertinente. Quelle en est la raison ? Le sens du mot aurait-il évolué ?

Selon la première définition du dictionnaire « Le Robert » trouvée en ligne, une équipe est : « un groupe de personnes devant accomplir une tâche commune »3.

En approfondissant dans divers ouvrages et en effectuant des traductions, on découvre les définitions suivantes :

  • En psychologie sociale, une équipe est : « un groupe primaire ou « groupe restreint » composé de 4 à 20 individus ayant un but commun, se connaissant et entretenant des relations interpersonnelles ».4
  • Une définition plus précise stipule : « une équipe est un petit nombre de personnes aux compétences complémentaires s’engageant pour un but commun, des objectifs de performance et une approche dont elles se tiennent mutuellement responsables »5.

Ces deux définitions renvoient à des éléments de l’équipage d’un bateau : « but commun », « tâches complémentaires »…, tout en précisant que le nombre de personnes impliquées est restreint. Pourquoi cette précision ?

On peut supposer que cette spécification est liée au nombre d’interactions entre les membres. Plus il y a de personnes, plus le nombre d’interactions augmente, ralentissant ainsi la prise de décision et l’action de l’équipe6.

En outre, la taille de l’équipe ajoute de la complexité aux relations externes. Une troisième définition traite de ces interactions extérieures :

« Une équipe est un ensemble d’individus qui sont interdépendants dans leurs tâches, qui partagent la responsabilité des résultats, qui se voient et qui sont vus par les autres comme une entité sociale intacte intégrée dans un ou plusieurs systèmes sociaux plus larges (par exemple, une unité commerciale ou la société), et qui gèrent leurs relations au-delà des frontières organisationnelles. »7 .

L’équipe comme entité sociale, comme système

L’équipe est vue par ses membres ainsi que par l’écosystème comme « une entité sociale intacte intégrée dans un ou plusieurs systèmes sociaux plus larges[…] «  L’équipe devient alors une dualité : à la fois un groupe de personnes et une entité distincte et vivante, semblable aux particules d’énergie qui peuvent également former une onde. En systémique, c’est le concept de totalité qui affirme que le tout est plus que la somme des parties. Il existe donc une dynamique supplémentaire qui donne vie à cette entité qu’est l’équipe. Les individus au sein d’une équipe adopteront probablement des comportements différents en présence des autres membres par rapport à ceux qu’ils manifesteraient de manière individuelle. Comme Coluche l’illustrait dans son sketch sur les militaires, cette interaction collective influe sur les actions et attitudes des individus.

L’équipe constitue donc un système et selon Donella H. Meadows à qui l’ont doit « Thinking in Systems » mais également le non moins célèbre rapport du club de Rome définissant les limites à la croissance, un système :

« Un système est un ensemble de choses – personnes, cellules, molécules ou quoi que ce soit d’autre – interconnectées de telle sorte qu’elles produisent leur propre modèle de comportement au fil du temps. Le système peut être secoué, resserré, déclenché ou entraîné par des forces extérieures. Mais la réponse du système à ces forces est caractéristique de lui-même, et cette réponse est rarement simple dans le monde réel.[…] La partie la moins évidente du système, sa fonction ou son but, est souvent le déterminant le plus crucial du comportement du système[…]« 8

Lorsqu’on considère une équipe comme un système, il devient clair qu’elle ne se compose pas simplement de personnes travaillant ensemble pour atteindre un objectif commun. Par conséquent, il est crucial de se concentrer sur la constitution de cette équipe. Si les composantes d’un système sont faciles à identifier (les membres de l’équipe, par exemple), d’autres éléments sont plus difficiles à discerner : les interactions entre les personnes, les valeurs, les croyances, les relations avec l’écosystème… Ces éléments influencent néanmoins fortement le comportement du système. La construction d’une équipe vise à rendre ces éléments explicites afin de mieux comprendre comment ils impactent le comportement du système qu’est l’équipe. Pour démarrer une équipe, j’aime utiliser certains ateliers proposés dans « Liftoff9 » de Diana Larsen, qui permettent d’aligner les parties prenantes et l’équipe, ou encore utiliser la version simplifiée du Team Canvas. Pour favoriser les interactions, j’apprécie l’atelier « Give and take » de Thiagi en précisant que l’objectif est de se concentrer sur les interactions entre les différentes personnes plutôt que sur les rôles individuels. Le lancement d’une équipe pourra être abordé plus en détail dans un autre article si nécessaire.

Dans le Manifeste « Agile »

Le manifeste Agile 10reste vague sur le concept d’équipe mais indique dans deux des douze principes que celle-ci doit être auto-organisée et doit s’améliorer de façon continue. Ceci laisse bien évidemment une liberté d’organisation.

« Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées. »

« À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.« 

Le manifeste Agile fait également référence aux interactions entre les personnes à travers la première valeur comme pour rappel du fonctionnement d’un système.

« Les individus et leurs interactions plus que les processus et les outils »

Dans Scrum

Le guide Scrum11 est plus précis que le manifeste Agile concernant une équipe. on peut lire :

  • « L’unité fondamentale de Scrum est une petite équipe[…]« , afin de limiter la complexité liée au nombre d’interactions.
  • « La Scrum Team se compose d’un Scrum Master, d’un Product Owner et de Developers […] » les auteurs clarifient ici les différentes responsabilités.
  • « […] composée de professionnels focalisés sur un seul objectif à la fois, l’Objectif de Produit […] » afin d’aligner les membres sur un objectif commun.
  • « Les Scrum Teams sont pluridisciplinaires, leurs membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint […] « . On essaie ici de réduire les dépendances avec d’autres équipes ou membres extérieurs à l’équipe afin d’optimiser le flux de livraison de valeur.
  • « Elles sont également autogérées, elles décident en interne qui fait quoi, quand et comment.[…] » Idem le point précédent pour accélérer la livraison.

On voit ici que les auteurs de Scrum ont pris soin de border le concept d’équipe en rendant plusieurs notions explicites : taille, responsabilités, objectif…

Pour l’anecdote, le concept d’équipe comme entité distincte a été revue en 2020 par ses créateurs Ken Schwaber et Jeff Sutherland.

En 2017, le guide Scrum définissait une équipe Scrum de la manière suivante :

« Une équipe Scrum comprend un Product Owner, une équipe de développement (Development Team) et un Scrum Master[…] ».

Ceci entraînait certaines confusions du type : suis-je dans l’équipe ou en dehors ? Quand je parle d’équipe, je parle d’équipe Scrum ? ou de l’équipe de développement ? Comment les partenaires savent à quelle équipe ils s’adressent ?…

En 2020, l’équipe Scrum a fondamentalement changé pour devenir

« L’unité fondamentale de Scrum est une petite équipe, la Scrum Team. La Scrum Team se compose d’un Scrum Master, d’un Product Owner et de Developers. Il n’y a pas d’équipe dans l’équipe ni de hiérarchies. Il s’agit d’une seule et même unité stable, composée de professionnels focalisés sur un seul objectif à la fois, l’Objectif de Produit[…] »

Ce qui évite les confusions dans l’équipe Scrum.

En me basant sur mon expérience passée, je vous propose, d’éviter le concept d’équipe dans l’équipe pour éviter tout ces aléas. Ou du moins si cela est créé, que cela reste ponctuel et interne à l’entité sociale vue de l’extérieure.

Conclusion

Le fait de considérer la dualité de l’équipe nous invite à nous demander comment construire et entretenir cette entité sociale.

On peut supposer que pour construire une équipe il faudra à la fois tenir compte des différents membres de l’équipe, de leurs interactions mais également de l’environnement autour de celle-ci. parmi lesquels : un but commun, les limites de responsabilités définies, les dépendances avec l’environnement, les complémentarités des individus, leur motivation…

NB : article écrit avec l’aide de Chat GPT

Ressources

  1. Pour une approche du travail en équipe – Jean Michel Motta ↩︎
  2. Le mot équipe raconté par Alain Rey ↩︎
  3. Définition de équipe par le dictionnaire Le Robert ↩︎
  4. Maubras, Rodéric (2020-11-04T22:58:59.000). Coacher une équipe avec la psychologie sociale (French Edition) . Eyrolles. Édition du Kindle. ↩︎
  5. « a team is a small number of people with complementary skills who are commited to common purpose, performance goals, and approach for wich the hold themselves mutually accountable » – The wisdom of teams Jon R Katzenbach & Douglas K. Smith ↩︎
  6. Why teams should be just 5 people – Marcus Hyett ↩︎
  7. « A team is a collection of individuals who are interdependent in their tasks, who share responsibility for outcomes, who see themselves and who are seen by others as an intact social entity embedded in one or more larger social systems (for example, business unit or the corporation), and who manage their relationships across organizational boundaries. » (Cohen and Bailey, 1997 : 241) ↩︎
  8. Thinking in Systems – Donella H Meadows ↩︎
  9. https://www.amazon.com/Liftoff-Launching-Agile-Teams-Projects/dp/097792016X ↩︎
  10. https://agilemanifesto.org/iso/fr/manifesto.html ↩︎
  11. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.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 :

Apprendre à découper des user stories en jouant

Eric LannemajouLaisser un commentaire

Découper une user story est un des problèmes souvent remonté par les équipes qui travaillent en SCRUM. Vous pouvez trouver sur internet plusieurs articles qui définissent le format d’une user story et je vous renvoie notamment vers le blog de Oeil de Coach– comment rédiger des user stories comme hulk pour en savoir plus. Le site de SAFe (en anglais) indique aussi ce format ainsi que plusieurs axes pour découper une story selon :

  • les étapes du workflow
  • les règles métier
  • l’effort majeur
  • simple/complexe
  • la variation dans les données
  • les méthodes sur les données
  • les opérations
  • les qualités du système
  • les scénarios, uses cases
  • les études techniques ou spikes

Ces différents axes sont visualisables ici sous la forme d’un poster mais le découpage selon ces critères reste toujours un peu compliqué.

Mike Cohn qui est l’auteur de plusieurs livres sur les user stories, se base quant à lui sur 5 axes qu’il a décrit sur son blog à travers l’acronyme SPIDR :

  • S pour Spike : les études techniques ; si une user story vous paraît compliquée et que vous ne savez pas comment la réaliser, vous pouvez toujours effectuer dans un premier temps une étude technique ou fonctionnelle afin de récupérer des informations qui vous aideront par la suite à évaluer sa complexité.
  • P pour Paths : les chemins ou les différentes façon de faire une activité ; si vous avez par exemple une story qui vous précise que l’utilisateur souhaite acheter un objet avec différents moyens de paiement, vous pouvez préciser dans une première story les étapes du paiement par carte bleue, dans une deuxième les étapes relatives à un autre moyen de paiement comme le virement, dans une troisième…et ainsi de suite.
  • I pour Interfaces : les différents navigateurs web, le hardware…
  • D pour Data : les différents types de données ; si vous avez une story par exemple sur l’affichage du nom et du prénom d’un utilisateur, vous pouvez choisir de la découper pour afficher le nom dans une première story et le nom et le prénom dans une deuxième. Les deux stories sont alors indépendantes et vous pouvez donc choisir celle à implémenter en fonction de la priorité et du budget que vous avez.
  • R pour Rules : les règles métier ; vous pouvez choisir d’implémenter le cas le plus simple et créer des user stories complémentaires pour gérer les règles supplémentaires…

Pour vous aider à découper vos stories, vous pouvez jouer à Elefant Carpaccio crée par Alistair Cockburn, l’un des signataires du Manifeste Agile. Ce jeux nécessite une disponibilité de 1h30 à 2h. Mais si vous avez moins de temps, je vous propose de partir des axes de split de Mike Cohn ci-dessus et d’apprendre à découper les stories en jouant à split my story. Le jeu permet dans un premier temps de se familiariser avec les axes de SPIDR puis dans un second temps de créer vos propres stories découpables. N’hésitez pas à me poser des questions si vous souhaitez avoir davantage d’informations et merci de me donner vos feedbacks afin de continuer à améliorer le jeu 😉

NB : sur conseil de Jérôme Carfantan, je rajoute ce lien vers le jeu Split Poker de SOAT. Merci Jérôme.

Ressources du jeu

splitmystory-cardsTélécharger
splitmystory-cards_axes_with_iconsTélécharger
splitmystory-diplomaTélécharger
splitmystory-rules_v1.1Télécharger

Liens et références :

Le « tu » tue, ou la mécanique des mots

fxbravoLaisser un commentaire

Il vous est certainement arrivé de terminer un échange, avec une ou plusieurs personnes, déçu et frustré de ne pas avoir bien communiqué.

Cette situation banale peut déboucher sur un blocage.

Je me propose de décortiquer le processus permettant de résoudre des problèmes de communications internes (avec soi-même) et externes (avec un groupe) à travers ces différents outils:

  • la Stratégie de résolution de problèmes,
  • la Systémique,
  • la Communication Non Violente,
  • et les 5 Phases du deuil.

Une fois l’échange fini, vous avez peut-être eu envie d’en discuter avec votre entourage. Dans la majeure partie des cas, votre entourage vous conseille avec du « tu aurais dû » ou « tu aurais pu », en utilisant un ton bienveillant. La plupart de ces conseils peuvent être logiques d’ailleurs, et résonner en vous.

Et plus vous en discutez avec votre entourage, plus vous ressassez l’échange, et n’arrivez pas à passer à autre chose. Vous bouclez.

Afin de résoudre ce problème il est intéressant de se servir de l’excellente méthode de résolution stratégique des problèmes de Giorgio Nardone.

Résultat de recherche d'images pour "La stratégie de résolution de problèmes"
La stratégie de résolution de problèmes – G. Nardone

Dans son livre, Nardone insiste sur la première étape qui est de bien définir le problème.

Ceci constitue le premier pas vers la solution (assez logique). Il s’agit donc de décrire de la manière la plus empirique possible les termes de la situation problématique afin de parvenir à en dessiner une image tangible.

Précision :

  • Si le travail se fait en équipe, il faut arriver à un accord unanime sur la définition du problème.
  • Si le travail se fait seul, il est fondamental d’appréhender le problème sous tous les angles possibles avant d’en donner une définition. Il peut être utile de demander à des proches s’ils ont la même lecture de notre problème. cette démarche permet d’éviter de rester prisonnier de ses idées préconçues.

Très souvent, les personnes brûlent cette étape car ils la considèrent comme allant de soi. Si vous ne voulez pas partir sur de mauvaises pistes, il faut prendre le temps nécessaire à la bonne définition du problème: y revenir plusieurs fois, demander l’avis extérieur, examiner sous tous les angles possibles, ….

Voilà pour cette première partie importante.

Après avoir passé en revue un maximum de possibilités, vous arrivez, dans le cas présent, à l’établissement d’un tableau à 2 colonnes:

  • Ce que j’ai fait pendant l’échange
  • Ce que j’aurais dû faire (pensé par moi-même ou par les conseils d’autres personnes)

Dans la première colonne, vous marquerez tout ce que vous avez fait pour remédier au problème de communication avec votre interlocuteur.

Dans la deuxième colonne, vous noterez tous les inputs/conseils qui vous ont été adressés lors de vos divers échanges avec votre entourage.

Une fois les 2 colonnes remplies, vous vous poserez la question suivante: vu que je sais ce que j’ai fait et que je sais ce que j’aurais dû/pu faire, pourquoi cela me tracasse-t-il encore?

Le Penseur in the Jardin du Musée Rodin, Paris March 2014.jpg
Le penseur de Rodin

Ayant déterminé d’où pouvait venir le problème, vous pouvez passer à l’étape de modélisation systémique. Pour ceux qui ne connaissent pas la systémique et les 2 types de boucles de rétroaction, je vous en fait un rapide résumé:

  • une boucle de renforcement a, comme son nom l’indique, une action amplificatrice.
  • une boucle d’équilibrage a, quant à elle, une action d’équilibration.

Boucle de renforcement

La boucle se lit de la manière suivante: au plus je suis « frustré », au plus j’en parle et j’obtiens des « conseils », et au plus j’ai des « conseils », au plus je suis « frustré » de ne pouvoir les mettre en application.

Une fois cette boucle de renforcement posée, il faut trouver ce qui peut moduler son amplification.

Boucle d’équilibrage

La boucle se lit de la manière suivante: au plus je suis dans la « projection » (le terme est ici employé dans sa définition psychanalytique) au plus je suis dans « l’action », et au plus je suis dans « l’action », au moins je suis dans la « projection ».

Vous avez vos deux boucles. Mais cela ne suffira pas à régler intégralement le problème. Il vous faudra savoir ce qui active la boucle d’équilibrage, qui active à son tour la boucle de renforcement.

Pour cela, il est possible d’utiliser d’autres outils, comme la Communication Non Violente (CNV), créé par Marshall Rosenberg (psychologue).

Les 4 étapes de la CNV (Wikipedia)

La CNV est un processus de communication en 4 étapes:

  • Observation (O) : décrire la situation en termes d’observation partageable ;
  • Sentiment et attitudes (S) : exprimer les sentiments et attitudes suscités dans cette situation ;
  • Besoin (B) : clarifier le(s) besoin(s) ;
  • Demande (D) : faire une demande respectant les critères suivants : réalisable, concrète, précise et formulée positivement. Si cela est possible, que l’action soit faisable dans l’instant présent. Le fait que la demande soit accompagnée d’une formulation des besoins la rend négociable.

Voilà d’où peut venir le blocage: vous êtes dans l’incapacité d’agir, de mettre en pratique les conseils de votre entourage, car la situation est tout simplement passée. Une vraie injonction paradoxale!

Les conseils prodigués par vos proches, qui sont tous pleins de bonnes intentions, vous ont fait boucler à chaque fois. Vous ne pouvez tout simplement pas appliquer leurs conseils car cette échange ne se reproduira pas.

Ainsi, lorsque vous transformez tous les conseils du type « tu aurais dû/pu » en « il aurait été possible de », la boucle d’équilibrage opère son changement: vous n’êtes plus dans la projection d’une action, mais dans l’explication théorique générale.

Le « tu » peut être bloquant, culpabilisant et entrainer une boucle (sans fin) de « J’aurais dû/pu ». Le « il » a une vertu de neutralité et de distanciation, qui permet de prendre un recul nécessaire sur la situation.

Bien sûr, certaines personnes ne réagiront pas de la même manière à ce même problème. Ceci dit, les mécanismes décrits dans l’article peuvent se produire dans une multitudes d’autres cas (Les conflits, les TOC, les phobies, ….)

En communication, un mot peut faire toute la différence (avec soi-même et avec les autres).

Pour finir, et vérifier que le problème est bien résolu, vous pouvez vous servir de l’outil créé par Elizabeth Kubler Ross: les 5 phases du deuil

Comme vous pouvez le voir sur le schéma ci-dessus, à la suite d’un échange « traumatisant », il faut passer par un processus distinct de 5 phases. La personne peut passer alternativement de la phase 1 à 4. Tant que le système traumatique est actif, il est impossible d’accéder à la 5ème étape.

En conclusion, si vous avez des conseils à prodiguer, communiquez par le biais du « IL », pas du « TU ». Inspirez-vous de la Communication Non Violente ou autre technique de communication. Les personnes en face vous remercieront.

La communication est un Art, et il faut toute une vie pour essayer de la maîtriser.

Systémiquement.

François-Xavier

Liens et références :

  • La stratégie de résolution des problèmes – G. Nardone – Enrick B. Editions
  • Thinking in systems – D. Meadows – Chelsea Green Publishing
  • Les mots sont des fenêtres – Marshall Rosenberg – Edition La Découverte
  • Sur la vie et le deuil – E. Kubler-ross et D. Kessler – Edition Pocket

La rétrospective : amélioration continue et systémique

Eric LannemajouLaisser un commentaire

220px-PDCA_Cycle_FR.svg

La rétrospective est le rituel SCRUM d’amélioration continue des équipes qui se base sur cette représentation communément connue à tort (cf cycle de Shewhart) sous le nom de roue de Deming ou PDCA : Plan, Do, Check, Act (Planifier, Développer/Réaliser, Contrôler/Vérifier et Ajuster/Améliorer en français). J’ai rencontré des équipes qui avaient tendance à négliger ce rituel, le trouvant trop long ou le sacrifiant sur l’hôtel de la productivité lorsque celles-ci n’avaient plus le temps de réaliser les fonctionnalités du produit ou encore lorsque leur performance n’était plus à la hauteur de leur engagement. Plusieurs raisons peuvent expliquer le fait que les équipes ne perçoivent pas la valeur de la rétrospective et parmi celles-ci, nous pouvons énumérer les suivantes:

  • L’équipe n’a pas compris le sens du rituel
  • Les actions issues de la rétrospective sont trop grosses pour être facilement réalisées
  • Les solutions apportées sont perçues comme des pansements
  • Les actions ne sont pas suivies dans le temps
  • (…)

Je pourrais encore continuer cette énumération mais je souhaite surtout porter votre attention sur les deux premières qui sont le sens de ce rituel et la taille des actions.

Le sens de la rétrospective

La rétrospective est donc le rituel SCRUM dédié à l’amélioration continue d’une équipe. Mais pour être plus précis, ce rituel va chercher à modifier la façon dont l’équipe travaille. En changeant sa façon de travailler, l’équipe va donc agir sur le système. Mais pourquoi s’intéresser au système et non aux individus ? 

Une première partie de la réponse pourrait être qu’une équipe est définie par les relations entre les individus. Lorsqu’une personne rejoint une équipe, cela influence les relations entre tous les membres de l’équipe. Il en est de même lorsqu’un membre de l’équipe la quitte. Pour approfondir sur le sujet, vous pouvez lire « Coaching d’équipe » d’Alain Cardon (polarisation, circularité, rôles délégués…) coaching_equipeou encore vous référer au modèle de Tuckman qui explique les différents états d’évolution d’un groupe. On comprend donc qu’il va falloir agir sur les relations entre les personnes en considérant l’équipe comme un tout, comme un système. Modifier la relation entre deux membres de l’équipe aura des répercutions sur les relations de tous les membres de celle-ci.

Deming dans son expérience des « Red Beads » nous donne un deuxième élément de réponse. L’expérience est la suivante :  dans un bac, mélangez 3200 billes blanches qui représentent les résultats attendus avec 800 billes rouges qui modélisent les défauts.  Convoquez plusieurs personnes dont les rôles sont les suivants :

  • Les employés, au nombre de 6,  dont la tâche est, à l’aide d’une planchette de bois percée, de récupérer 50 billes du bac en s’arrangeant pour avoir le moins de billes rouges possible dans l’échantillon.
  • Les inspecteurs, au nombre de 2, dont la tâche est de compter les billes rouges présentes sur la planchette de bois.
  • L’inspecteur général qui motive et contrôle le travaille des troupes
  • Le scribe ou comptable qui enregistre les résultats et effectue le total des essais des employés.
  • Des actionnaires qui investissent dans l’entreprise.

Faîtes leur alors jouer un jeu de rôle avec un processus très précis de récupération des billes dans le bac en effectuant une certaine pression sur les employés. Les meilleurs employés, qui remontent le minimum de billes rouges, sont récompensés et les moins bons sont licenciés.

Deming reproduit dans cette démonstration, ce qui pourrait se passer à l’échelle d’une entreprise. Parmi les nombreux constats et leçons que nous pouvons retirer de cette expérience :

  • Les performances ne dépendent pas des employés mais du rapport du nombre de billes rouges et blanches. En effet, un employé qui avait de bons résultats peut ensuite avoir des résultats moins bons alors qu’il s’y prend exactement de la même manière pour extraire les billes.
  • Rien ne sert d’essayer de jouer sur la motivation des employés ou encore en agissant sur une cause locale en leur indiquant de manière précise comment récupérer les billes. C’est le système qui impose les résultats obtenus.

Mais surtout,  l’expérience ne dépend pas des personnes choisies pour celle-ci. Et c’est là que cela devient intéressant. En effet, pour pouvoir améliorer la façon de travailler, il faut agir sur le système, de façon globale.

Ce point de vue est aussi partagé par Peter Senge dans la « cinquième discipline« . La cinquième discipline de Peter Senge

Dans les enseignements du jeu de la bière, ce dernier nous indique que la structure influence le comportement : « Des personnes différentes placées dans une même structure tendent à produire des résultats similaires… Plus souvent qu’on ne le croit, ce sont les systèmes qui produisent leurs propres crises, et non les forces extérieures ou des erreurs individuelles. » La structure ici, est une structure systémique; c’est en fait la dynamique de relations au sein d’un groupe et qui influence son comportement. Dans un système, l’effet de vos décisions dépasse les limites de votre propre position, votre succès dépend de tous les acteurs du système. Néanmoins, des petites actions locales peuvent permettre de modifier le système de façon globale. La méthode des petits pas est aussi connue par le concept japonais KAIZEN est la fusion de 2 mots KAI et ZEN qui signifient « changement » et « meilleur ».

Mais pourquoi faire des petits pas et non pas de grands changements ?

  • Parce qu’on se sent moins impuissant à réaliser de petites actions : Face à de petites actions, on se sent moins impuissant et le sentiment d’angoisse lié à l’échec est moindre. On évite les réactions du genre : « C’est trop dur, je n’y arriverai jamais »
  • Parce que ceci génère une satisfaction rapide : il est plus facile de réaliser de petites actions que des actions longues et compliquées. Le résultat associé aux petites actions se voit souvent assez rapidement. Ceci renforce la maîtrise et génère de la satisfaction.
  • Parce qu’on apprend plus vite : les petites actions sont moins coûteuses à mettre en place, le risque associé est donc moindre. Si vous vous trompez sur une action sur laquelle vous avez dépensé peu d’énergie, vous serez davantage disposé à revenir en arrière pour pivoter. Un exemple à l’échelle d’un produit est le MVP (Minimum Viable Product)
  • Parce que les petites actions génèrent moins d’opposition : C’est l’histoire de la grenouille qu’on ébouillante selon Peter Senge : Si on plonge une grenouille dans une marmite d’eau et qu’on augmente petit à petit la température de l’eau, celle-ci s’ébouillantera en restant dans l’eau. A contrario, si vous la plongez dans une marmite bouillante, celle-ci fera tout ce qu’elle peut pour en sortir. En systémique, les petites actions déclencheront à priori des boucles de rétroactions  de type régulateur moins importantes que les grosses. En simplifiant l’explication de ces effets régulateurs, on peut définir ceux-ci comme des actions engendrées par le système et visant à rétablir l’équilibre ; c’est à dire que ces actions auront des effets inverses à celles que vous avez engagées.
  • Parce que les petites actions peuvent faire boule de neige : toujours en systémique, les petites actions peuvent produire un effet d’amplification. Le rapport entre l’énergie dépensée et le résultat sera encore plus important et ceci augmentera encore davantage la satisfaction.

Les boucles de rétroactions de type régulateur (actions contraires) ou amplificateur (boule de neige) peuvent souvent être accompagnées d’un effet retard ; c’est à dire que les effets de celles-ci ne sont visibles qu’après un certain délai. Lorsque vous réalisez des actions de rétrospective, il est parfois bon d’attendre un peu ou de répéter l’action suffisamment avant de tirer des conclusions trop hâtives et de pivoter.

Le Scrum master et les équipes doivent garder en tête que la rétrospective est leur chance de rester acteurs du changement et de faire évoluer le système de manière globale. Ceci est rendu possible grâce à de petites actions et aux mécanismes systémiques de régulation et d’amplification.

Liens et références :

Réduire la dette émotionnelle à Agile France avec Marilyn Kol

Eric LannemajouLaisser un commentaire

IMG_1056

J’étais à Agile France jeudi et vendredi dernier et c’est dans une salle de 25 personnes mais avec à peu près du triple de participants que Marilyn Kol nous a raconté comment gérer la dette émotionnelle d’une équipe Scrum. Selon Marilyn, chaque équipe, en plus de sa dette technique bien connue des développeurs et des Scrum Masters, devrait porter attention à une dette émotionnelle. Si on n’y prend garde, celle-ci pourrait s’amplifier au cours du temps et prendre des proportions ingérables. Cette dette qui tire son origine des conflits (opposition d’idées ou d’opinion réelle ou perçue comme telle entre deux groupes ou deux personnes) et irritants entre les membres d’une équipe, peut déraper jusqu’à atteindre le niveau 5 irrémédiable de « la guerre mondiale » où tous les membres de l’équipe sont en guerre. Mais il existe des solutions pour empêcher que le climat à l’intérieur d’une équipe ne se dégrade à ce point et Marilyn, forte de son expérience professionnelle, nous a prodigué quelques conseils.

Parmi ceux-ci, le premier est de reconnaître et d’assumer les problèmes. Ceux-ci peuvent, dans un premier temps, s’exprimer à travers le langage corporel des différents protagonistes lors des rituels Scrum et notamment lors du daily scrum. Vous pouvez identifier les signaux non verbaux à condition que vous soyez à minima empathique; que vous puissiez lire et détecter les émotions des personnes sans que celles-ci n’affecte les vôtres. Une fois le problème rendu visible vous pourrez essayer de résoudre collectivement celui-ci.

Afin de mieux cerner le problème, et dans le cas où celui-ci relève d’après vos hypothèses d’un malentendu ou de difficultés de communication, vous pouvez utiliser ou proposer l’écoute active; celle-ci consiste à écouter l’autre pour le comprendre et non pour essayer de lui répondre. Ensuite, vous pourrez reformuler afin de vous assurer de la problématique ou encore questionner les antagonistes avec la technique des 5 pourquoi afin de trouver les causes racines. Si vous pensez que vous avez plutôt à faire à une divergence d’opinion, de point de vue ou si le problème concerne des émotions, voici ci-dessous quelques outils qui vous seront fort utiles.

Afin de désamorcer un conflit, vous pouvez inviter les membres de votre équipe (si vous êtes Scrum Master) à se servir de la communication non violente (CNV).  Celle-ci détaille un protocole de communication en 4 étapes :

2018-06-15 22_43_41-Amazon.fr - Les mots sont des fenêtres (ou bien ce sont des murs) - Marshall B.

  • O pour observation, on relate les faits
  • S pour exprimer ses sentiments vis-à-vis de ces faits
  • B pour exprimer ses besoins
  • D pour formuler une demande

Vous pourrez retrouver plusieurs mises en situation dans le livre de Marshall Rosenberg; les mots sont des fenêtres (ou bien ce sont des murs).   Selon Marilyn, les personnes ont souvent du mal à utiliser ce protocole au début. Aussi n’hésitez pas à insister, parfois lourdement, en montrant l’exemple dès que possible (« lead by example »…). Afin de rendre votre intervention encore plus efficace, vous pouvez remplacer les questions en « pourquoi » par des questions en « en quoi ». Par exemple, au lieu de demander : « Pourquoi es-tu en retard au daily Scrum ? », vous pourriez reformuler par « En quoi est-ce difficile pour toi de venir à l’heure au daily Scrum ? ». Enfin, si vous sentez que quelqu’un est en retrait ou fait la moue à la sortie d’une réunion, vous pouvez, par exemple, utiliser quelques soupçons de psychologie positive : « C’est cool, la réunion a bien remotivé l’équipe! »

Dernier chapitre de la présentation. Marilyn nous a partagé quelques outils afin d’améliorer la communication d’une équipe et permettre à ses membres de mieux se comprendre :

  • L’atelier sur les valeurs : chaque personne va définir individuellement ses valeurs, partager aux autres leur signification ainsi que leur réaction si cette valeur était trahie. Puis, les valeurs communes vont être regroupées afin de former celles de l’équipe.

J’ai facilité un atelier de team building il n’y a pas très longtemps où j’ai fait construire à l’équipe un poster avec les valeurs. Je trouve intéressant dans l’atelier ci-dessus, que chacun exprime le sens qu’il donne aux mots et partage les limites qu’il ne souhaite pas voir dépassées. Marilyn nous indique que cet atelier peut être donné lors de la construction de l’équipe ou lors de l’arrivée d’un nouveau membre.  Selon elle, cet événement génère une nouvelle équipe.

Vous pouvez retrouver les différents stades de formation d’une équipe dans le modèle de Tuckman (article que je vous ai récemment partagé sur LinkedIn).

  • L’atelier sur les moving motivators issus du Management 3.0 et qui permettent d’identifier les facteurs intrinsèques de motivation; c’est-à-dire ceux qui apportent du plaisir par eux même.
  • La rétrospective Lego ou chaque personne doit construire sa manière de travailler privilégiée; seul ou en équipe ? Introverti ou extraverti ? Attention, un introverti n’est pas quelqu’un qui n’aime pas les gens mais qui puise son énergie lorsqu’il est seul.
  • Le MBTI qui permet de définir les personnalités selon 4 axes :
    • comment te ressources-tu ?
    • comment prends-tu tes décisions ?
    • comment recueilles-tu les infos ?
    • comment gères-tu le monde extérieur ?
  • IMG_1068[1]La rétrospective Empathy Map 
  • La rétrospective « Turn the table » afin de démontrer aux différents membres d’une équipe qu’ils se connaissent mieux qu’ils ne le pensent et qu’ils sont plus empathiques qu’ils ne le croient.

Pour les 5 dernières minutes, Marilyn a rapidement abordé les schéma ci-contre pour nous expliquer qu’il faut souvent creuser plus profondément que les comportements pour comprendre une situation.

La qualité de la mise en forme, le storytelling et l’énergie de Marilyn nous a tenu en haleine pendant toute la session.  L’ovation finale de la salle était amplement méritée.

 

 

Liens et Références

Qu’est-ce qu’un Scrum Master ? (Agile en Seine 2017)

Eric LannemajouLaisser un commentaire

Voici un retour un peu tardif sur les conférences de Agile en Seine du 20 septembre 2017 et notamment sur la présentation de Romain Couturier sur « Qu’est-ce qu’un Scrum Master ?« . J’ai réalisé un petit dessin qui centralise ce que j’ai retenu et je l’ai publié sur linkedIn dans un POST. Mais comme il est parfois difficile de retrouver les informations dans le flux dense du réseau social, je republie ce dernier ci-dessous 😉

20170920-scrummaster

Je vous propose aussi de pouvoir approfondir le sujet avec l’article de Jean Claude GrosJean, « Le ScrumMaster n’est pas un Coach Agile« 

 

L’estimation et la planification agile

Eric Lannemajou1 commentaire

L’une des valeurs du manifeste Agile est de favoriser l’adaptation par rapport à un plan établi. Cette valeur est parfois mal interprétée et ne signifie pas qu’il ne faut pas planifier. Mike Cohn nous explique dans Agile Estimating and Planning les raisons pour lesquelles il est nécessaire pour une équipe Agile de planifier.51I7-xMCQDL._SX408_BO1,204,203,200_

Dans mon expérience, j’ai rencontré plusieurs équipes qui se demandaient comment il fallait planifier et surtout comment estimer les stories. Faut-il estimer en point, en jours idéaux, avec la suite de Fibonnaci ? L’estimation du travail est souvent source de tension ou de conflit entre l’équipe de développement et les commanditaires du projet ou encore avec le Product Owner. Mais avant de se poser la question du « comment? », j’invite les équipes à revenir sur le « pourquoi? ». Pourquoi estimer ? A quoi et à qui cela sert ?

Mike Cohn nous explique ces raisons dans Agile Estimating and Planning. Un plan doit permettre de :

  • guider les décisions des investissements à réaliser.
  • savoir si un projet est sur le point de livrer des fonctionnalités que les utilisateurs attendent.
  • connaître le nombre de ressources disponibles pour travailler sur ce projet pendant une période définie.

Planifier est souvent difficile et les équipes peuvent tomber dans les deux extrêmes de ne pas planifier du tout ou de trop planifier. Planifier est une activité difficile et le cône d’incertitude ci-dessous nous démontre combien il est difficile d’estimer le projet dans les premières phases de ce dernier. A la définition du projet, l’incertitude est de 60% et il faut attendre le design détaillé pour réduire cette incertitude à 10%. Ce qui explique donc que plus de 2/3 des projets dépassent le coût estimé initialement.

coneOfUncertainty

Mais alors si cela est si difficile de planifier un projet, pourquoi effectuer cette activité ? Et bien tout d’abord pour :

  • réduire le risque : les discussions qui servent à estimer le projet permettent de mettre en lumière les potentiels risques du projet.
  • réduire l’incertitude : un des risques les plus importants d’un projet n’est pas de ne pas sortir dans les temps mais bien de développer des fonctionnalités qui ne répondent pas aux besoins des utilisateurs. Ce risque peut être atténué via une planification agile continue qui permet de récupérer les retours utilisateurs au fur et à mesure du projet.
  • aider à prendre de meilleures décisions : l’estimation du coût d’un projet et de sa valeur métier nous permet de décider si le projet doit être lancé.
  • établir la confiance :  les fréquentes livraisons de fonctionnalités permettent d’établir la confiance entre le client et les développeurs. Les estimations deviennent de plus en plus fiables au cours des itérations et permettent de prioriser les fonctionnalités en se basant sur l’estimation fiable de l’équipe de développement.
  • transmettre de l’information : un plan ne garantit pas la livraison d’un périmètre à une date précise mais permet néanmoins de fixer un niveau d’attente et l’approche pour arriver à satisfaire cette attente.

Maintenant que nous savons à quoi sert la planification et l’estimation agile, nous pouvons insister sur le « comment ». Certaines équipes estiment leurs stories en point de complexité/d’effort alors que d’autres les estiment en jours idéaux. Les jours idéaux sont des jours où chaque membre de l’équipe consacrerait 100% de son temps de travail dans la journée à la story sans être dérangé par d’autres activités professionnelles.

Les partisans du chiffrage en points mettent en avant que ce type de chiffrage :

  • permet aux équipe multi-fonctionnelles de pouvoir avoir une mesure commune.
  • est constant dans le temps, ne dépend pas du niveau de capacité ou de compétence de la personne qui va réaliser la story.
  • est une pure mesure de taille et ceci permet donc de pouvoir chiffrer par analogie, de manière relative. De plus, comme cette mesure est complétement abstraite, les équipes ne devraient pas être tentées de comparer cette estimation avec du temps passé.
  • est plus rapide grâce notamment à la possibilité de comparer de manière relative par analogie avec des stories de référence.

Enfin, les jours idéaux varient d’une personne à une autre. Cependant,  il est plus facile d’expliquer un chiffrage en jours idéaux aux personnes extérieures à l’équipe et pour une équipe qui débute, ce mode de chiffrage est plus facile à appréhender.

L’action de planification pour une équipe agile s’effectue à plusieurs horizons et plusieurs niveaux d’abstraction. L’action de planifier revient à se fixer des objectifs sur une période donnée et à les réviser tout en décalant des objectifs plus long terme. Pour une équipe qui travaille en SCRUM, l’équipe va fixer un objectif de release avant le premier sprint et réviser ce dernier au fur et à mesure des sprints. En effet, la release va être initialement estimée et planifiée puis revue à la fin de chaque itération pour évaluer comment le périmètre associé à la date évolue. L’action ici sur le périmètre du sprint a une influence sur le périmètre de la release. On parle ici de planification en couches successives ou en oignon.

Le dernier point détaillé par Mike Cohn que je souhaiterais partager est celui du niveau de détail de l’estimation et de la planification. A quel moment et niveau de détail faut-il arrêter de planifier ? Cette question peut aussi se poser dans un projet en cycle en V et j’ai déjà par le passé fait l’amère expérience de trop planifier un projet. Ce problème se présente par le fait de planifier de toutes petites tâches et donc de planifier tout le temps. Planifier devient alors l’activité principale et l’information portée par ce niveau de détail n’apporte pas assez de plus-value au projet. Mike Cohn nous explique ce travers avec le petit exemple suivant : « si vous vous demandez combien de cookies j’ai mangés l’an dernier, vous avez plusieurs options pour répondre à cette question :

  • Estimer le nombre de cookies au hasard
  • Demander à mes proches, mes amis, ma famille
  • me suivre pendant une journée, compter combien je mange de cookies et extrapoler sur un an.

Cependant, si votre but est de savoir si vous pouvez m’offrir ou non, une boîte de cookies, alors vous n’avez pas besoin d’avoir une mesure ultra précise et il n’est donc pas nécessaire d’effectuer trop de recherches. Dans ce cas précis, la première solution pourra convenir. Quand on planifie, il faut donc toujours se demander dans quel but afin d’évaluer le niveau d’effort et de détail que nécessite cette planification.

Je vais vous décrire une situation que j’ai déjà rencontrée et qui peut s’avérer être un parfait exemple d’une planification peu « agile ». Lors d’un projet avec un centre de service, j’ai travaillé avec une équipe qui chiffrait les stories en points en utilisant la suite de Fibonnaci. L’équipe n’était pas dédiée et le nombre de point d’une story, convertie par un coefficient donnait directement le nombre de jours et donc le coût de la story. L’équipe allouait un nombre/capacité de points différent à chaque itération qui représentait donc directement le nombre de jours pendant lesquels l’équipe allait travailler sur le produit. Cette situation peut aboutir à plusieurs effets pervers :

  • Comme l’équipe estime une capacité ou un coût de story fixe et que celui-ci représente le nombre de jours de travail sur la fonctionnalité, il n’est plus possible de lisser entre les stories d’un même sprint.
  • Comme l’équipe estime avec la suite de Fibonnaci et que les stories sont directement converties en jours/homme, une story légèrement supérieure à 8 passe à 13, ce qui n’est pas du tout le même coût : le commanditaire se sent lésé.
  • Comme les développeurs estiment chaque story et prennent un engagement sur chacune d’elles, ceux-ci ont tendance à se protéger et réhausser leur chiffrage.
  • Comme l’équipe n’est pas dédiée et que la capacité change à chaque itération, on perd la possibilité d’apprendre au cours des sprints.
  • Le fait de ne pas estimer de release et de changer la capacité à chaque itération supprime toute possibilité de planification.

Cette situation aboutit donc à une forte tension entre le commanditaire et l’équipe de développement. Sans compter que ceci rajoute aussi de la pression sur les développeurs qui doivent prendre un engagement à la story. Ce pattern qui favorise un rapport contractuel et impose une facturation à la story est selon moi anti-agile.

Liens et Références :

MVP et Design Sprints

Eric Lannemajou4 commentaires

Aujourd’hui, je voudrai vous parler de MVP; Minimum Viable Product (ou Produit Minimum Viable en français). On en entend souvent parler autour de nous et notamment lorsqu’un projet débute. Le MVP permettrait au Responsable de Produit (PO) d’apporter le maximum de valeur métier à ses utilisateurs en un minimum d’effort de la part de l’équipe qui réalise le produit ; effort souvent limité aux premiers sprints. De nombreuses Entreprises de services numériques (ESN) proposent donc d’échelonner leurs réalisations suivant ce MVP.

Mais qu’est-ce que le MVP ? Wikipedia n’est pas très loquace sur le sujet : « stratégie de développement de produit, utilisée pour de rapides et quantitatifs tests de mise sur le marché d’un produit ou d’une fonctionnalité » et nous renvoie notamment vers Eric Ries auteur de  The Lean Startup. Pour simplifier, le Processus du Lean Startup se base sur les trois composantes suivantes :

  • Build qui est l’étape de la construction methodology_diagramdu produit ou de la fonctionnalité
  • Measure qui est l’étape ou on mesure la plus-value de la fonctionnalité ou du produit construit à l’aide de métriques.
  • Learn qui est l’étape où on apprend auprès des utilisateurs et où on récupère leur feedback sur l’utilisation du produit ou de la fonctionnalité.

Le MVP est donc un outil ou une stratégie qui permet de mesurer la pertinence d’un produit ou d’une fonctionnalité auprès des utilisateurs concernés sans avoir pour autant besoin de construire ces derniers. Alexander Cowan dans son cours Running Product Design Sprints, nous explique que le MVP est utilisé pour tester la motivation des utilisateurs pour une fonctionnalité et valider des hypothèses concernant la plus-value métier de cette dernière. Les différents outils ou véhicules qu’il propose sont les suivants :

  • Sales vehicle :  technique qui consiste à vendre la fonctionnalité ou le produit. Il n’y a pas d’interaction entre les utilisateurs et la fonctionnalité ou le produit. Cette technique peut se matérialiser par un envoi de mail aux utilisateurs, par une page de publicité sur un site, par un sondage, un formulaire…
  • Wizard of Oz vehicle : technique qui consiste à présenter le produit/fonctionnalité ou du moins une interface qui va simuler le fonctionnement du produit ou la fonctionnalité. Cette technique peut se matérialiser par une démonstration, une présentation animée, un webinar ou encore une vidéo…
  • Concierge vehicle : technique qui consiste dans le fait de fournir la fonctionnalité à l’utilisateur, même si cette fonctionnalité est offerte manuellement. Cette technique ne nécessite pas forcément la construction du produit ou de la fonctionnalité finale.

Ces 3 techniques peuvent être combinées afin de valider les hypothèses de plus-value  formulées pour résoudre les problèmes utilisateurs et de nombreuses entreprises les ont utilisées avant d’investir des fonds dans la construction de leur produit ou des fonctionnalités.

Voici quelques exemples décrits dans le cours Running Product Design Sprints :

  • Les créateurs de DROPBOX ont commencé en publiant une démo sur YouTube puis en intégrant cette vidéo dans une page web avec un formulaire  pour récupérer des signatures : on reconnaît ici une combinaison Wizard of Oz et Sales.
  • Le créateur de ZAPPOS, le site de vente de chaussures online, Nick Swinmurn a commencé en prenant une photographie d’une paire de chaussures  et en la postant sur un site web pour savoir si des personnes achèteraient cette paire de chaussures. Une fois que les clients ont acheté la paire de chaussures, ils ont pu recevoir celle-ci à leur domicile. Le MVP utilisé  est le Concierge.
  • SPRIG est une entreprise de préparation et de livraison de plats préparés. Les créateurs se sont organisés dans une cuisine temporaire pour préparer des plats. Ils ont envoyé des mails à leurs amis et ont ensuite vendu les plats grâce au site EventBrite. Ils ont pu ainsi mesurer le succès de leur idée. Nous sommes ici dans un cas de Concierge puisque les utilisateurs ont pu expérimenter le service.

On peut trouver de nombreux autres exemples sur le net : Twitter, Groupon…Mais le but d’un MVP est d’apprendre et de valider des hypothèses sur les utilisateurs et selon Alexander Cowan, le Concierge MVP est celui qui permet d’en savoir le plus. Les habitudes des utilisateurs peuvent être mesurées sur le produit grâce à des tags et des indicateurs…Des interviews peuvent aussi compléter ces données.

Pour revenir au début de l’article, je ne suis pas certain qu’on puisse vraiment parler de MVP dans le cas où on construit un produit mais où on ne valide aucune hypothèse sur les utilisateurs. Le but du MVP, ne l’oublions pas, est de valider la pertinence du service proposé aux utilisateurs, en un minimum de temps et d’investissement.

Liens et Références