« 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.

« Scrum ne fonctionnerait jamais pour nous ici… Ou le ferait-il ? » par Sam Adesoga

« Scrum ne fonctionnerait jamais ici ! »

Scrum Would Never Work for Us Here… Or Would It?

https://samadesoga.me/posts/scrum-would-not-work-for-us/

C’est une phrase que j’ai entendue d’innombrables fois, et elle reflète souvent une résistance plus profonde au changement ou une incompréhension de ce qu’est vraiment Scrum. S’il est vrai que Scrum n’est pas une solution unique, il s’agit d’un cadre incroyablement puissant pour les équipes axées sur la livraison de produits. Lorsqu’il est correctement mis en œuvre, Scrum peut transformer la façon dont les équipes travaillent, hiérarchisent les priorités et créent de la valeur.

Alors, pourquoi tant d’équipes ont-elles du mal avec Scrum ?

D’après mon expérience, la résistance se résume souvent à 3 problèmes clés :

  1. L’incapacité à établir des priorités, ce qui entraîne trop de « travail en cours » et un manque de concentration.
  2. Un manque de compréhension de l’établissement d’objectifs et de son impact sur le moral et la productivité de l’équipe.
  3. Un manque de confiance entre l’équipe et ses parties prenantes.

Ironiquement, ce sont précisément les raisons pour lesquelles Scrum peut être si efficace. Voyons comment Scrum relève ces défis, en particulier à travers le prisme de la définition d’objectifs.

Le pouvoir des objectifs : objectifs de produit et de sprint

En 2020, le Scrum Guide a explicitement introduit les concepts d’objectifs de produit et d’objectifs de sprint, et pour de bonnes raisons. Ces objectifs servent d’étoile polaire pour les équipes, apportant clarté, concentration et un sens commun de l’objectif.

Pourquoi les objectifs sont importants

Les objectifs ne sont pas seulement des choses agréables à avoir ; Ils sont essentiels pour une livraison efficace des produits.

Ils:

  • Fournissent une orientation claire à l’équipe et aux parties prenantes.
  • Aident à suivre les progrès et à mesurer le succès.
  • Alignent tout le monde autour d’un objectif commun.

Pourtant, de nombreuses équipes font à cet exercice à l’envers. Elles commencent par définir le « quoi » (les tâches ou les éléments du backlog), puis essaient d’adapter un « pourquoi » (l’objectif) autour d’eux. Cette approche conduit souvent à la confusion, au désalignement et à la déperdition d’efforts.

Le Scrum Framework renverse la situation. Il encourage les équipes à commencer par le « pourquoi », c’est-à-dire la raison impérieuse derrière le travail, puis à l’utiliser pour définir le « quoi ». En d’autres termes, créez d’abord l’objectif, puis laissez-le guider la création des éléments du backlog de produit.

Cette logique s’applique à la fois au Product Goal (objectif intermédiaire) et au Sprint Goal (objectif tactique). Ensemble, ils créent une feuille de route qui guide les efforts de l’équipe et assure l’alignement avec les attentes des parties prenantes.

Créez les objectifs grâce à la collaboration

L’une des idées fausses les plus courantes sur Scrum est que les objectifs sont dictés du haut vers le bas. En réalité, l’établissement d’objectifs efficaces est un processus collaboratif qui implique l’ensemble de l’équipe et ses parties prenantes.

Objectifs du produit

L’objectif du produit est l’objectif global vers lequel l’équipe travaille. Ce n’est pas quelque chose que le Product Owner imagine seul. Au lieu de cela, il s’agit d’une suggestion ou d’une idée, qui est ensuite affinée et finalisée en collaboration avec les parties prenantes, y compris les développeurs. Cela permet de s’assurer que l’objectif est à la fois ambitieux et réalisable.

Objectifs du sprint

De même, l’objectif de sprint est un tremplin vers l’objectif du produit. Ce n’est pas transmis à l’équipe ; il est co-créé pendant la planification du sprint. L’équipe discute de l’objectif, évalue sa faisabilité et s’engage à le livrer d’ici la fin du Sprint.

