Équipes agiles, conflits et Thomas-Kilmann Conflict Mode Instrument (TKI).

Dans le monde de l’agilité, les conflits font naturellement partie du parcours de l’équipe vers l’innovation et l’efficacité.

Agile Teams, Conflicts, and TKI de Zuzi Sochova

https://agile-scrum.com/2025/10/01/agile-teams-conflicts-and-tki/

Lorsque les équipes se réunissent pour travailler vers un objectif commun, elles ont forcément des idées et des opinions différentes. La facilitation est un excellent outil pour aider à naviguer dans des conflits sains. C’est l’une des raisons pour lesquelles il est toujours utile d’avoir un ScrumMaster. J’ai déjà écrit à ce sujet de nombreuses fois. Cette fois, je veux vous présenter un outil qui n’est pas si courant, mais qui est très utile à avoir dans votre boîte à outils ScrumMaster. Thomas-Kilmann Conflict Mode Instrument (TKI) est un outil qui aide les gens à comprendre comment ils managent les conflits et à garder leurs équipes productives et heureuses.

5 modes différents de gestion des conflits.

Compétition

Le mode Compétition se situe dans le quadrant assertif et non coopératif. Prendre des décisions importantes sans l’accord de l’équipe peut nuire à la confiance et causer des problèmes. Par exemple, un Product Owner effectue des changements soudains sans en parler à l’équipe, ce qui entraîne de la colère et des problèmes de qualité. Ou un membre de l’équipe pousse ses idées sans écouter les autres, ce qui interrompt le travail et crée des tensions. D’un autre côté, il n’y a pas de mal à prendre des décisions rapides quand vous en avez vraiment besoin. Par exemple, un Scrum Master peut rapidement arrêter une discussion pour s’assurer que l’équipe atteint un objectif, ou un développeur peut dire que la sécurité est importante, même si d’autres sont plus axés sur la rapidité.

Collaboration

Le mode Collaboratif se situe dans le quadrant assertif et coopératif. Essayer de mettre tout le monde d’accord peut ralentir les choses et rendre les équipes moins efficaces. Par exemple, si vous passez trop de temps à faire du brainstorming et à essayer de plaire à tout le monde, cela peut retarder les décisions et provoquer une condition appelée « paralysie de l’analyse ». Ou, si vous essayez d’inclure les opinions de chacun, cela peut élargir la portée du projet au-delà de ce qui est réellement nécessaire. D’un autre côté, ce mode est idéal pour rassembler différentes perspectives et établir un consensus lorsqu’une équipe travaille ensemble pour s’assurer que les décisions techniques s’alignent sur les objectifs de l’entreprise. Cela peut améliorer la livraison du produit et la satisfaction des clients, ou lorsque les développeurs et le Product Owner collaborent pour s’assurer que les user stories sont claires et correctement hiérarchisées.

Compromis

Le mode Compromis est intermédiaire dans les quadrants de l’assertivité et de la coopération. Accepter des solutions partielles peut conduire à des opportunités manquées d’obtenir les meilleurs résultats. Par exemple, lorsque l’équipe se met d’accord sur une solution qui satisfait partiellement tout le monde mais ne répond pas pleinement aux besoins techniques ou business importants, ou lorsque l’équipe sacrifie la couverture des tests pour atteindre un objectif de délai de sprint, ce qui entraîne des corrections ultérieures et une dette technique. Cependant, il peut être utile pour parvenir à des règlements temporaires, comme la négociation d’un ensemble de fonctionnalités minimum viable avec les parties prenantes pour respecter les délais de livraison ou le partage du temps entre la refactorisation et la livraison de nouvelles fonctionnalités pour équilibrer la santé technique et la création de valeur.

Évitement

Le mode évitement se situe dans le quadrant non assertif et non coopératif. Ignorer les problèmes récurrents peut aggraver les choses et nuire à la qualité de la collaboration de l’équipe. Par exemple, si l’équipe continue d’ignorer les mêmes problèmes, cela peut entraîner une dette technique ou si un Scrum Master évite de gérer les conflits, l’équipe peut continuer à rester bloquée. Mais il y a des moments où il est acceptable d’ignorer les petits problèmes ou lorsque les autres membres de l’équipe sont mieux placés pour gérer certains conflits. Par exemple, s’il y a un débat sur un processus non essentiel qui peut attendre la rétrospective, ou si un développeur doté d’une expertise approfondie peut gérer un désaccord technique mineur sans impliquer toute l’équipe.

Serviabilité

Enfin, le mode serviable se situe dans le quadrant non assertif et coopératif. Essayer de trop plaire à tout le monde peut conduire à oublier des choses importantes comme les besoins techniques et de livraison. Par exemple, si un développeur continue d’accepter des délais impossibles pour satisfaire tout le monde, cela peut provoquer un épuisement professionnel, ou bien l’équipe fait toujours passer les exigences des parties prenantes en premier, même si cela signifie ignorer la dette technique. D’un autre côté, il est parfois bon de garder l’harmonie et les relations au premier plan. Par exemple, accepter de petites demandes de fonctionnalités pour créer de la bonne volonté avec les parties prenantes ou lorsqu’un développeur senior laisse un membre de l’équipe junior diriger une tâche pour qu’il puisse acquérir de l’expérience.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Les équipes agiles sont axées sur le travail d’équipe, et il est important que tout le monde sache comment il gère habituellement les conflits et comment le fait de s’orienter vers différents modes peut changer la dynamique de l’équipe. Par exemple, si vous avez un ScrumMaster qui est très fort en matière d’évitement et de serviabilité, il se peut qu’il ignore des problèmes de l’équipe, qu’il ne parvienne pas à éliminer les obstacles et qu’il compromette les principes agiles pour satisfaire tout le monde pendant un certain temps. En un mot, il n’aide pas vraiment l’équipe et les organisations à changer.

Les excellents ScrumMasters doivent avoir un profil équilibré avec un niveau de collaboration élevé pour intégrer les idées de l’équipe et favoriser le consensus, et une appétence modérée de la concurrence et du compromis pour protéger l’équipe, maintenir des principes agiles et gérer efficacement les équilibres.

Dans la vraie vie, les gens possèdent un mélange de tendances. Par exemple, imaginez que vous avez un Product Owner qui est très fort en matière de collaboration et d’adaptation. Il coopérera bien avec les clients et établira d’excellentes relations, ce qui est génial, mais en même temps, il essaie de rendre tout le monde heureux et ne peut pas définir une direction claire ou prendre une décision pourtant nécessaire.

Alors, par où commencer ?

Encouragez les membres de l’équipe à passer l’évaluation TKI pour mieux comprendre leurs styles de conflit par défaut. Comprendre ses tendances naturelles peut aider les individus à choisir consciemment l’approche la plus efficace dans diverses situations.

J’anime généralement des ateliers pour discuter des cinq modes de gestion des conflits et explorer les scénarios où chaque mode pourrait être le plus efficace. L’utilisation de jeux de rôles aide les membres de l’équipe à s’entraîner à changer de mode et à comprendre les points de vue des autres.

Les grands Scrum Masters sont d’une grande aide. Ils sont doués pour reconnaître les modes de conflit et sont capables d’aider les équipes à trouver la façon la plus constructive de manager les conflits. Ils incitent les individus à réfléchir sur leurs tendances et les aident à créer un meilleur équilibre. Ce sont eux qui s’assurent que tout le monde se sent en sécurité pour partager ses pensées, et ils interviennent lorsque les choses commencent à devenir trop animées.

Apprenez-en davantage sur la transformation des organisations, du leadership et de la culture avec Agile & Enterprise Coaching. Consultez les sessions de formation Scrum et Agile sur Sochova.com. Procurez-vous un exemplaire de The Great ScrumMaster : #ScrumMasterWay et The Agile Leader : Leveraging the Power of Influence.

« Le Recovery d’un Projet : Comment Redresser un Projet en Dérive » par Ophélie GOMES

« Le projet a deux ans de retard et accumule une perte de 2 M€. Peux-tu voir ce que tu peux faire? »

Voici comment on m’a demandé pour la première fois de reprendre un projet. J’avais 2 ans d’expérience, autant dire que la pression était immense.

8 mois plus tard, l’équipe livrait le projet en production avec les remerciements du client.

Depuis, j’ai enchaîné les reprises de projets en difficulté. Et j’ai compris une chose : le PMI ne propose pas de « procédure officielle » de recovery. Il donne des bonnes pratiques pour mesurer la dérive et mener un plan d’action, mais quand tout devient trop complexe, un changement de manager de projet devient inévitable et la nécessité d’une approche spécifique.

Dans cet article, je partage les 3 conseils essentiels qui m’ont permis de réussir ces missions impossibles.

Conseil n°1 : Soyez une « Plante Verte » – Observer Sans Intervenir

La première erreur à ne pas commettre est de vouloir agir immédiatement. Certes, la situation est urgente, mais il faut prendre le temps de la compréhension et de l’observation. De plus, arriver avec « ses gros sabots » peut rendre l’équipe réticente à votre arrivée.

La phase « plante verte » consiste à observer avant d’agir tout en mesurant l’ampleur de la dérive.

Comment procéder ?

Restez en retrait : Assistez aux réunions, aux daily meetings, aux ateliers, mais ne prenez pas immédiatement les commandes.

Regardez l’équipe travailler : Observez les interactions, les dynamiques de groupe, les processus en place.

Avec le client, optez pour des réponses en deux temps : « Je prends note, je reviens vers vous » ou « Je vais creuser ce point ». Ces réponses vous protègent car votre interlocuteur tentera certainement de vous faire aller dans son sens.

Taisez-vous et ne jugez pas : Ce n’est pas le moment de critiquer ce qui a été fait. Vous n’étiez pas là, vous ne connaissez pas le contexte complet.

En parallèle, récupérez les informations sur la dérive : Budget, planning, périmètre, qualité. Construisez vos KPI de suivi dès maintenant.

Pourquoi cette phase est cruciale ?

Parce que ce sont ceux qui font qui savent. L’équipe qui a vécu le projet depuis le début possède une connaissance terrain que vous n’aurez jamais en lisant des rapports de suivi.

Cette phase d’observation vous permettra de :

  • Identifier les vrais problèmes (qui sont souvent différents de ceux qu’on vous a présentés)
  • Comprendre la dynamique de l’équipe
  • Gagner la confiance de l’équipe en montrant que vous ne débarquez pas en « redresseur de tort »

Combien de temps ? Entre 2 et 4 semaines selon la taille du projet. Ne vous précipitez pas, cette phase conditionne toute la suite.

Conseil n°2 : Crever l’Abcès – Rétrospective et Transparence

Il m’est arrivé d’intervenir sur un projet en difficulté sans que l’équipe ne le sache vraiment. L’équipe observait les tensions mais sans vraiment en mesurer l’ampleur.

La rétrospective est le bon moment pour crever l’abcès.