Cette approche collaborative favorise un sentiment d’appartenance et de responsabilité. Lorsque tout le monde participe à la création des objectifs, ils sont plus susceptibles de s’investir dans leur réalisation.

L’un des arguments contre l’adoption de Scrum est le désir de jongler avec plusieurs objectifs simultanément.

Bien que cela puisse être une préoccupation légitime, il existe des stratégies pour l’atténuer :

  1. Raccourcissez les délais : Réduisez la période de temps dédiée pour atteindre l’objectif du produit, par exemple, de trois mois à un mois. Cela rend l’objectif plus gérable et permet des boucles de rétroaction plus rapides.
  2. Élargissez l’objectif : Créez un objectif plus large qui offre une valeur significative dans la période temps choisie. Cela permet à l’équipe de rester concentrée sans se sentir débordée.

Ces stratégies aident les équipes à maintenir la clarté et le momentum, même lorsqu’elles sont confrontées à des priorités concurrentes.

Le rôle de la confiance et de la concentration

Scrum ne concerne pas seulement les processus et les objectifs ; Il s’agit de personnes. Pour que Scrum fonctionne, les équipes ont besoin de confiance, de soutien et de liberté pour se concentrer.

Confiance : Lorsque les parties prenantes font confiance à l’équipe pour respecter ses engagements, cela crée une boucle de rétroaction positive. L’équipe se sent responsabilisée et les parties prenantes voient des résultats cohérents.
Concentration : Les équipes sont plus performantes lorsqu’elles peuvent se concentrer sur leurs objectifs sans interruptions intempestives. Cela signifie qu’il faut réserver des capacités dédiées aux tâches non planifiées (comme le travail réglementaire ou de conformité) tout en veillant à ce que la majorité des efforts de l’équipe soient consacrés à la réalisation de ses objectifs de sprint et de produit.

Au fil du temps, les équipes qui adoptent des objectifs ambitieux mais réalisables développent un moral plus élevé et un sens plus fort de raison d’être. Elles deviennent plus autonomes, productives et alignées sur les besoins des utilisateurs.

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

Faites en sorte que Scrum travaille pour vous !

L’expression « Scrum ne fonctionnerait jamais pour nous ici » découle souvent d’un manque de compréhension ou d’une mauvaise application du cadre de travail Scrum. Mais lorsqu’il est mis en œuvre correctement, en mettant l’accent sur la collaboration, la définition d’objectifs et la confiance, Scrum peut changer la donne pour les équipes de livraison de produits.

Si votre équipe a du mal à établir des priorités, à s’aligner ou à garder le moral, envisagez d’essayer Scrum. Commencez par définir des objectifs clairs et convaincants. Impliquez votre équipe et vos parties prenantes dans le processus. Plus important encore, créez un environnement où la confiance et la concentration peuvent prospérer.

Scrum n’est pas une solution miracle, mais un outil puissant pour développer l’agilité et créer de la valeur. La question n’est pas de savoir si Scrum peut fonctionner pour vous, mais si vous êtes prêt à adopter les principes qui le font fonctionner.

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


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.

 

 

Le premier rapport annuel sur l’état de SAFe, le « State of SAFe Report » a été publié !

« State of SAFe Report 2025 » – Simplifier les directives, les rendre plus pratiques, plus adaptables, et se focaliser sur les résultats business !

https://framework.scaledagile.com/blog/the-first-annual-state-of-safe-report-has-been-released par Steve Mayner

Scaled Agile a lancé un effort de recherche sur les retours des clients et utilisateurs SAFe et c’est le plus important de son histoire : State of SAFe Report 

Téléchargez ce rapport en langue anglaise.

Ce rapport 2025 donne un bon aperçu et analyse les informations partagées dans les réponses à l’enquête.

Sur de nombreux sujets, les commentaires reçus soutiennent la nécessité de simplifier les directives, de les rendre plus pratiques et adaptables, et de se concentrer davantage sur les résultats opérationnels plutôt que sur les processus.

La nécessité pour Scaled Agile de rendre SAFe encore plus facile à adapter en sort encore renforcée.

Et vous, quels sont vos retours pratiques sur SAFe ?