Vous avez observé, donc vous avez pu constater les dysfonctionnements. Vous avez peut-être même des idées de résolution (à ce stade, gardez-les pour vous). Vous avez également des mesures concrètes sur la dérive du projet. C’est le moment de la rétrospective.

Déroulement de la rétrospective en 3 étapes

 Étape 1 : Partagez les KPI

C’est une excellente introduction. Présentez factuellement où en est le projet : budget consommé, retard accumulé, dette technique, satisfaction client. Pas de jugement, juste des faits.

Étape 2 : Faites la rétrospective

De la plus classique (« Ce que l’on fait bien », « Ce que l’on veut arrêter », « Ce que l’on veut essayer », « Ce que l’on veut changer ») à la plus ciblée (diagramme d’Ishikawa pour identifier les causes racines).

Étape 3 : Debrief et confrontation douce

C’est le moment d’ajouter vos observations : « J’ai remarqué cela, je ne le vois pas sur le tableau, qu’en pensez-vous ? ». Cette approche non accusatrice permet de faire émerger les non-dits.

En sortie de rétrospective, vous aurez :

  • Une équipe consciente du problème et de son ampleur
  • Une vision complète du projet et de ce qu’il faut faire

Une fois cela fait, vous pouvez enchaîner sur le classique : « Plan, Do, Check, Act ».

Conseil n°3 : N’hésitez pas à Bousculer les Codes

Pendant mes recovery projets, j’ai pris des décisions radicales :

Supprimer tout un pan de l’application pour la reconstruire : 1,5 an de travail jeté à la poubelle. Pourquoi ? La dette technique était telle qu’il était plus rapide de reconstruire sur des bases saines que de corriger l’existant.

Supprimer toutes les spécifications pour repartir en mode agile : L’équipe perdait plus de temps à comprendre des documentations de 200 pages plutôt que de poser la question au client en direct.

Diminuer mon équipe alors qu’on me conseillait de l’augmenter pour aller plus vite : Trop de personnes = trop de coordination = perte d’efficacité. J’avais besoin d’une équipe restreinte.

Le paradoxe du recovery

C’est le plus gros avantage en recovery projet : Vous avez souvent les mains libres. Les clients et les directions veulent du changement, ils ont conscience que la situation ne peut pas empirer. Profitez-en pour proposer des approches audacieuses.

En Résumé : Les 3 Clés du Recovery

🌱 1. La phase « Plante Verte »

Observer sans intervenir pendant 2-4 semaines. Mesurer la dérive. Gagner la confiance.

🔍 2. Rétrospective et transparence

Crever l’abcès. Partager les KPI. Identifier collectivement les causes et les actions.

⚡ 3. Innover

Oser les décisions radicales. Profiter de la liberté du recovery.

Et vous, avez-vous déjà repris un projet en dérive ? Quelle a été votre première action ? Quelles leçons en avez-vous tirées ?

 Partagez votre expérience en commentaire. 👇


Ophélie GOMES

Ophélie GOMES

Je suis issue d’une filière technologique : Diplômée MIAGe à Lyon en 2002. J’ai commencé ma carrière dans une Entreprise de Services du Numérique (ESN) en tant que développeuse Java en mars 2003 tout en continuant en parallèle une thèse en Business Intelligence que j’ai soutenue en 2010.

J’ai occupé différentes fonctions dans l’IT pendant 15 ans chez Capgemini à Grenoble: Business Analyst, Chef de projet run, chef de projet build dans différentes technologies (java, SAP, Documentum, .Net) et différents secteurs (Services privés, Énergies, secteur public, industrie), directrice d’entité puis directrice régionale infrastructure. Depuis deux ans, je suis directrice des études et du digital chez Europ Assistance. En plus de mon rôle de manager, je suis coach agile certifiée SPC – Implementing SAFE et je donne des cours de gestion de projet.

Ami(e)s Agilistes, connaissez-vous The Scrum Alliance Resource Library ?

Cette bibliothèque de connaissances (Articles, documents, vidéos, formations sur Agile et plus particulièrement Scrum) a été récemment améliorée en se basant bien sûr sur les retours de ses utilisateurs.

Visitez The Scrum Alliance Resource Library.


Un design audacieux et épuré
qui facilite l’exploration et la découverte d’articles, de vidéos et d’autres ressources. Vous bénéficierez toujours des mêmes caractéristiques et fonctionnalités qu’auparavant, mais avec une apparence considérablement améliorée.

Des balises (tags) intuitives en haut pour que vous puissiez filtrer instantanément par articles, vidéos, webinaires, communiqués de presse ou collections, ou afficher tous les types de ressources.

Des filtres thématiques sur la gauche de l’écran pour une recherche ciblée. Vous pouvez sélectionner un ou plusieurs de ces filtres en fonction de ce qui vous intéresse à explorer.

Une barre de recherche simple pour trouver des ressources par mot(s) clé(s) ou titre complet.

Copyright © 2025 Scrum Alliance Inc.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

 

« Scrum Master en tant que coach, formateur et mentor » par Sam Adesoga

3 postures constituent le socle d’un Scrum Master efficace : Coach, Formateur et Mentor.

Scrum Master as a Coach, Teacher and Mentor par Sam Adesoga

https://samadesoga.me/posts/scrum-master-as-a-coach-teacher-mentor/

Barry Overeem, dans son article sur les 8 postures d’un Scrum Master, décrit le Scrum Master comme un coach, un formateur, un mentor, un facilitateur, un agent de changement, un éliminateur d’obstacles, un manager et un leader serviteur.

Bien que ces huit postures soient précieuses, trois d’entre elles constituent le socle d’un Scrum Master efficace : Coach, Formateur et Mentor. Ces rôles sont souvent combinés, mais chacun a un objectif distinct pour aider les équipes à se développer et à prospérer.

Le Scrum Master en tant que coach.

Le coaching consiste à libérer le potentiel de l’équipe, et non à fournir toutes les réponses. Un Scrum Master en tant que coach doit développer sa patience, ses capacités d’écoute et sa capacité à guider sans diriger.

Ce que cela donne au quotidien.

  • Écoute activement et patiemment.
  • Aborde le coaching avec la conviction que l’équipe a déjà les réponses.
  • Guide systématiquement sans intervenir pour faire le travail.
  • Apporte une perspective holistique dans les conversations.
  • Comprend que les changements significatifs sont graduels et nécessitent plus que des processus documentés.

Les compétences de coaching ne se construisent pas du jour au lendemain. Elles nécessitent de la pratique, de la réflexion et des années de perfectionnement. L’expérience en leadership aide, mais l’essence du coaching est la confiance, c’est-à-dire permettre aux équipes de trouver leurs propres réponses.

Le Scrum Master en tant que formateur.

Sans expérience pertinente, il est difficile pour un Scrum Master d’enseigner efficacement. La formation implique le transfert de connaissances, parfois sur Scrum lui-même, d’autres fois plus largement sur les pratiques de produit et de développement.

Ce que cela donne au quotidien.

  • Enseigne aux équipes les événements Scrum, les valeurs et autres pratiques agiles.
  • Guide les Product Owners dans les techniques de management de produit comme le backlog slicing.
  • Initie les développeurs à des pratiques collaboratives telles que mob programming ou le TDD.
  • Soutient les testeurs en leur montrant des moyens de mieux collaborer avec les développeurs.

Ici, l’expérience compte. Un Scrum Master qui a travaillé dans des organisations de produits peut enseigner avec crédibilité et une perspicacité pratique, rendant les concepts abstraits plus concrets.

Le Scrum Master comme mentor.

Alors que la formation consiste à transférer des connaissances, le mentorat va plus loin : Il consiste à accompagner l’apprenant. Contrairement au coaching, où le Scrum Master pose principalement des questions, le mentorat consiste souvent à partager des conseils, des expériences et même à modéliser les bonnes pratiques.

Ce que cela donne au quotidien.

  • Aide les membres de l’équipe à devenir de meilleurs animateurs d’événements Scrum.
  • Guide les individus pour résoudre leurs propres obstacles.
  • Offre des conseils et une perspective aux équipes qui naviguent entre les différentes options.

Le mentorat accélère la croissance parce qu’il fournit à la fois des connaissances et des exemples vécus. Il dit : « Voici comment je l’ai fait – maintenant, essayons-le ensemble. »

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Pourquoi ces postures sont importantes.

Les Scrum Masters qui manquent de compétences en matière de coaching, de formation et de mentorat ont souvent du mal à avoir un impact. C’est pourquoi j’encourage les nouveaux Scrum Masters à acquérir de l’expérience dans d’autres rôles au sein d’une équipe Scrum avant d’entrer dans ce rôle. Une exposition plus large vous fournit des informations pour coacher avec empathie, enseigner avec autorité et mentorer avec confiance.

Bien sûr, aucun Scrum Master n’est un expert en tout. Il y a des moments où il est logique de s’associer à d’autres pour combler vos lacunes en matière de compétences. Par exemple, j’ai une formation en développement, mais je m’appuie sur des développeurs ou des architectes seniors lorsque l’équipe a besoin d’une expertise approfondie en conception de logiciels. Cette collaboration ne diminue pas le rôle du Scrum Master, mais l’améliore en veillant à ce que l’équipe reçoive les bons conseils.

Réflexions finales.

Être un Scrum Master n’est pas une question de titres ou de cérémonies. Il s’agit de permettre aux personnes et aux équipes de se développer. Le coaching permet à l’équipe d’être une meilleure version d’elle-même, la formation fournit de nouvelles connaissances et le mentorat s’appuie sur ces connaissances pour créer des capacités durables au sein de l’équipe.


Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

 J’anime plusieurs cours sur le leadership agile et Scrum, si vous souhaitez en savoir plus sur le cadre de travail Scrum, consultez la page de la ValueHut Consulting Academy

Développement itératif ou incrémental : Pourquoi les équipes agiles ont-elles besoin des deux ?

Des cadres de travail agiles tels que Scrum reposent sur deux principes fondamentaux : Le développement itératif et le développement incrémental.

Iterative vs. Incremental Development: Why Agile Teams Need Both par Mike Cohn

https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

Ces termes sont si fréquemment utilisés (et mal utilisés) que leur impact peut être perdu, mais comprendre comment chaque approche fonctionne (et pourquoi leur combinaison est si puissante) est essentiel pour créer de meilleurs logiciels, plus rapidement.

Cet article décompose chaque approche, utilise des analogies du monde réel et explore pourquoi la combinaison des deux est plus efficace que l’une ou l’autre seule.

Qu’est-ce que le développement itératif ?

Un processus itératif progresse par le raffinement.

Une approche itérative du travail commence par une version approximative d’une fonctionnalité ou d’un produit, puis l’améliore grâce à des cycles répétés, chacun se rapprochant peu à peu de la forme finale.

Par exemple, un sculpteur qui aborde le travail de manière itérative peut commencer par sculpter grossièrement un bloc de pierre. À chaque passage, il affine la forme, ajoutant des détails, lissant les bords et s’améliorant continuellement jusqu’à ce que la sculpture atteigne sa forme finale. La sculpture n’est pas terminée tant que l’ensemble de la pièce n’est pas terminé.

Qu’est-ce que le développement incrémental ?

Un processus incrémental permet de créer et de livrer des fonctionnalités et des produits en plusieurs parties. Chaque élément, ou incrément, représente un sous-ensemble complet de fonctionnalités.

Les incréments peuvent être petits ou grands. L’objectif est de terminer chaque incrément de fonctionnalité dans son intégralité avant de passer au suivant, sans qu’il soit nécessaire de revenir en arrière et de repasser sur ce travail plus tard. Chaque incrément terminé peut être livré seul.

Pour en revenir à l’analogie de la sculpture, un sculpteur incrémental choisirait un élément de la sculpture et se concentrerait sur celui-ci jusqu’à ce qu’il soit terminé. Il peut choisir de petits incréments (d’abord le nez, puis les yeux, puis la bouche, et ainsi de suite) ou de grands incréments (tête, torse, jambes puis bras). Cependant, quelle que soit la taille de l’incrément, le sculpteur incrémental tenterait de terminer le travail de cet incrément aussi complètement que possible avant de passer à autre chose.

Les équipes agiles combinent incrémental et itératif.

Le développement agile combine les deux approches pour obtenir le meilleur des deux mondes :

  • C’est itératif parce que le plan est que chaque pièce soit affinée et améliorée au fil du temps.
  • C’est incrémental car des logiciels fonctionnels utilisables sont livrés tout au long du projet.

Cette combinaison permet aux équipes d’apporter de la valeur dès le début, d’obtenir des retours et de s’adapter.

La vidéo ci-dessous montre comment le comédien Jerry Seinfeld aborde son travail d’une manière à la fois incrémentale et itérative.

Exemple concret : Création d’une application de rencontres.

Imaginez que vous développez un site de rencontres. Voici comment chaque approche fonctionnerait.

Purement itératif

  1. Vous construisez et bénéficiez d’un peu de toutes les fonctionnalités : Profils, recherche, chat, etc.
  2. Vous revenez en arrière et améliorez chacun d’entre eux au cours de plusieurs cycles.
  3. Au fil du temps, l’ensemble du système est perfectionné puis, finalement, livré.

Purement incrémental

  1. Vous créez et fournissez une version parfaite de la fonction de gestion des profils. Vous ne commencez rien d’autre avant que ce soit terminé.
  2. Vous construisez et livrez une version parfaite d’une deuxième zone, disons la recherche. Vous passez ensuite à la suivante.
  3. Chaque fonctionnalité est parfaite avant le début de la suivante.

Itératif + Incrémental (Agile)

  1. Vous commencez avec une version de base du profil utilisateur, vous la livrez. Vous obtenez des commentaires.
  2. Vous ajoutez la possibilité d’ajouter une image au profil de l’utilisateur et de fournir une version de base de la fonctionnalité de recherche. Vous obtenez à nouveau des commentaires.
  3. Vous réorganisez les champs sur le profil utilisateur pour améliorer l’expérience utilisateur. Vous ajoutez des filtres à la fonctionnalité de recherche. Vous créez un schéma de la fonction de chat. Vous obtenez davantage de commentaires.
  4. Les sprints suivants peuvent inclure des améliorations apportées aux fonctionnalités précédentes et des versions de nouvelles fonctionnalités utilisables. Ou les deux.

Une approche agile permet des mises en production précoces, des expérimentations à faible risque et des corrections de cap fréquentes, caractéristiques des équipes performantes.

L’agilité est itérative et incrémentale

Ni le développement incrémental ni le développement itératif n’apportent à eux seuls beaucoup de valeur. Mais ensemble, ils forment la colonne vertébrale de l’agilité.

L’itération aide les équipes à affiner et à s’adapter. L’incrémental garantit une progression constante et une création de valeur. Combinés, ils permettent d’obtenir de l’agilité, de la réactivité et des résultats concrets.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Bloquez votre agenda, Piaf 2026 arrive ! « Intégrer l’agilité aux business »

PMI France Agile (PIAF) est en préparation.

  • PIAF 2026 se tiendra le 20 mars 2026. Une journée exceptionnelle pour explorer comment l’agilité, au-delà de l’IT, devient un levier stratégique pour délivrer de la valeur, innover et accompagner la transformation des organisations.
  • Prenez-y la parole ! Proposez une conférence, un atelier ou un sujet de panel. C’est l’occasion idéale de partager vos pratiques, vos retours d’expérience et vos idées pour enrichir la communauté. Voici le lien : https://sessionize.com/piaf-2026 .
  • Retrouvez également les replays des éditions précédentes sur YouTube www.youtube.com/@PIAFAgile .
  • Suivez toutes les actualités et échangez avec la communauté sur LinkedIn : https://www.linkedin.com/company/piaf-agile .
  • Vous souhaitez rejoindre l’équipe d’organisation et contribuer au succès de cet événement ? Contactez cette sympathique équipe Agile !

« Un projet comme système adaptatif complexe : Vers une stratégie de régulation intelligente » par Alain Chautard

Dans le contexte actuel, un projet ne peut plus être considéré comme une suite linéaire de tâches à exécuter selon un plan figé.

Le projet évolue dans un environnement mouvant, souvent incertain, où les variables économiques, sociales, techniques et humaines interagissent en permanence. C’est pourquoi un projet doit aujourd’hui être compris comme un système adaptatif complexe.

Un tel système est constitué d’un ensemble d’acteurs autonomes — qu’il s’agisse d’équipes, de métiers, de prestataires ou de parties prenantes — qui interagissent selon des règles souvent locales, propres à leurs compétences, à leur culture de travail ou à leurs objectifs.

Ces interactions ne sont pas uniquement coordonnées par le haut.

Elles génèrent des effets globaux émergents, qui ne sont pas nécessairement prévisibles à partir des seules règles de départ.

Dans ce type de projet, l’environnement extérieur joue un rôle crucial.

Il n’est pas simplement un cadre passif, mais un élément dynamique qui évolue en fonction des actions du projet et en retour, influence ses trajectoires. Ainsi, le projet ne se contente pas de « suivre un plan » : Il s’ajuste en permanence à l’évolution de son contexte, à la manière d’un organisme vivant qui s’adapte à son milieu pour survivre et évoluer.

Ce pilotage adaptatif repose sur un principe fondamental : L’apprentissage en boucle.

Pour fonctionner efficacement, le système projet doit être capable d’observer son propre fonctionnement en temps réel. Pour cela, il s’appuie sur une base d’indicateurs de performance, construite autour de deux dimensions complémentaires :

  • D’une part, des indicateurs techniques, qui renseignent sur l’avancement, les coûts, la qualité, la charge ;
  • D’autre part, des indicateurs humains, qui donnent des signaux sur la motivation des équipes, les tensions organisationnelles, la clarté des rôles ou encore le climat de collaboration.

Ces indicateurs ne prennent tout leur sens que lorsqu’ils sont mis en rapport avec des consignes réalistes, c’est-à-dire des objectifs adaptatifs, définis non pas comme des normes rigides mais comme des seuils d’alerte intelligents, ajustés aux spécificités du projet et de son environnement.

Lorsqu’un écart apparaît entre la mesure et la consigne, cela ne signifie pas forcément un échec, mais signale un besoin d’ajustement.

Ce signal déclenche alors un processus structuré de résolution de problème.

Des méthodes éprouvées comme l’AMDEC (analyse des modes de défaillance et de leurs effets), les arbres des causes ou les 5 pourquoi permettent d’identifier les origines profondes des écarts constatés. À partir de là, des plans d’action ciblés sont construits. Ces actions ne sont pas imposées de façon descendante mais redistribuées intelligemment aux acteurs du projet : Elles sont affectées à des services, à des équipes, à des personnes, selon leurs compétences, leur responsabilité ou leur place dans la dynamique de travail.

Chaque action corrective devient alors une nouvelle donnée d’entrée pour le système, et contribue à le faire évoluer. Cette dynamique produit de l’apprentissage collectif. Les bonnes pratiques identifiées, les erreurs comprises, les seuils ajustés ou les innovations de terrain sont capitalisés. Ils alimentent la mémoire du projet, mais aussi plus largement celle de l’organisation. Ainsi, à chaque cycle de régulation, le système augmente sa résilience.

Progressivement, à force de réajustements, de diagnostics, de réinjections d’expérience, l’entreprise devient plus apte à résister aux aléas, à intégrer le changement, à transformer ses pratiques en continu. Elle devient ce que l’on appelle une organisation apprenante, c’est-à-dire une entité capable de se transformer par l’usage intelligent de ses propres retours d’expérience.

Ce que l’on observe ici, c’est une commande adaptative intégrée.

Elle ne repose pas sur un pilotage centralisé rigide, mais sur une régulation distribuée, fondée sur la circulation de l’information, l’analyse des signaux faibles, la réactivité locale et la diffusion d’une vision commune. L’enjeu n’est plus simplement de « tenir un cap », mais de coordonner des trajectoires multiples vers une direction stratégique partagée, en conservant la capacité d’adaptation à chaque instant.

Ainsi, le projet cesse d’être une construction mécanique, pour devenir une forme vivante, auto-régulée, intelligente, guidée par ses boucles d’observation, d’action et d’apprentissage.

Cette approche change en profondeur la posture du chef de projet, du manager et des équipes :

On passe d’un modèle de contrôle à un modèle de résonance, d’un plan à une dynamique, d’un programme à une forme d’intelligence collective.

C’est un Contrôle statistique de processus qui en entreprise peut s’appliquer à divers processus (gestion de projets, marketing, veille technologique). Une entreprise est caractérisée par un produit ou service. Une organisation et des processus sont établis afin de concevoir, développer, produire et vendre un produit ou un service. Cela a un coût : Le prix de revient (PR). Le prix de vente (PV) est lié à l’équilibre économique de la concurrence. Le bénéfice (B = PV − PR) est à optimiser, ce qui exige de réfléchir à la commande des processus afin de limiter les coûts de non-qualité (entropie de l’entreprise, désordre organisationnel, gaspillage [qu’il s’agisse d’activités, de ressources ou de matière]). Un contrôle statistique met en œuvre la commande du processus et permet de garantir une efficacité du processus en minimisant les coûts de non-qualité générés par celui-ci.

Dans ces 3 cas d’applications, la modélisation conduit à une estimation de paramètres pertinents. Leur estimation en temps réel (apprentissage) conduit à un pilotage adaptatif et optimal de ces systèmes en vue de finalités opérationnelles. L’application opérationnelle de ces méthodes est une commande adaptative de ces systèmes.

Nous pourrions la modéliser par le schéma suivant :