https://scaledagile.com/resources/state-of-safe-report/

© Scaled Agile, Inc.

AgilePM® : 3 documents en langue anglaise produits par APMG International sur la V3

AgilePM v3 est conçu pour vous aider à apporter plus de valeur, à manager le changement en toute confiance et à faire évoluer vos projets comme jamais auparavant.

APMG International vous offre un accès exclusif à trois ressources essentielles qui mettent en évidence pourquoi la version 3 se démarque comme la meilleure approche Agile. Ces documents vous aideront à approfondir votre compréhension et à appliquer efficacement les principes d’AgilePM.

3 documents gratuits

Voici ce que vous recevrez:

  1. The AgilePM Value Blueprint: un guide stratégique pour maximiser les avantages d’AgilePM. Les étapes décrivent un plan pour tirer le meilleur parti de vos projets grâce à l’application pragmatique et agile d’AgilePM (v3). Il s’agit d’un parcours en cinq étapes pour atteindre la maîtrise et libérer de la valeur pour vos clients, votre entreprise et vous-même.
  2. Les résultats de l’enquête « AgilePM Candidate Survey »: Les perspectives et attentes de plus de 380 candidats sur leurs expériences AgilePM. A la fois sur la formation pour préparer la certification et sur l’examen en lui-même.
  3. 10 Characteristics of a High-Performing Agile Team and How to Build One : 10 astuces pratiques pour améliorer les performances de votre équipe Agile.

Et relisez l’annonce : La version 3 d’AgilePM® est arrivée !

 

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2 et AgilePM.

PIAF 2025 – Repensez l’agilité pour un avenir durable !

Le 14 mars 2025 aura lieu l’événement incontournable de l’agilité !

Inscrivez-vous rapidement en ligne.

Cette année, Piaf se transforme et se concentre sur une journée intense, riche en apprentissages et en échanges autour du thème : « Repenser l’agilité pour un avenir durable ». Une occasion unique pour les professionnels, leaders et passionnés de l’agilité de découvrir des stratégies novatrices et des solutions pratiques pour créer des organisations résilientes et durables.

Organisé par des experts de renom en agilité, avec le soutien précieux de PMI France, partenaire principal de cette édition, Piaf 2025 propose un programme soigneusement conçu, alternant conférences inspirantes et ateliers interactifs.

Explorez les nouvelles dimensions de l’agilité : écoconception, responsabilité sociétale, adaptation à long terme, et bien plus encore !

Pourquoi participer à Piaf 2025 ?

  • Un contenu avant-gardiste : Découvrez les dernières tendances et pratiques pour intégrer des valeurs durables dans vos projets agiles.
  • Des intervenants inspirants : Rencontrez des experts et des praticiens reconnus de l’agilité, qui partageront leur vision et leur expérience pour transformer vos défis en opportunités.
  • Une communauté engagée : Rejoignez une communauté dynamique de professionnels en quête de sens et d’impact durable, échangez des idées et développez de nouveaux partenariats.

Au programme :

  • Conférences thématiques autour des défis et innovations en agilité durable
  • Ateliers pratiques pour renforcer vos compétences et tester des approches concrètes
  • Rencontres et réseautage avec des experts et des praticiens de l’agilité

Cet événement est l’occasion idéale pour enrichir vos pratiques, repenser votre approche de l’agilité, et contribuer activement à la construction d’un avenir plus responsable.

Rendez-vous le 14 mars 2025 !

Inscrivez vous dès maintenant et soyez au cœur de cette transformation. Ensemble, réinventons l’agilité pour bâtir un avenir résilient.

Cette année, la billetterie sera solidaire :

  • Un accès gratuit pour les étudiants, personnes en recherche d’emploi ou reconversion s’ils le souhaitent.
  • Un accès payant (= solidaire à 20€) pour permettre l’organisation de l’événement et son accès à tous.

La version 3 d’AgilePM® est arrivée !

AgilePM est la principale certification non pas d’approches Agile mais de management de projet agile depuis son lancement en 2014.

La certification Agile Project Management, leader mondial, vient de s’améliorer.

Détails en ligne.