La complexité des systèmes temps réel et processus d’entreprise conduit à élargir les techniques traditionnelles d’analyse et de pilotage afin d’ optimiser l’efficacité du système (estimation, prédiction interprétation) , cela par le biais de la commande adaptative. C’est un mode particulier de commande optimale

Bibliographie

W Edwards DEMING – Out of the crisis

Michael MACCOBY – Strategic Intelligence (conceptual tools for leading change)

Général Vincent DESPORTES – Décider dans l’incertitude

Jean Claude CORBEL – Management de projet : Fondamentaux – Méthodes – Outils

Alain CHAUTARD – La Data Science pour modéliser les systèmes complexes: Optimiser la prédiction, l’estimation et l’interprétation – Dunod – 2020


Alain Chautard

Alain Chautard est ingénieur en data science dans le groupe Thalès. Il a travaillé pendant 20 ans dans les services d’Études Avancées où il a été acteur dans la modélisation et la simulation de systèmes complexes. Depuis 15 ans, il participe au développement et la mise en œuvre des systèmes d’information, notamment dans le domaine de la Gestion de projet. Dans ce cadre, il est en charge d’études concernant l’utilisation des données capitalisées et leur modélisation à des fins de prédictions pour la conduite du changement et l’amélioration continue.

3 conseils pour rester effectif et devenir plus efficace !

3 conseils pour rester effectif et devenir plus efficace : La résilience, le temps de marge et les boucles de rétroaction plus rapides

Three Tips to Be More Effective: Resilience, Slack, and Faster Feedback Loops par Johanna Rothman

https://www.jrothman.com/newsletter/2023/06/three-tips-to-be-more-effective-resilience-slack-and-faster-feedback-loops/

Stan, un client potentiel, a eu du mal à trouver le temps de participer à notre session de découverte. (C’est la session de travail où le client et moi discutons des limites d’une mission de conseil.) Après qu’il ait annulé trois appels programmés, j’ai soupçonné que nous ne travaillerions pas ensemble.

Mais ensuite, il m’a demandé une conversation un soir, après sa « journée de folie ». (Ses mots, pas les miens.)

Lorsque nous avons discuté après nos heures normales de travail, j’ai appris plusieurs choses importantes sur son organisation.

  • Tout le monde était surchargé. Les équipes avaient trop de projets et de travail de support. Les managers avaient trop de décisions à prendre.
  • En conséquence, leur débit était assez faible. Cela signifiait que leurs boucles de rétroaction étaient trop longues. (Ils souffraient des effets de Loi de Little avec un en-cours élevé, un long encourt et un faible débit.)
  • Il était certain qu’il allait perdre des gens s’il ne changeait rien. Et il ne savait pas par où commencer.

Au cours de notre conversation, il a convenu avec moi qu’il devait mener ces changements. Ces changements étaient d’atteindre plus de résilience dans le système de chacun, plus de marges dans le système, et que tous fassent tout ce qu’ils peuvent pour créer des boucles de rétroaction plus rapides.

Commençons par ce que j’entends par plus de résilience dans le système.

Astuce #1 : Résilience du système.

Beaucoup de personnes pensent que la résilience leur permet de rebondir après des moments difficiles. Au lieu de cela, considérez la résilience comme un moyen de vous projeter vers l’avant. Si c’est le cas, vous pouvez vous libérer pour prendre des décisions différentes, et peut-être meilleures.

Lorsque Stan a repensé ses idées sur la résilience, il s’est rendu compte que l’organisation avait créé un système fragile, peu susceptible de rebondir du tout, sans parler d’aller de l’avant.

Stan a identifié ce qui rendait le système fragile :

  • Des feuilles de route longues et détaillées pour la plupart des produits.
  • Des promesses spécifiques que les ventes avaient faites à plusieurs clients, ce qui a forcé à maintenir ces feuilles de route en place. Parce que les feuilles de route étaient si longues, les gens ont continué à y ajouter davantage de fonctionnalités.
  • À la suite de toutes ces promesses, tout le monde regardait en arrière, pas en avant.

Cette perspective, de toujours regarder en arrière, rendait difficile, voire impossible, la réévaluation d’une décision. Après avoir discuté des problèmes, Stan a décidé de reconsidérer toutes les différentes promesses faites aux clients. Comme il l’a dit :

« Nous avons déjà rompu les promesses de date de livraison. Autant tout négocier. »

Lentement, en supprimant les ancres autour des engagements de chacun, Stan a pu réduire le nombre de projets actifs et créer un peu de marge dans le système.

Astuce #2 : Intégrez de la marge dans le système

Stan et moi avons reparlé dans la soirée. Même si les équipes ont réussi à dégager un peu de marges, Stan avait toujours l’impression que le travail le submergeait. Mais maintenant, il avait besoin d’informations pour garder ces marges dans le système. Pendant si longtemps, les gens avaient été si occupés qu’ils ne savaient pas quoi faire de leur temps « supplémentaire ».

Je lui ai demandé : « Coachez-vous les gens pour qu’ils prennent certaines de vos décisions ? Ou est-ce que vous devez encore prendre toutes les décisions ? »

Il s’est arrêté et a dit :

« Je suppose qu’il est temps pour moi de déléguer certaines décisions, n’est-ce pas ? »

« Vous n’obtiendrez pas de boucles de rétroaction plus courtes tant que vous n’aurez pas intégré un peu de mou dans votre système », ai-je dit. « Il suffit de regarder notre relation de conseil. Vous me payez cher pour travailler avec moi en dehors de vos heures de travail normales. C’est comme une taxe de décision. Je parie que vous avez beaucoup plus de ces taxes de décision chaque jour que nos simples discussions.

J’ai su qu’il comprenait quand il a émis un grognement. Mais cette idée lui a permis de raccourcir de nombreuses boucles de rétroaction.

Astuce #3 : Raccourcissez les boucles de rétroaction

Lorsque j’ai parlé pour la première fois avec Stan, son temps de prise de décision et celui de toute la direction exécutive éclipsaient tout le temps de travail sur les projets.

(Voir Why Minimize Management Decision Time.)

Comme les équipes ont travaillé sur moins de projets et sur moins de fonctionnalités, elles ont raccourci leurs boucles de rétroaction internes. Cela leur a permis de montrer des démos et de livrer plus souvent en production, ce qui a permis aux chefs de produit de réduire le contenu du backlog et des feuilles de route. Cela a aussi permis aux chefs de produit d’être beaucoup plus réactifs aux besoins des clients et de terminer les projets plus rapidement. Plus les équipes terminaient les projets rapidement, plus il était facile de modifier le portefeuille de projets.

(Voir Multiple Short Feedback Loops Support Innovation.)

Aujourd’hui, en repensant leur approche de la résilience et en créant davantage de marges dans le système, Stan pouvait constater que l’organisation était plus efficace. Il avait encore du travail à faire avec son équipe de direction, mais elle était sur la bonne voie.

L’efficacité mène à l’agilité de l’entreprise

Lors d’une conversation récente (pendant les heures normales de travail !), Stan a dit qu’il avait enfin l’impression que l’organisation était plus efficace. Et qu’il avait plus d’options, ce qui était le point de l’agilité business.

Nous nous réunissons maintenant pendant nos journées de travail, et non le soir. Stan a l’air plus détendu. Il a dit qu’il prenait des décisions plus rapidement et mieux, ce qui était le but de notre engagement.

Il se peut que vous ne souhaitiez pas ou n’ayez pas besoin d’une « véritable » agilité business. Cependant, je soupçonne que vous voulez être plus efficace.

Considérez ces idées :

  • Utilisez la résilience pour vous projeter vers l’avant.
  • Intégrez des marges dans le système pour ne pas être frénétique.
  • Raccourcissez les boucles de rétroaction, en particulier les boucles de rétroaction de la direction.

Si vous mettez en œuvre es conseils, partagez comment cela se passe.

Êtes-vous nouveau sur la newsletter de Pragmatic Manager ? Voir les éditions précédentes.

 

Les indicateurs de flux et pourquoi ils sont importants pour les équipes et les managers.

Les indicateurs de flux sont le seul « secret » qui peut améliorer l’agilité dans n’importe quelle approche.

Flow Metrics and Why They Matter to Teams and Managers par Johanna Rothman

https://www.jrothman.com/newsletter/2024/01/flow-metrics-and-why-they-matter-to-teams-and-managers/

Je continue de travailler avec des gens qui ont de la difficulté avec leur approche agile. Ils me disent que l’estimation relative ne fonctionne pas pour eux. Ils continuent à repousser des items de l’arriéré de produit, d’un sprint à l’autre. Ils ont reconduit certains articles pendant six mois ou plus. Les gens se sentent démoralisés. Et les Scrum Masters ou les managers de projet agiles n’ont aucune idée de la façon de résoudre la situation.

C’est à ce moment-là que je leur recommande d’utiliser les métriques de flux au lieu de l’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles ne les aident pas.

Les indicateurs de flux sont le seul « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces indicateurs mettent en évidence les principes de l’agilité. Lorsque les équipes mesurent ces quatre indicateurs, elles peuvent voir leur réalité et décider quoi faire pour créer un meilleur environnement. Et, comme pour la plupart des principes, il y a une petite différence dans la façon dont ils comptent pour les équipes et les managers.

Tout d’abord, voyons ce que sont les métriques de flux.

Métriques de flux

Voici les quatre indicateurs de flux :

  1. Work InProgress (WIP), travail en cours. Tous les travaux en cours : commencés et pas encore terminés.
  2. Throughput, débit : Nombre d’éléments de travail qu’une équipe/un responsable peut effectuer par unité de temps.
  3. Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
  4. Vieillissement : Depuis combien de temps un travail est en cours.

Bien que les indicateurs de flux soient indépendants, ils créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager.

Commençons par une équipe.

Comment les métriques de flux interagissent

Imaginez une équipe qui termine régulièrement un élément chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense que l’on a besoin d’en faire « plus ». Peut-être que quelque chose a changé sur le marché ou que la direction n’est pas satisfaite du rendement de l’équipe. Ou peut-être qu’un concurrent gagne du terrain. Quoi qu’il en soit, l’organisation en veut « plus ».

Une personne bien intentionnée demande à l’équipe de commencer un autre article cette semaine et de le terminer. Cela augmente le WIP de l’équipe. Cependant, à moins que l’équipe ne change quelque chose dans sa façon de travailler, elle n’augmente pas son débit, simplement parce qu’elle a commencé un élément supplémentaire.

En fait, leur débit a diminué parce qu’ils travaillent sur deux articles en parallèle et n’ont terminé aucun des deux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux articles plus anciens, ce qui augmente l’âge moyen de tous les articles.

La demande de travail augmente, tout cela parce que l’équipe n’a pas terminé « assez » d’items.

C’est une boucle de rétroaction qui se renforce. À mesure que le WIP augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des articles plus vieux. Tout cela augmente leur WIP.

Nous tournons en rond, créant un environnement de plus en plus mauvais pour l’équipe.

Si vous avez déjà vu une équipe « basculer » le travail d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse n’aident pas, mais la mesure du temps de cycle fonctionne.

La bonne nouvelle, c’est que l’équipe peut intervenir à n’importe quel endroit et apporter des améliorations.

Interventions de l’équipe.

Voici les questions que l’équipe peut poser :

  • Quelle est la chose sur laquelle nous devrions travailler et terminer ? (Commencer par WIP.)
  • Quel âge a notre item le plus ancien ? A-t-il encore de la valeur ? (Commencez par le vieillissement.)
  • Que devrions-nous changer dans notre travail pour réduire notre temps de cycle ? (Focus sur le temps de cycle.)
  • Comment pouvons-nous augmenter notre débit ? (Focus sur le débit.)
boucle de renforcement positif

J’ai tendance à commencer par l’une ou l’autre des deux premières questions, car elles se concentrent sur une chose que l’équipe peut terminer. Lorsque l’équipe réduit son en-cours à un seul élément, elle doit changer sa façon de travailler. (J’ai abordé ce problème de collaboration dans le conseil 3 en Trois conseils pratiques pour commencer votre prochaine année en force.)

Ensuite, plus l’en-cours est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens items est réduit. C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.

Est-ce que « 1 item » est toujours le bon nombre pour les travaux en cours ? Non. Dans créez votre projet Agile réussi, je recommande à l’équipe de commencer par le nombre de personnes de l’équipe divisé par deux. Si vous avez un nombre impair de personnes, arrondissez au dessous. Donc, si vous avez cinq personnes, utilisez deux comme WIP maximum.

Mais votre équipe peut vouloir commencer par des changements d’équipe pour réduire le temps de cycle et augmenter le débit. Vous pouvez commencer n’importe où car il s’agit d’une boucle de rétroaction.

Les managers travaillent différemment. Aussi, les indicateurs ne changent pas, mais les interventions de la direction changent.

Interventions de la direction

Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne livrent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées présentées dans pourquoi minimiser le temps de décision de la direction ont tellement d’importance.