La certification AgilePM a été rapidement adoptée par les organisations mondiales et les gouvernements comme l’un des meilleurs cadres de travail pour le management de projet agile. Aujourd’hui, plus de 200 000 professionnels ont été certifiés en AgilePM pour fournir un management de projet de qualité, et de nombreux employeurs demandent spécifiquement la certification AgilePM pour leurs nouvelles embauches au vu des compétences et des connaissances acquises dans cette formation.

Dans l’esprit agile d’amélioration continue, AgilePM V3 vient d’être amélioré et regorge de nouvelles idées. La nouvelle certification s’aligne sur les progrès des méthodologies agiles, du management de projet, des pratiques business et de la technologie afin d’adopter une approche encore plus centrée sur l’humain.

Principaux changements entre AgilePM V2 et V3.

  • Passez de la livraison du produit à la création de valeur : Allez au-delà de la livraison de produits et créez une valeur business tangible à chaque étape de votre projet.
  • Passez de la gestion de projet au leadership de projet : Passez de chef de projet à leader Agile et amplifiez votre impact.
  • Adoptez SCRUM comme moteur de livraison de produits : Intégrez de manière transparente les pratiques Scrum dans les flux de travail de vos projets pour une agilité accrue de l’équipe.
  • Pour les projets multi-équipes : Appliquez des stratégies avancées pour manager efficacement plusieurs équipes de projet.
  • Pour le management des risques : Appropriez-vous les outils nécessaires pour améliorer la façon dont vous anticipez, évaluez et atténuez les risques de projet dans un environnement agile.
  • Expérience d’apprentissage et d’évaluation améliorée : Participez à une nouvelle simulation d’apprentissage interactive et pratique conçue pour approfondir votre compréhension et votre assimilation.

Téléchargez le guide PDF en anglais AgilePM v2 to v3 – what has changed? pour un résumé des changements.

CertYou est partenaire de DantotsuPM, allez voir les certifications et formations AgilePM !

A propos de valeur asymétrique dans vos projets.

Les projets transforment des contributions élaborées et construites par plusieurs personnes et groupe de personnes en un livrable de plus grande valeur.

Vos projets construisent une énorme valeur qui reste souvent indiscernable pour celle ou celui qui ne regarde que les briques qui la compose. C’est l’assemblage de ces briques qui produit une valeur supérieure.

La valeur dépend aussi de quel côté du mur on se trouve.

De plus, cette « valeur » est le plus souvent asymétrique pour vos parties prenantes et pour tous les bénéficiaires du livrable que construit votre projet.

« 1 tiens vaut mieux que 2 tu l’auras »

La valeur de disponibilité : Beaucoup de personnes préfèrent opter pour quelque chose qu’elles peuvent obtenir immédiatement plutôt que pour quelque chose de plus de valeur mais qu’elles ne sont pas certaines d’obtenir plus tard. La valeur actuelle est souvent plus attrayante qu’une valeur future plus importante. La valeur de votre livrable subit donc souvent une décote pour compenser le risque futur de ne pas l’avoir et le fait de ne pouvoir l’utiliser que plus tard et non pas tout de suite. Il y a un coût à attendre, surtout si le nouveau produit revient moins cher à l’usage que la solution actuelle.

 « Quand on n’a pas les moyens, on pic-nic. » Louis De Funès

La valeur relative : 1€ vaut beaucoup moins pour la personne qui a 100€ en poche que pour celle qui n’a que 5€. Même si vos commanditaires ou clients aiment votre proposition de livrable, peuvent-ils se l’offrir ?

L’asymétrie de la valeur peut donc souvent provenir du délai pour obtenir votre livrable mais aussi de la position actuelle des bénéficiaires (et de chaque bénéficiaire).

D’où l’intérêt des approches Agile qui permettent de délivrer rapidement le plus de valeur possible au moindre coût.

Sans oublier, les processus de management de portefeuilles de projets qui vous aident à sélectionner les projets les plus attractifs en fonction des objectifs de votre organisation et de vos clients pour y concentrer vos efforts et ressources.

Alors, si on vous demande « quelle est la valeur de votre projet », que répondez-vous ?