Plus les managers ont des de décisions en cours de réflexion (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus le WIP d’un manager est élevé, plus le temps de cycle est long et plus le débit est faible. Cela signifie que les gens ne savent pas quoi faire et décident par eux-mêmes. Les gens ne peuvent plus attendre une décision du management.

Les managers peuvent se poser des questions légèrement différentes :

  • Dois-je prendre cette décision ou puis-je la déléguer à quelqu’un ou à une autre équipe ? (Cela réduit les travaux en cours.)
  • Cette décision a-t-elle encore de la valeur ? (Réduire le vieillissement.)
  • Quelles décisions puis-je prendre aujourd’hui pour m’en débarrasser ? (Réduire le temps de cycle.)
  • De qui d’autre ai-je besoin pour prendre cette décision et comment pouvons-nous décider aujourd’hui ? (Augmenter le débit.)

Bien que les questions soient un peu différentes, les managers peuvent utiliser la boucle de rétroaction pour créer une boucle de rétroaction qui fonctionne pour eux, et non contre eux.

Les indicateurs de flux peuvent amener de meilleures décisions.

Lorsque les équipes et les managers voient le nombre de leurs travaux en cours, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils veulent changer. Est-il temps de collaborer davantage ? Peut-être commencer par la question de la valeur, comme dans « Quelle est la chose la plus précieuse que nous puissions terminer aujourd’hui ? ».

Les indicateurs de flux sont importants car ils permettent aux équipes et aux managers de voir et de gérer leur façon de travailler. Utilisez-les pour obtenir des informations sur les domaines dans lesquels vous pourriez choisir de modifier votre travail.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Cette lettre d’information aborde les sujets abordés dans les livres :

Livre sur Amazon
Livre sur Amazon

Nouveau sur le Pragmatic Manager ?

Êtes-vous nouveau sur la newsletter Pragmatic Manager ? Consultez les numéros précédents ou visualisez et écoutez ces newsletters sur la chaîne YouTube.

Comment les équipes autonomes aident-elles tout le monde à apprendre et à s’améliorer ?

Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome.

How Autonomous Teams Help Everyone Learn and Improve par Johanna Rothman

https://www.jrothman.com/newsletter/2025/05/how-autonomous-teams-help-everyone-learn-and-improve/

Avez-vous remarqué que certaines équipes semblent être plus efficaces que d’autres ?

La plupart du temps, elles gèrent leur WIP (Work in Progress). Ses membres apprennent ensemble. Souvent, ils collaborent à l’échelle de l’organisation. Mais le point majeur, c’est qu’ils ont tendance à livrer plus rapidement et plus souvent que les autres équipes moins efficaces.

Bien que la plupart de ces équipes efficaces soient interfonctionnelles, j’ai travaillé avec des équipes de composants qui ont démontré ce comportement. Chaque équipe était autonome, mais elle collaborait pour livrer quelque chose de plus grand que « son » seul composant.

Qu’est-ce qui crée ces équipes plus efficaces ?

Plusieurs caractéristiques :

  • Elles ont un objectif global clair.
  • Tout le monde collabore pour travailler vers cet objectif, et seulement vers cet objectif.
  • Les membres de l’équipe ont appris à donner et recevoir des commentaires les uns des autres. Ces commentaires aident l’équipe à apprendre et à s’améliorer.

Et comme très peu d’équipes peuvent livrer seules, elles peuvent aider les autres équipes à apprendre et à s’améliorer. Tout cela parce qu’elles créent et utilisent des plus petits réseaux. Ce sont des équipes autonomes.

Comment fonctionnent les équipes autonomes ?

Les équipes autonomes prennent leur objectif clair, se concentrent sur celui-ci et atteignent cet objectif. Elles décident comment travailler ensemble et comment manager les membres de l’équipe lorsqu’elles ne le peuvent pas. Lorsqu’elles ne peuvent pas livrer, elles vous en informent le plus tôt possible.

Si vous êtes manager, comment pouvez-vous créer ces équipes autonomes ?
  • Établissez et clarifiez l’objectif global de cette équipe.
  • Demandez à l’équipe si elle a besoin d’une certaine facilitation au début ou au fur et à mesure qu’elle persiste. Si certaines équipes autonomes n’ont pas besoin de facilitation, beaucoup en ont la nécessité. Surtout face aux exigences omniprésentes de multitâches.
  • Encouragez la création de communautés à l’échelle de l’organisation et de plus petits réseaux. Cela aide les personnes et les équipes à réfléchir à la manière dont elles peuvent apprendre à l’échelle de l’organisation. Et d’offrir des informations recueillies dans leur équipe aux personnes de l’ensemble de l’organisation.

Commençons par l’objectif global.

Définissez et clarifiez l’objectif global de l’équipe.

Les équipes de développement de produits ont souvent un objectif global axé sur le produit. C’est de la forme :

Cette version permettra au jeu de clients numéro un de résoudre les problèmes A, B et C dans cet ordre de classement. Bien que nous espérions pouvoir également résoudre les problèmes D, E et F, nous nous concentrons pour l’instant sur ce plus petit objectif spécifique. Parce que même si nous voulons accomplir D, E et F, nous pouvons également vouloir nous concentrer sur un jeu de clients différent lorsque nous terminerons A, B et C.

Vous pouvez décrire différemment l’objectif global de votre équipe. Cependant, ces objectifs sont souvent spécifiques, c’est pourquoi ils définissent un périmètre circonscrit autour du travail de l’équipe, afin que l’équipe puisse se concentrer uniquement sur son travail. Pas de multitâche. Pas d’interruptions.

Mieux encore, un périmètre circonscrit aide l’équipe à repousser ce qui est hors de celui-ci pour le moment. L’équipe ne se laisse pas distraire par un travail futur ou d’autres possibilités. Au lieu de cela, elle livre ce qu’elle doit livrer.

Si vous faites partie d’un programme, un ensemble de projets tous axés sur un livrable business global, vous avez probablement vu des équipes agir ainsi. Chaque équipe se concentre sur sa contribution pour que le produit global réussisse.

Alors que certaines équipes peuvent s’accaparer leur objectif global et le suivre, certaines équipes ont également besoin de facilitation.

Envisagez des rôles d’animation d’équipe.

Normalement, je ne considère pas le leadership de produit comme un rôle d’animation d’équipe. Mais parfois, c’est le cas. Surtout si les membres de l’équipe ont du mal à se concentrer sur le premier jeu de clients. Ou dans l’ordre de hiérarchisation des problèmes A, B et C.

Il y a longtemps, j’ai travaillé sur un programme où la direction avait décidé de reporter pour le moment plusieurs fonctionnalités intéressantes et de les considérer pour une future version. Cependant, un développeur était convaincu qu’il devait « sauver » le produit en continuant à travailler sur ces fonctionnalités intéressantes.

C’est à ce moment-là que le chef de produit a expliqué l’intérêt de reporter ces fonctionnalités intéressantes et ce que l’entreprise espérait gagner avec cette version plus limitée.

Une fois que le développeur a compris ceci, il fut heureux de se concentrer sur le travail de l’équipe, et non sur ses intérêts.

Parfois, les équipes ont besoin de liberté pour être autonomes. J’ai vu des managers bien intentionnés (et certains moins bien intentionnés) s’insérer dans le travail de l’équipe. Lorsque les managers font cela, l’équipe perd son autonomie. Au lieu de cela, un manager de projet facilitateur peut agir comme une boîte de délimitation pour l’équipe elle-même, protégeant l’équipe des personnes qui détruiraient l’autonomie de l’équipe.

Les managers de projet facilitateurs ne disent pas à l’équipe quoi faire ou comment travailler. Au lieu de cela, ils et elles créent l’environnement pour que tout le monde puisse contribuer. Parfois, cela signifie expliquer à des managers bien intentionnés que non, l’équipe ne peut pas en faire plus.

Parfois, ces animateurs et animatrices aident l’équipe à mieux travailler ensemble. Il peut s’agir de faciliter les accords de travail de l’équipe ou d’aider l’équipe à s’entraîner à donner et recevoir des commentaires. Il peut s’agir d’aider l’équipe à envisager des pratiques alternatives pour la rendre encore plus efficace.

Mais les leaders facilitateurs ne disent pas à l’équipe comment travailler. Ils et elles offrent des options. Souvent, l’une de ces options inclut les communautés de l’ensemble de l’organisation.

Construisez des communautés à l’échelle de l’organisation.

Lorsque je vois des équipes autonomes, je découvre souvent que ces équipes ont construit des réseaux à l’échelle de l’organisation. (Voir l’image en haut de cet article.) Non pas parce que quelqu’un leur a dit de le faire. Mais elles se rendent compte que Marie, là-bas, a des connaissances intéressantes. Et Fred, ici, a déjà résolu un problème comme celui-ci. Ou Suzanne, dans cette autre équipe, a déjà eu affaire à ce client.

Les équipes autonomes peuvent combler leurs lacunes en travaillant avec et auprès d’autres personnes, même si ces autres ne font pas partie de « leur » équipe.

J’aime particulièrement les groupes d’apprentissage ciblés. Envisagez les communautés de pratique formelles comme un moyen de commencer par un apprentissage ciblé. À l’époque où les entreprises avaient des cafétérias, j’apprenais beaucoup de choses de manière informelle au déjeuner. Non seulement j’ai appris à connaître les produits, mais j’ai aussi appris qui avait quels types de connaissances. Cela m’a aidé à décider par où commencer une quête sérieuse.

Bien que de nombreuses équipes autonomes n’aient pas besoin d’un leadership spécifique axé sur un projet ou une équipe, elles ont besoin du type de leadership qui peut définir l’objectif global.

Les équipes autonomes ont toujours besoin d’un leadership d’entreprise.

La grande chose dont les équipes autonomes ont besoin de la part de la direction est la suivante : L’objectif global et la durée de cet objectif.

Cela signifie que les équipes autonomes doivent comprendre le(s) objectif(s) du produit et la stratégie. Ces équipes doivent comprendre à quelle fréquence la direction de l’entreprise souhaite être en mesure de modifier ces objectifs de produit et/ou cette stratégie.

De plus, il arrive que des équipes se retrouvent en difficulté et qu’elles ne sachent pas comment s’en sortir. (Imaginez un membre de l’équipe qui cesse de venir travailler. Ce genre de problème.) C’est à ce moment-là que les managers peuvent soutenir l’équipe et les différents membres de l’équipe.

Les équipes autonomes ne fonctionnent pas en circuit ouvert. Au lieu de cela, elles montrent leur travail tôt et souvent. Elles utilisent un périmètre circonscrit pour se concentrer sur leur objectif et uniquement sur cet objectif. Et si quelqu’un demandait autre chose ? Elles ont des options, mais ces options incluent rarement le multitâche ou le fait de dire oui. Elles sont beaucoup plus susceptibles de dire non.

Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome. Votre équipe apprendra et s’améliorera, et contribuera à partager cet apprentissage et cette amélioration dans toute l’organisation.

Lu dans la newsletter de Johanna Rothman pour le mois de mai 2025 de Pragmatic Manager.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Comment faire la différence entre un ordre de classement et une hiérarchisation des besoins ?

Si les vraies priorités ne sont pas bien posées et comprises, l’équipe projet risque fort de travailler sur trop d’éléments en même temps et ne pas être très efficace.

How to Tell the Difference Between Rank-Order and Prioritization par Johanna Rothman

https://www.jrothman.com/mpd/2025/03/how-to-tell-the-difference-between-rank-order-and-prioritization/

Trop de mes clients confondent deux termes spécifiques : Ordre de classement (Rank Order) et hiérarchisation. Trop souvent, cela signifie que l’équipe travaille sur trop d’éléments en même temps. Cela conduit à un en-cours élevé, à un temps de cycle court et à un faible débit.

Voici donc un visuel et une explication.

Voir la partie gauche de l’image « L’ordre de classement ». Lorsque nous classons les travaux par ordre d’ordre, nous choisissons une priorité #1, une priorité #2, une priorité #3, et ainsi de suite.

Nous ne choisissons qu’un seul élément à chaque priorité.

Oui, ce mot « priorité » fait partie du problème. Nous y reviendrons plus tard.

Comparez cette approche et cette explication avec le nombre d’organisations qui créent une « La liste priorisée » (Prioritization) (partie droite de l’image) :

Cette organisation a déclaré :

« Nous allons prioriser le travail, mais nous avons trop de travail pour vraiment faire la distinction entre chacun des éléments aux niveaux élevés, moyen et bas. Nous laisserons donc à l’équipe (ou au chef de produit) le soin de décider quand il sera temps pour eux de décider.

On dirait que l’équipe a de l’autonomie, n’est-ce pas ?

Pas si vite.

Cette équipe a trois éléments prioritaires « Forts». Selon la taille de chaque article, cela peut représenter l’équivalent d’un trimestre entier de travail. Ensuite, l’équipe a six éléments prioritaires « Moyens ». Combien de temps cela prendra-t-il ? Aucune idée.

Pire, l’équipe a 12 articles prioritaires « Faibles ». celle-ci peut aussi être une liste infinie.

Parlons de la « priorité » et de ce que cela signifie.

Ce que signifie la priorité

Lorsque nous disons « prioriser », nous sommes censés répondre à cette question : « Quelle est la préséance de cet élément par rapport à tous les autres éléments ? »

Lorsque nous classons le travail, avec un élément à chaque rang, nous pouvons le dire.

Mais lorsque nous classons le travail avec Fort, Moyen et Faible, nous commençons à peine à classer le travail. Si nous autorisons plusieurs articles à chaque rang (comme je le vois chez mes clients), nous n’avons pas terminé la hiérarchisation. Pire encore, certaines techniques pour décider quel travail faire maintenant, comme MoSCoW, aggravent encore la situation. (MoSCoW signifie : Must, Should, Could, Would.)

Lorsque nous priorisons plusieurs éléments à la fois, nous pouvons nous retrouver dans une très mauvaise situation avec beaucoup trop de WIP (travail en cours / en-cours).

Il y a des années, l’un de mes clients a commencé avec Fort, Moyen et Faible. Mais Fort n’était pas assez élevé, alors ils ont ajouté « Vraiment Fort ». Puis, « Ultra Fort ». Oui, ils ont commencé à utiliser « Mega Fort » quand je suis arrivée.

Les managers l’ont fait parce que l’équipe avait tellement d’en-cours que leur débit était assez faible. Voir la  newsletter Flow Metrics.

J’ai demandé à tous les managers de créer silencieusement une liste classée de tous ces fiches d’éléments de travail avec une seule liste de fiches sur la table. Ils n’ont pas pu se mettre d’accord. Je leur ai donné trois minutes, et quand Buzz a été en désaccord avec Woody pour la troisième fois, je les ai arrêtés. Nous avons discuté du problème, et je leur ai présenté l’ordre de classement.

Ils pouvaient tous s’entendre sur les trois premiers éléments de leur liste beaucoup trop longue. C’était suffisant pour que l’équipe commence à travailler et à livrer. Ils doivent classer le travail, pas le hiérarchiser.

Classement du travail

Certains de mes collègues agiles recommandent qu’une équipe puisse commencer à répartir le travail entre Fort, Moyen et Faible. Mais cela en vaut-il la peine alors que si peu d’équipes atteignent les niveaux Moyen et Faible ? (Ou l’un des autres termes de hiérarchisation employé ?)

Pire encore, le chef de produit ou l’équipe n’a pas vraiment la capacité de dire « non » à l’un ou l’autre des éléments de travail. Cela signifie que l’équipe n’a pas l’autonomie nécessaire pour décider.

C’est pourquoi je recommande à l’équipe de classer le travail. Vous pouvez utiliser le temps de cycle ou compter le nombre de stories que votre équipe termine généralement dans un sprint. Ne classez – et planifiez – que pour ce nombre d’histoires. Ensuite, l’équipe sait ce qu’elle est censée faire maintenant. Cela permet au chef de produit de réduire les options pour le travail suivant.

J’aimerais que le classement et la hiérarchisation signifient la même chose. Trop d’organisations ne traitent pas ces deux activités de la même manière. Au lieu de cela, classez le travail avec un élément #1, un élément #2, etc. car cela vous permettra de limiter le WIP et de terminer le travail.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Pourquoi Agile est-il mort ? (Best of #9)

Ne reportez pas tout le blâme sur les leaders !

Ce billet fut le plus apprécié en 2024.

De trop nombreuses organisations ont embauché des coachs Agile pour former et coacher les équipes sans élaborer de plan stratégique pour le changement nécessaire au succès d’Agile.

Pourquoi Agile est-il mort ? par Britt Smith

Surmontez la fatigue de l’IA ! Quelques conseils pratiques pour les managers de projets.

En tant que manager de projets, trouvez-vous que la simple évocation de l’acronyme « IA » est épuisante ?

Inspiré de “Overcoming AI fatigue: Practical advice for product managers” par Elizabeth Haynie »

Pour de nombreux chefs de projets, les forces au sommet de leur entreprise commencent à rendre obligatoire l’utilisation de l’Intelligence Artificielle dans leurs jobs :

Tout le monde veut utiliser l’IA pour tout (et n’importe quoi).

Vous êtes frustré par les priorités mouvantes de l’entreprise en matière d’IA.

De nombreux managers de projets naviguent silencieusement dans leurs sentiments mitigés face à la présence croissante de l’IA, mais la communauté des managers a peut-être besoin d’avoir un dialogue ouvert à ce sujet.

Comment pouvez-vous rester sain d’esprit face à la tâche ardue d’utiliser l’IA pour tout ?

La peur des licenciements restant élevée en raison des continuels plans de compression de personnel, il est tentant pour vous de vouloir faire profil bas et d’être très accommodant. Votre prudence est compréhensible, mais rester silencieux sur l’IA et hésiter quant à son utilisation, se retournera contre vous.

Aujourd’hui, plus que jamais, faire entendre votre voix pourrait être crucial pour éviter de devenir un dommage collatéral de la prochaine restructuration.

L’alternative ?

N’évitez pas les discussions sur l’IA, mais façonnez plutôt votre avenir avec connaissances et confiance.

#1 – Développez une voix forte en tant que manager de projets.

La meilleure façon de développer une voix forte sur les sujets de l’IA est de devenir un utilisateur de la technologie.

Vous familiariser avec ChatGPT est un excellent moyen d’acquérir de l’intuition sur la façon d’utiliser les modèles LLM (Large Language Models). Au-delà de l’IA générative, il existe également des modèles prédictifs qui font des projections basées sur des données historiques.

Bien que les modèles prédictifs tels que les réseaux neuronaux puissent sembler intimidants, vous n’avez pas besoin de compétences en développement logiciel pour développer votre intuition sur leurs capacités. Des outils interactifs existent qui vous permettent d’expérimenter divers algorithmes sans écrire une seule ligne de code.

Vous pouvez même télécharger vos propres ensembles de données pour tester des scénarios réels. Vous comprendrez qu’un point crucial de l’apprentissage automatique est que toutes les données doivent être converties en valeurs numériques pour que les algorithmes puissent les traiter. Presque tout peut être transformé en chiffres : Texte, images, catégories, métriques qualitatives, avancement du projet…

Quand vous aurez acquis une compréhension de la technologie de l’IA grâce à votre propre expérience de première main, vous pourrez commencer à tirer parti de ces connaissances pour éloigner votre organisation des initiatives d’IA malavisées.

#2 – Connaissez vos pouvoirs sur la décision de faire ou pas usage de l’IA.

Nous ne pouvons pas poursuivre ce projet ou le développement de cette fonctionnalité avec la richesse des algorithmes d’Intelligence Artificielle parce que nous n’avons pas les données pour prouver ses bénéfices.

Les données et surtout l’absence de données sont l’atout ultime pour décider quelles fonctionnalités d’un produit d’IA sont intéressantes à poursuivre.

En tant que manager de projet, vous devez découvrir et dénoncer les problèmes potentiels de disponibilité des données qui pourraient vous empêcher de produire des livrables projet réussis.

Pour un projet utilisant les algorithmes et approches de l’Intelligence Artificielle, le conseil traditionnel de commencer par un problème et trouver une solution ensuite n’est pas le meilleur. Pour l’IA, peut-être devriez-vous prendre l’approche inverse :

Quelles données sont disponibles et quels problèmes importants pourraient-elles aider à résoudre ?

Utilisez la disponibilité et la qualité des données comme point de départ, afin de plus facilement réorienter le projet et ses sponsors vers des résultats plus réalisables.

#3 – Si vous devez échouer, faites le rapidement.

Vous avez partagé avec votre comité de projet le risque indiquant qu’une stratégie d’IA spécifique pourrait échouer, mais votre direction souhaite toujours la poursuivre.

Faites pivoter votre approche avec agilité vers la découverte rapide des problèmes. Fournissez un jeu de données business à votre équipe de développement et demandez-leur de développer un produit minimum viable (MVP) utilisant la technologie. Vous pourriez être surpris et découvrir que la voie d’IA choisie en vaut la peine après tout.

Évitez les voies sans issue.

La ‘révolution’ de l’IA est là et, aussi irritant que cela puisse être de voir cette technologie vous être imposée, votre adaptation est essentielle.

Demandez-vous, puis posez ensuite aux autres ces quelques questions :

  • Avons-nous suffisamment de données fiables disponibles pour résoudre ce problème avec l’IA ?
  • Existe-t-il un moyen rapide de valider cette nouvelle approche ?
  • Existe-t-il une approche maîtrisée plus traditionnelle d’atteindre l’objectif business recherché ?
  • Avons-nous les compétences pour faire pivoter notre stratégie vers cette IA ou combien de ressources et de temps cela va-t-il nécessiter pour les acquérir ?

Les réponses à ces questions devraient vous à éviter d’entrer sans y avoir bien réfléchi dans une mode de l’IA comme réponse universelle à tous les problèmes.

Développez une voix forte de par vos connaissances et expérience dans ce domaine pour empêcher la technique ou la direction de dicter les décisions pour votre projet.

Agile ou l’agilité n’est jamais l’objectif ultime de votre projet !

Cela me gêne toujours quand je vois des gens traiter Agile comme LA solution miracle. Quelque chose à rechercher, quel qu’en soit le prix.

Inspiré de https://mdalmijn.com/p/agile-or-agility-is-never-the-goal de Maarten Dalmijn

L’agilité devrait découler naturellement du type de projet que vous réalisez comme une approche plus efficace qui produit de meilleurs livrables et davantage de valeur, le plus tôt possible à vos commanditaires.

Si les besoins auxquels votre projet doit répondre sont stables et matures et que vous attendez peu ou pas de surprises, vous n’avez pas besoin d’Agile, une approche et méthode prédictives seront très efficaces.

Si vous anticipez de nombreuses surprises mais que vous n’êtes pas en mesure de les manager, vous avez besoin de plus d’agilité.

Rien de réellement nouveau ici.

Si vous êtes un expert dans votre domaine, par exemple dans le management de projet, le développement logiciel, le marketing de produit… vous devez comprendre Agile et être imprégné de ses principes pour savoir quand en tirer bénéfice.

Agile n’est pas un objectif isolé à atteindre, c’est une partie nécessaire et fondamentale pour être bon dans votre job de manager de projet.

L’objectif reste de produire la valeur attendue de votre projet.

Agile peut faire naturellement partie de l’équation de réussite de votre projet, ou pas. Une approche Agile ou hybride fait partie des moyens pour réussir votre projet.

Vous êtes-vous déjà demandé ce qui fait qu’une user story est bonne ? Par Mike Cohn

Voici deux descriptions pratiques de user stories efficaces que chaque équipe devrait connaître.

Les 3 C (par Ron Jeffries)

Une bonne user story a 3 C :

  1. Carte – Une courte description écrite utilisée pour la planification et le suivi.
  2. Conversation – Dialogue qui ajoute de la profondeur et de la compréhension à l’histoire.
  3. Confirmation – Tests et critères d’acceptation qui vous indiquent quand l’histoire est terminée.

Ces trois éléments permettent de s’assurer que vos histoires sont exploitables et alignées sur la compréhension de l’équipe.

INVEST (adapté de Bill Wake)

Cet acronyme décrit six qualités des user stories fortes :

  1. Indépendante – Autonome, ne dépend pas des autres histoires.
  2. Négociable – Souple, pas un contrat rigide.
  3. Valeur – Offre une valeur claire aux utilisateurs ou aux parties prenantes.
  4. Estimable – Suffisamment compréhensible pour être estimée avec précision.
  5. Dimensionnée de manière appropriée – Les stories devront éventuellement être suffisamment petites pour un sprint, mais doivent être dimensionnées à la hausse ou à la baisse, en fonction de leur position dans le backlog.
  6. Testable – Dispose de critères clairs pour que l’équipe sache quand c’est terminé.

Il n’est pas nécessaire que toute les User Stories atteignent les 6 objectifs, mais celles situées en haut de l’arriéré devraient s’en approcher.


Gardez ces cadres de travail dans votre boîte à outils. Ils sont simples, pratiques et peuvent sérieusement améliorer la qualité de votre backlog et vous aider à réussir avec agile.

P.S. Vous cherchez des exemples de user stories à partager avec votre équipe ? J’ai rassemblé 200 échantillons de user stories de l’un de mes premiers projets Scrum. Certains ne sont pas ceux que j’écrirais aujourd’hui, mais j’ai noté lesquels, et pourquoi.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Pourquoi un nouveau pack d’extension du Scrum Guide ?

Ce pack d’extension Scrum Guide explique le quoi et le pourquoi de chaque élément de Scrum en se projetant vers l’avenir.

L’objectif annoncé est une adoption plus réussie grâce à des conseils supplémentaires et actualisés du Guide Scrum 2020 de Ken Schwaber et Jeff Sutherland.

Chaque élément a un objectif spécifique et contribue à la valeur globale et aux résultats obtenus avec Scrum. Ce pack d’extension continuera d’évoluer régulièrement à l’avenir.

Ce document suppose d’être familier de Scrum et son langage associé, donc relisez le Guide Scrum 2020 avant de prendre en main ce document.

Ce pack d’extension est conçu pour traiter de tous les aspects de la livraison du produit par une équipe autogérée motivée par les besoins des parties prenantes en réponse à un problème ou une opportunité.

Bien qu’il soit à l’origine ancré dans le développement de produits logiciels, Scrum a été largement adopté dans divers domaines, pour générer de la valeur par le biais d’un travail collaboratif complexe. Au fur et à mesure que son utilisation se développe, des professionnels tels que des ingénieurs, des programmeurs, des chercheurs, des analystes, des avocats, des spécialistes du marketing et des scientifiques appliquent de plus en plus Scrum avec succès à leurs domaines.

Bonnes lectures (estivales et studieuses) !
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Vidéo de présentation de ce pack.

La partie la plus difficile en premier (ou pas ?).

J’ai eu l’occasion de pratiquer dans mes projets les 2 approches, commencer par la partie la plus ardue ou bien par de plus faciles pour construire la confiance et engranger de premiers bénéfices.

Les 2 ont marché ou pas pour moi en fonction des projets (contenu, degré d’innovation, niveau de changement nécessaire dans les process et habitudes, durée…) et surtout des membres de l’équipe projet, de la gouvernance projet et des parties prenantes.

The hard part first par Seth Godin

https://seths.blog/2023/11/the-hard-part-first/

Si vous essayez de réduire les risques, faites d’abord la partie la plus difficile. De cette façon, en cas d’échec, vous aurez minimisé votre temps et vos efforts.

Mais, d’un autre côté, si vous recherchez l’adhésion et l’engagement afin de pouvoir traverser la partie difficile, faites-la en dernier.

Les gens ont extrêmement de mal à ignorer les coûts irrécupérables, et les victoires précoces et les sentiments d’identification qui découlent des succès faciles du début vous donneront de l’élan dans votre progression.


Alors, s’attaquer à la partie la plus difficile en premier ou plus tard ?

Comme je l’indiquais en intro, je n’ai pas de réponse universelle à cette question. J’apprécie l’approche Agile, en particulier Scrum, qui focalise les choix sur les éléments qui vont apporter le plus de bénéfices business en premier.

Et vous, quelles sont vos expériences sur ce sujet ?
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Un guide simple de Scrum par Tobias Mayer

Volontairement incomplet, Scrum est conçu pour être construit par l’intelligence collective des personnes qui l’utilisent.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

A simple guide to Scrum par Tobias Mayer

https://scrum.academy/guide

Scrum est un cadre de travail léger et centré sur l’équipe qui permet de résoudre des problèmes complexes et de générer de la valeur. Volontairement incomplet, Scrum est conçu pour être construit par l’intelligence collective des personnes qui l’utilisent.

Fondé sur l’empirisme et la pensée Lean, Scrum permet aux équipes de travailler élégamment, en s’adaptant aux exigences changeantes, tout en générant de la valeur pour l’utilisateur, tôt et fréquemment. Pour que cela réussisse, ceux qui mettent en œuvre Scrum doivent travailler avec focus et incarner certaines valeurs, y compris, mais sans s’y limiter, l’engagement, l’ouverture, le respect et le courage.

Le travail est effectué en courts « sprints », généralement d’une durée d’une à quatre semaines. Le sprint est le battement de cœur de Scrum, créant du rythme et permettant d’obtenir un retour rapide.

La mise en œuvre efficace de Scrum nécessite que les éléments suivants soient clairement établis.

L’équipe Scrum

L’unité fondamentale de Scrum est un petit collectif interfonctionnel autogéré avec trois responsabilités.

  • Développeurs : (3 à 8) personnes aux compétences différentes, qui créent en collaboration un incrément de valeur à chaque sprint.
  • Product Owner (PO) : (1) la voix du business ; le PO maximise la valeur du produit en parlant avec les clients, en fixant  des objectifs de produit clairs et en manageant le backlog du produit.
  • Scrum Master : (1) agent de changement organisationnel ; s’assure que Scrum est appliqué efficacement et favorise un environnement propice à l’apprentissage continu et à la croissance personnelle.

Une remarque sur la mise à l’échelle : Si l’équipe devient trop grande, les développeurs doivent se réorganiser en plusieurs équipes cohésives, chacune se concentrant sur le même produit. Par conséquent, ils doivent partager le même objectif de produit, le même backlog de produit et le même product owner.

Engagements

Un objectif clair dirige le travail et rend l’intention visible à tous.

  • Objectif du produit : Décrit un état futur du produit : un engagement à donner une direction claire.
  • Sprint Goal : Un tremplin concret vers l’objectif du produit : un engagement envers la valeur incrémentale.
  • Définition de Done : Un engagement envers la qualité pour tous les éléments de travail.

Artefacts

Ces éléments apportent de la transparence. Chacun d’entre eux est revu régulièrement lors d’un ou plusieurs des événements Scrum.

  • Backlog de produit : Une liste évolutive et ordonnée d’articles, engagée dans l’objectif du produit ; ce backlog est régulièrement affiné et mis à jour.
  • Backlog de sprint : Eléments sélectionnés du backlog et plan d’action validés pour atteindre l’objectif du sprint.
  • Incrément : Eléments du backlog terminés qui concrétisent l’objectif du sprint et répondent à une définition convenue de Done.

Événements

Il y a trois événements de sprint, un événement quotidien et un méta-événement contenant les quatre autres. Ces événements permettent d’effectuer des inspections et des adaptations sur une base régulière, à différents niveaux de granularité.

  • Sprint : Une période de temps précise pour le travail et les quatre événements d’alignement ; le cœur de Scrum où les idées sont transformées en valeur.
  • Planification du sprint : Au début de chaque sprint. Le product owner et les développeurs définissent l’objectif du sprint et sélectionnent les éléments du backlog ; les développeurs peuvent créer une liste de tâches.
  • Daily Scrum : A lieu tous les jours ouvrables, idéalement à la même heure et au même endroit. Une courte conversation avec les développeurs pour inspecter/adapter le backlog de sprint au service de l’objectif du sprint.
  • Revue de sprint : A la fin de chaque sprint. Les parties prenantes inspectent l’incrément et offrent des commentaires ; l’équipe Scrum peut mettre à jour le backlog du produit.
  • Rétrospective de sprint : A lieu immédiatement après la revue de sprint. L’équipe Scrum repense au sprint et identifie les changements pour améliorer son efficacité.

Note de fin

Scrum est un conteneur d’agilité, invitant à d’autres techniques, méthodologies et pratiques. Le cadre de travail Scrum, adopté de manière holistique, permet aux équipes d’inspecter, d’adapter et de livrer des produits de valeur dans des environnements complexes.


Un guide simple de Scrum a été compilé par Tobias Mayer, inspiré par Bob Hartman, et avec des conseils, des suggestions et des orientations de membres de la communauté professionnelle Scrum, notamment Björn Jensen, Hector Feliciano, Joachim Atunwa, Joel Bancroft-Connors, Marcelo Lopez, Mike Vizdos, Natasha Baisiwala, Nick Perry et Tariq Juneja, à qui nous adressons nos remerciements.

Un guide simple de Scrum est une version abrégée et modifiée du Guide Scrum officiel, de Ken Schwaber et Jeff Sutherland, qui reste la source de vérité pour Scrum. Cette version résume et réorganise le contenu, mais n’ajoute pas de nouveaux éléments, ni ne supprime rien d’essentiel. Ce travail est conforme à la licence Attribution Share-Alike de Creative Commons, établie par le Guide officiel Scrum, 2020. Vous êtes libre d’utiliser le contenu comme vous le souhaitez, mais il vous est conseillé de lire l’accord original Scrum Guide Creative Commons et de le respecter.

Tobias Mayer et Bob Hartman, 21 mars 2025

Un guide simple de Scrum, v1, 21 mars 2025. Attribution et crédits. Version PDF (en anglais)

Le product backlog ou arriéré de produit n’est pas une liste linéaire !

« Tout est une question d’arriéré de produit (Product Backlog). Le Product Owner doit le gérer. Donnez-lui la priorité. Remplissez-le de User Stories. »

Backlog is not a Linear List par Zuzi Sochova

https://agile-scrum.com/2025/03/30/backlog-is-not-a-linear-list/

Cela vous semble familier ? À certains stades de la transformation agile, il est typique de se concentrer sur la construction d’un arriéré ou backlog de produit. Et d’utiliser Jira pour cela. Vous trouverez de telles listes linéaires de tâches dans presque toutes les organisations au début de leur parcours agile. Et bien que le Product Backlog soit un outil très important car il apporte de la clarté et aligne les gens autour des mêmes objectifs business, c’est aussi l’un des outils les plus mal compris et les plus mal utilisés.

Cela part souvent par une bonne intention, le Product Owner demandant aux clients ce qu’ils veulent. Et ils réfléchissent à toutes les fonctionnalités possibles que vous pouvez imaginer, dans une bonne intention. Et le backlog/contenu ne cesse de croître alors que les attentes en matière de délais restent les mêmes. C’est le début très fréquent d’une grande déception avec Agile.

« Cela ne nous a pas aidés. Ce n’est pas plus rapide ! » disent les gens, et ils ont raison.

L’agilité n’est pas le moyen de fournir plus de fonctionnalités plus rapidement. Bien au contraire. C’est un moyen d’obtenir plus rapidement une valeur business plus élevée, et ce sont là deux choses différentes.

Donc, si vous voulez obtenir plus de valeur business, commencez par le backlog.

Mais cette fois-ci, vous ne demandez pas ce que vous voulez mettre en œuvre, mais plutôt les besoins et recherchez une fonctionnalité minimale à mettre en œuvre pour satisfaire ces besoins. 80 % de la valeur réside dans 20 % de la fonctionnalité et c’est exactement ce qu’un bon Product Backlog doit identifier. Les objets de plus grande valeur en premier, le reste plus tard ou jamais.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Un bon Product Backlog est co-créé en collaboration avec le client, les parties prenantes et les membres de l’équipe. Ils doivent tous découvrir les besoins de l’entreprise. Ils doivent tous développer une empathie pour les clients. Dans la plupart des cas, le Product Backlog qu’ils créent ensemble n’est pas une liste linéaire qui s’adapterait à des outils traditionnels comme Jira ou Excel, mais très souvent, nous utilisons la technique du Story Mapping pour créer des cartes multidimensionnelles, ou la technique de cartographie d’impact pour créer une carte mentale, ou visualiser le produit sous forme d’arbre et élaguer les branches. Rien qui ressemblerait à une liste linéaire de choses à faire.

Toutes les techniques ont une chose en commun ; Elles se concentrent sur la valeur commerciale et les besoins du client. Elles ne décrivent pas la solution.

Le comment dans Scrum doit être découvert lors du Sprint en collaboration d’équipe. Alors :

Oubliez les exigences, arrêtez de demander à vos clients ce qu’ils veulent, et concentrez-vous plutôt sur la découverte de leurs besoins et visualisez ensemble la valeur dans votre Product Backlog.

« 3 façons de manager le travail inachevé qui sera parfois laissé de côté même par une formidable équipe agile » par Mike Cohn

Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, mais certaines fois vous pourriez découvrir une chose qui est en train de tourner en mauvaise habitude.

#1 – Si vous voulez une garantie, achetez un grille-pain.

Mon premier conseil sur la façon de manager le travail inachevé est : Rappelez-vous  que même les meilleures équipes agiles ratent parfois leurs objectifs. C’est OK et même souhaitable dans une certaine mesure.

Les objectifs de sprint ne sont pas garantis. (Comme le dit le personnage de Clint Eastwood, Nick Pulovski, dans The Rookie, « Si vous voulez une garantie, achetez un grille-pain ! »). Les dirigeants, les parties prenantes et même l’équipe elle-même peuvent avoir besoin d’un rappel occasionnel à ce sujet.

L’engagement d’une équipe envers un objectif de sprint est une promesse de faire de son mieux pour atteindre cet objectif. Si les membres de l’équipe sont perpétuellement contraints de donner une garantie, ils garantiront moins pour être en sécurité.

Parfois, une équipe a besoin de donner une garantie. Il peut arriver qu’un client ait besoin d’une fonctionnalité à une certaine date. Le groupe financier peut avoir besoin d’exécuter des rapports de fin d’année au début du mois de janvier, par exemple.

En général, cependant, nous ne voulons pas forcer une équipe à donner une garantie. Nous demandons à une équipe de s’engager dans quelque chose de raisonnable, puis nous comprenons si elle n’y parvient pas. Ne pas réussir occasionnellement n’est pas un échec, c’est généralement un signe de malchance ou d’une équipe qui s’efforce d’en faire trop.

#2 – Ne reportez pas le travail au prochain sprint automatiquement.

Mon deuxième conseil est : Résistez à l’envie de reporter automatiquement le travail inachevé au prochain sprint. Mettez-le plutôt dans le backlog du produit.

L’item peut être de retour dans le backlog du produit pendant une milliseconde, mais le product owner doit décider consciemment de continuer à travailler dessus.

(D’un point de vue logistique, je me fiche qu’il soit plus facile dans l’outil de votre choix de déplacer l’élément vers le sprint suivant plutôt que vers le backlog du produit en premier. L’essentiel est qu’il y ait une vraie décision de poursuivre le travail.)

Si le Product Owner décide que l’équipe doit travailler sur l’élément partiellement fini immédiatement lors du prochain sprint, importez l’élément du backlog de produit tel quel. Ne le réestimez pas. Ne le renommez pas. Ne prenez pas de crédit de vélocité partielle. Il suffit de mettre l’élément dans le sprint suivant et de prendre le crédit complet lorsqu’il est terminé.

Mais si l’article est reporté à plus tard, allez-y et divisez l’histoire en ce qui a du sens. Prenez un crédit partiel de vélocité pour le travail que vous avez effectué lors du dernier sprint, puis rédigez une nouvelle histoire qui décrit uniquement les fonctionnalités manquantes et estimez cette histoire.

#3 – Documentez la cause.

Mon dernier conseil pour manager le travail inachevé est le suivant : A chaque fois qu’un travail est inachevé à la fin d’un sprint, l’équipe doit prendre le temps de la rétrospective pour déterminer si ceci était évitable.

Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, comme un membre de l’équipe malade ou un problème découvert tard dans le sprint qui n’aurait pas pu être détecté plus tôt. Parfois, c’est juste le résultat d’une cible trop élevée pour un sprint.

Mais vous pourriez découvrir quelque chose qui devient une mauvaise habitude.

Quelle qu’en soit la cause, il est toujours utile de se demander si quelque chose peut être fait pour éviter que cela n’affecte les sprints futurs afin que votre équipe puisse réussir avec l’agilité.

Rejoignez 120 000+ autres personnes et recevez un petit conseil par semaine pour améliorer votre utilisation d’agile ou de Scrum directement dans votre boîte de réception chaque jeudi.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.