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

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.

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.

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.

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)

N’échouez pas rapidement, échouez consciemment.

Dans cette vidéo, Leticia Gasca demande aux leaders d’entreprises de s’ouvrir au sujet de leurs échecs, et plaide en faveur du remplacement de l’idée d’échouer rapidement par un nouveau mantra : Échouer consciemment.

Disponible avec sous titrages en français si vous préférez.

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

Le pouvoir de l’amélioration continue

Très souvent, les gens s’attendent à ce que les changements se produisent instantanément. Mais les changements demandent du temps et des efforts continus dans la durée.

The Power of Continuous Improvement par Zuzi Sochová

https://agile-scrum.com/2025/04/22/the-power-of-continuous-improvement/

Très souvent, les gens s’attendent à ce que les changements se produisent instantanément. Ils sont impatients, ils veulent tout maintenant. Mais les changements demandent du temps et des efforts.

Le changement n’est certainement pas une activité simple ; Cela ne se passe jamais comme vous l’avez prévu.

Pour réussir le changement dans votre organisation, vous devez être créatif, innovant et ludique. Et en plus de cela, vous devez être patient. L’une des raisons pour lesquelles j’aime Scrum, c’est qu’il est incrémentiel et itératif non seulement dans la création de valeur pour les clients, mais aussi dans sa propre mise en œuvre. Étape par étape, vous déterminez ce que signifie être agile pour nous, comment utiliser Scrum et comment vous devez mettre en œuvre les différents artefacts et événements. Il n’y a pas de recette de cuisine, vous devez trouver votre propre chemin.

Au début, ne cherchez pas la perfection, commencez simplement par tout ce qui est suffisamment bon. Vous devez avoir une équipe qui peut apporter au moins une sorte de valeur limitée. Une équipe qui a une chance de devenir au moins un peu interfonctionnelle. Une équipe qui, au fil du temps, peut prendre en charge la responsabilité et l’appropriation et devenir autogérée. Une fois que vous avez ce point de départ, une équipe prête à essayer, tout ce dont vous avez besoin est d’inspecter fréquemment et de vous adapter progressivement. De petites, petites itérations. À chaque itération, vous découvrez ce qui fonctionne et le faites rester ; Chaque itération révèle ce qui doit être amélioré et propose une étape exploitable pour le prochain sprint afin de l’améliorer. Il n’est pas nécessaire que ce soit un grand changement, bien au contraire. Les petits pas fonctionnent généralement beaucoup mieux. De cette façon, ils peuvent être essayés en toute sécurité et sont plus susceptibles de se produire. Ils n’ont pas l’air de pouvoir changer le monde instantanément, mais si vous regardez en arrière où vous étiez il y a six mois, vous vous rendez compte que vous avez fait un grand pas.

Dans l’ensemble, je dirais que si vous ne retirez rien du cadre de travail Scrum hormis les rétrospectives, que vous les faites régulièrement et que vous vous assurez qu’elles apportent des changements progressifs, vous vous retrouvez à un stade bien meilleur que vous ne l’avez été auparavant.

Être agile, c’est être adaptable.

Soyez créatif et allez-y une étape à la fois. Jouez avec le changement. Un changement progressif est la pratique clé qui peut vous rendre vraiment agile. Ce n’est pas une question d’outils. C’est une façon différente de penser, et les changements progressifs sont un élément clé de cette nouvelle façon de penser et d’aborder les choses.

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

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.

 

 

Comment favoriser une compréhension partagée de l’agilité pour vos équipes.

Lorsque les organisations n’obtiennent pas les résultats qu’elles attendent de l’agilité, je constate souvent que l’ingrédient manquant est une compréhension commune de ce que signifie être agile. Mike Cohn

How to Foster a Shared Understanding of Agile for Your Teams par Mike Cohn

https://www.mountaingoatsoftware.com/blog/how-to-get-teams-aligned-on-what-it-means-to-be-agile

Bien que les cadres de travail agiles comme Scrum offrent une structure, ils sont délibérément incomplets pour permettre la flexibilité. Cette même flexibilité, cependant, peut créer de l’ambiguïté et conduire à des interprétations incohérentes entre les équipes. Et cette incohérence peut devenir un obstacle important à l’obtention de tous les bénéfices de l’agilité, mais il y a certaines choses que vous pouvez faire.

Résistez à la tentation de(tout) standardiser.

Souvent, les organisations confrontées à de multiples interprétations de l’agilité essaient à tort de créer une cohérence par le biais de règles strictes et standardisées entre toutes les équipes.

À première vue, cela semble être une approche efficace. Si tout le monde suit les mêmes règles, tout le monde sera sûrement sur la même longueur d’onde ? Peut-être, mais c’est rarement une bonne longueur d’onde.

L’un des principes fondamentaux de l’agilité est l’inspection et l’adaptation. Cela ne s’applique pas seulement aux produits : Cela doit être appliqué à l’utilisation de l’agilité elle-même.

Au début d’une initiative agile, je pense que les équipes doivent rester très proches de ce qui est prescrit dans l’approche agile de leur choix, qu’il s’agisse de Scrum, Kanban, Extreme Programming, SAFe ou n’importe quelle autre.

Chacun de ces cadres de travail fait un bon effort pour placer des garde-fous (ou des contraintes) sur les équipes qui les empêcheront de s’éloigner des concepts agiles critiques. C’est important, car les équipes qui apprennent à être agiles n’ont pas nécessairement les connaissances ou l’expérience nécessaires pour décider quelles pratiques d’un cadre de travail peuvent être modifiées.

Mais dès que les équipes acquièrent de l’expérience, elles doivent avoir la liberté d’inspecter et d’adapter leur processus. Lorsqu’une organisation verrouille sa définition des pratiques agiles acceptables de manière trop rigide ou trop longue dans le parcours d’une équipe, ces dernières perdent leur sentiment d’autonomie.

La durée des itérations en est un bon exemple : Il est fort probable que, quelle que soit votre organisation, les équipes bénéficient d’itérations de différentes longueurs. J’ai vu une même durée d’itérations imposée trop de fois simplement parce que quelqu’un voulait recevoir des rapports d’avancement de toutes les équipes aux mêmes dates.

Évidemment, les équipes dont le travail est très imbriqué peuvent tout à fait bénéficier d’un accord sur une durée de sprint commune. Et, si c’est le cas, les équipes elles-mêmes le découvriront probablement sans que cela ne soit dicté.

Une organisation ne devrait pas dicter des règles qu’une équipe devrait choisir par elle-même. C’est un peu comme une règle dictant que je dois manger des tacos une fois par semaine ; Je le ferai quand même sans cette règle.

Une entreprise de développement de jeux avec lequel j’ai travaillé accordait plus d’attention au respect des règles de Scrum qu’à l’innovation. On avait dit aux équipes qu’elles devaient tout terminer à la fin de chaque sprint et qu’elles devaient atteindre l’objectif du sprint.

Dans la précipitation pour respecter une date limite de sprint, une équipe a développé des personnages trop grands pour tenir dans les véhicules conçus pour eux par une autre équipe. Cela avait été remarqué au milieu du sprint, mais aucune des deux équipes n’a estimé qu’elle pouvait apporter les changements nécessaires tout en atteignant son objectif de sprint.

Lorsque les équipes n’ont pas la liberté d’adapter les pratiques agiles à leurs besoins, elles se sentent contraintes et désengagées. Ces règles descendantes suggèrent fortement aux équipes que la direction ne leur fait pas confiance pour prendre leurs propres décisions, ce qui érode encore plus le moral.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Une meilleure approche : 3 stratégies pour aligner les équipes sur Agile

Le concept qui sous-tend ces trois conseils est essentiellement que tout le monde respecte les concepts qui sous-tendent l’agilité.

Mais soyons précis :

1. Concentrez-vous sur les principes qui sous-tendent les pratiques

L’agilité n’est pas une question d’adhésion rigide aux pratiques ; Il s’agit des principes qui les inspirent. Bien que les pratiques agiles puissent être utiles, elles ne constituent pas l’objectif final. Au lieu de cela, ce sont les principes qui ont inspiré ces pratiques qui comptent vraiment : Ils offrent la flexibilité nécessaire pour s’adapter et s’améliorer au fil du temps.

Par exemple, le Manifeste Agile met l’accent sur des principes tels que :

  • Les individus et les interactions plutôt que les processus et les outils
  • Réagir au changement plutôt que suivre un plan

Ces principes encouragent les équipes à privilégier la collaboration, la communication et l’adaptabilité. En se concentrant sur les intentions agiles, les équipes peuvent adapter leurs pratiques pour mieux s’adapter à leur contexte et à leurs défis uniques.

Une fois qu’une équipe a acquis suffisamment d’expérience et comprend parfaitement l’intention de chaque principe agile, elle doit expérimenter pour trouver ce qui fonctionne le mieux pour elle.

Un facteur de succès essentiel est qu’une équipe s’approprie son processus. Je ne suis pas opposé à ce qu’une organisation impose des règles aux équipes. Mais il doit s’agir de règles faciles à suivre et non en opposition avec les principes agiles. Il est logique de normaliser l’utilisation d’un outil à l’échelle de l’entreprise, tout comme d’établir une durée maximale d’itération.

N’oubliez pas que les équipes, au fur et à mesure qu’elles acquièrent de l’expérience, doivent être en mesure d’explorer les variations qui correspondent à leurs objectifs et à leurs valeurs. C’est ainsi qu’elles créent un processus agile plus efficace et durable qui répond vraiment à leurs besoins.

2. Utilisez un langage et des définitions partagés

L’un des plus grands obstacles à l’alignement est l’incohérence dans la terminologie utilisée. Lorsque différentes équipes utilisent des termes différents pour les mêmes pratiques, il y a de la confusion et des problèmes de communication.

Par exemple, sprint et itération signifient la même chose. Une équipe utilisant l’un de ces termes n’aura généralement aucun problème à communiquer avec une équipe utilisant l’autre. Mais une équipe avec laquelle j’ai travaillé a utilisé le sprint pour désigner une itération dans laquelle les membres de l’équipe devaient faire des heures supplémentaires pour atteindre leurs objectifs.

Personne dans les autres équipes ne le savait jusqu’à ce que quelqu’un demande avec désinvolture : « Pourquoi utilisez-vous les deux termes ? »

Il y a certaines choses que vous pouvez faire pour réduire les malentendus.

  1. Standardisez la terminologie : Créez un glossaire des termes couramment utilisés dans les pratiques Scrum et agiles. Ce glossaire devrait être accessible à tous et régulièrement mis à jour pour refléter les modifications ou les nouveaux termes introduits.
  2. Formation et ateliers : Organisez régulièrement des sessions de formation et des ateliers pour éduquer les membres de l’équipe sur les principes et les pratiques de Scrum. Organisez des sessions d’intégration pour les nouveaux membres de l’équipe et des cours de remise à niveau pour les membres existants.
  3. Utilisez des outils de communication : Tirez parti d’outils tels que les wikis, les intranets et les grands tableaux visibles pour diffuser des informations et fournir un emplacement centralisé pour le partage des connaissances. Utilisez plusieurs méthodes pour vous assurer que tout le monde a accès aux mêmes informations et définitions.
  4. Facilitez la communication ouverte : Encouragez une communication facile et transparente lors des standups, des revues et des rétrospectives quotidiennes. Les membres de l’équipe doivent se sentir à l’aise pour discuter de leurs progrès, de leurs difficultés et de toute divergence de compréhension, sans crainte.
  5. Ne combattez pas le vocabulaire de votre outil : Si vous utilisez un outil pour gérer le travail d’une équipe, ne vous battez pas avec sa terminologie. Même si je ne suis pas d’accord avec la façon dont Jira abuse du terme épopée, je suis d’accord avec ça lorsque je travaille avec Jira.
  6. Établissez des communautés de pratique : Il s’agit de groupes de personnes partageant les mêmes idées ou les mêmes compétences qui se réunissent volontairement en raison de leur passion et de leur engagement commun autour d’une technologie, d’une approche ou d’une vision. Elles aident à combler les écarts entre les différentes équipes, facilitant ainsi la diffusion des bonnes pratiques, de la cohérence et des connaissances au sein d’une organisation.

Dans une entreprise, le leader de l’initiative agile a insisté sur une définition de ce que signifiait être agile. Il l’a fait parce que, dans une organisation précédente, il avait vu des équipes appliquer l’étiquette agile à leurs approches très peu agiles. Lorsque ceux-ci échouaient inévitablement, l’agilité développait une mauvaise réputation.

Dans sa nouvelle organisation, il insistait sur le fait qu’une équipe ne pouvait se qualifier d’agile que si elle travaillait avec des règles comme les suivantes :

  • Mettre en production le code fonctionnel au moins toutes les deux semaines.
  • Avoir une seule personne pour guider la vision et le travail de l’équipe (c’est-à-dire un propriétaire de produit ou manager).
  • Effectuer des stand-ups quotidiens.
  • Organiser une rétrospective au moins une fois par mois.

3. Comprenez comment les leaders aident les équipes agiles à réussir

Le leadership joue un rôle essentiel dans l’alignement des équipes sur les principes agiles. Lorsque les leaders agiles modélisent les comportements qu’ils souhaitent voir, ils envoient un message clair que l’agilité n’est pas seulement un ensemble de règles, mais un état d’esprit et une culture à incarner.

Les leaders doivent adopter des valeurs agiles telles que l’adaptabilité, la collaboration et la transparence. En montrant qu’ils donnent la priorité à ces valeurs, les leaders créent un environnement où les équipes se sentent habilitées à vivre les principes agiles et à expérimenter des pratiques agiles.

Voici quelques mesures spécifiques que les leaders peuvent prendre :

  1. Responsabilisation et autonomie : Les leaders doivent permettre aux équipes de s’auto-organiser et de prendre des décisions. Prenez du recul et laissez les équipes travailler sans interférence. Les équipes développent un sentiment d’appartenance et de responsabilité pour les résultats qu’elles obtiennent de cette façon.
  2. Écoute active : Les leaders doivent pratiquer l’écoute active. Écoutez vraiment ce que disent les membres de l’équipe, comprenez leurs défis et fournissez un soutien sans dicter de solutions. Cette approche favorise une culture de confiance et d’ouverture.
  3. Encourager l’expérimentation : Les meilleures équipes sont celles qui sont prêtes à essayer de nouvelles choses. Les leaders doivent favoriser un état d’esprit d’expérimentation, où les équipes sont motivées à réfléchir à leurs processus et à mettre en œuvre des améliorations potentielles à chaque itération. Cette amélioration continue est au cœur de la réussite agile. Pour encourager l’expérimentation, les leaders ne peuvent pas se mettre en colère lorsqu’une expérience ne fonctionne pas.
  4. Équilibrer les priorités : Les leaders doivent reconnaître que chaque oui a un coût. En comprenant les compromis à faire lors de la sélection d’un objectif plutôt qu’un autre, les leaders peuvent aider les équipes à se concentrer sur ce qui compte vraiment, en évitant les pièges de l’engagement excessif et de l’épuisement professionnel.
  5. Lâcher prise des idées personnelles : Il est important que les leaders soient ouverts aux idées des autres et ne soient pas trop attachés aux leurs. La flexibilité crée un environnement où la diversité des points de vue est valorisée, ce qui permet d’obtenir des solutions plus innovantes.
  6. Modéliser les valeurs agiles : Les leaders doivent incarner les valeurs fondamentales de l’agilité, telles que la collaboration, la transparence et l’adaptabilité. « Joindre le geste à la parole » pour établir une norme à suivre par l’équipe, en renforçant l’état d’esprit agile dans toute l’organisation.
  7. Soutenir l’apprentissage continu : Il est crucial d’encourager les équipes à tirer des leçons à la fois des réussites et des échecs. Les leaders facilitent cela en offrant des opportunités de formation, d’ateliers et de rétrospectives, où les équipes peuvent réfléchir à leurs expériences et identifier les domaines de croissance.

Des parcours de formation qui facilitent l’alignement des équipes

La formation et les ateliers sont utiles pour acquérir une connaissance commune des principes et des pratiques. Mais il peut être difficile d’essayer de coordonner les calendriers de formation de plusieurs équipes.

C’est l’une des raisons pour lesquelles Mountain Goat Software a conçu ses Flex and Select Passes.

Choisir les pratiques de management de projet hybride par Alan Zucker

Les projets hybrides ne sont pas limités par une méthodologie unique ou un cadre bien défini.  Par définition, il s’agit d’un mélange de pratiques.

http://www.planningplanet.com/blog/hybrid-project-management-part-4-picking-practices

Relisez ou découvrez les articles précédents :

  1. Management de projet hybride : Qu’est-ce que l’hybride ?
  2. Management de projet hybride : Quels changements ?
  3. Choisir l’approche de management de projet hybride

Les projets hybrides ne sont pas limités par une méthodologie unique ou un cadre bien défini.  Par définition, il s’agit d’un mélange de pratiques.  Une énorme responsabilité accompagne cette liberté de choix illimitée.  Les managers de projet doivent décrire clairement comment le projet sera exécuté pour réussir.

Se dérober à cette responsabilité est fort préjudiciable. La recherche (PMI® A New Way Forward) démontre que la maturité et la cohérence améliorent les résultats des projets.  Sans aucun processus, nous suscitons le chaos.

Des centaines d’options et de points de décision doivent être pris en compte lors de la description du plan de management ou d’exécution du projet.  Le Boîte à outils Disciplined Agile Toolkit  décrit plus de 150 décisions (options) pour l’organisation et l’exécution d’un projet. Capterra répertorie plus de 1500 outils logiciels de management de projet.

Les managers de projet hybrides doivent planifier intentionnellement. Cet article identifie certaines pratiques fondamentales qui devraient être utilisées dans chaque projet.  L’instanciation de ces pratiques sera adaptée au contexte du projet.

Établissez la charte de projet (Project Charter).

La Charte de projet définit l’approche de travail.  Elle établit les attentes et les compréhensions initiales entre les parties prenantes et l’équipe de projet. Elle documente les objectifs, les exigences et les contraintes de haut niveau, le rôle du manager de projet et de nombreux autres éléments. Le niveau de formalisme et les composantes seront basés sur les exigences de l’organisation et du projet.

Il peut être difficile de créer un alignement et trouver un accord entre les parties prenantes du projet. Le processus de définition de la charte du projet crée un forum pour faire apparaître et résoudre les conflits d’intérêt et les objectifs mal alignés, en minimisant les retards et en évitant la nécessité d’avoir à refaire certains éléments plus tard.

Créez un plan de management.

Le Plan de management de projet documente la façon dont le projet sera exécuté. Il doit être adapté au contexte du projet. Un plan de management de projet bien défini est crucial pour les projets hybrides puisqu’il n’existe pas de standard opérationnel.

Le plan établit les attentes et renforce la compréhension au sein de l’équipe de projet. Il définit et décrit les rôles, les responsabilités et les processus. Le format et le niveau de détail doivent être adaptés au contexte du projet.  Un bon plan augmente les chances de réussite du projet et réduit les inefficacités et les conflits.

Définissez le périmètre et construisez l’échéancier.

Les deux éléments de planification les plus critiques sont la définition de ce qui sera livré (portée/contenu) et du moment (échéancier/délais). Sans cela, les projets pataugent comme un navire sans gouvernail.  Le type de projet et l’environnement opérationnel influencent les pratiques et les outils utilisés.

Les projets traditionnels ont des spécifications détaillées, utilisent généralement un échéancier basé sur un diagramme de Gantt, et un processus rigoureux de management du changement.

Les projets Agile ont une portée émergente. Les fonctionnalités et les user stories sont documentées et hiérarchisées dans le backlog du produit.  Les fonctionnalités sont fournies en courtes itérations, souvent de 2 semaines. Les équipes utilisent un Tableau Kanban pour gérer le flux de travail.

Les projets hybrides sont libres de définir leurs propres pratiques de planification. Ils peuvent suivre les contours généraux de l’approche traditionnelle ou agile, combiner les meilleures pratiques, telles que la Technique des jalons Kanban (Milestone-Kanban Schedule), ou suivre un processus sur mesure.

Les projets simples n’ont besoin que d’une feuille de route de haut niveau et d’une liste de contrôle pour maintenir la coordination de l’équipe et le projet sur la bonne voie.

Visualisez le travail.

Les projets sont des entreprises complexes qui génèrent une pléthore de données. Il peut être difficile de corréler, de comprendre et de prendre des décisions éclairées. Malgré nos meilleures intentions, nous négligeons ou ne remarquons souvent pas les signes avant-coureurs de problèmes.

Les gens sont visuels. Nous reconnaissons rapidement les modèles graphiques. L’utilisation d’outils visuels de management de projet améliore considérablement la capacité du manager de projet et de l’équipe à comprendre le projet, son avancement et ses challenges.  Ces outils peuvent être sophistiqués, mais souvent plus c’est simple, mieux c’est.

Les feuilles de route, les tableaux Kanban et les tableaux de bord sont faciles à utiliser et transmettent rapidement des informations précieuses. Les versions physiques de ces outils fabriquées avec du ruban adhésif et des notes autocollantes sur le mur sont faciles à construire et à ajuster. Des outils collaboratifs peuvent être utilisés pour les équipes virtuelles et promouvoir la transparence, la responsabilité et la collaboration.

Managez les risques, les actions et les problèmes.

Le management proactif des risques, des actions et des problèmes est une activité fondamentale. Le manager de projet doit régulièrement inspecter l’environnement, consigner, suivre et traiter les éléments en cours. Il doit y avoir une cadence et un processus réguliers au niveau de l’équipe et de la direction, avec une appropriation et une responsabilité claires. Cela permet à l’équipe de projet de ne pas négliger ou oublier des éléments critiques qui pourraient faire dérailler le projet.

Le détail et la profondeur de ces pratiques doivent être adaptés aux besoins du projet.  L’outil le plus basique peut être une simple feuille de calcul.  Les applications plus sophistiquées peuvent intégrer et hiérarchiser des éléments dans plusieurs flux de travail, créer des rapports de tableau de bord et fournir des alertes.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Adoptez l’amélioration continue.

Il n’y a pas une seule et unique « bonne façon » de manager tous les projets.  Les projets sont des organismes vivants.  Les processus et les pratiques doivent s’adapter et s’améliorer continuellement à mesure que l’équipe et leurs organisations mûrissent et s’adaptent aux événements business externes.

Tous les projets doivent adopter une version de la rétrospective de l’équipe Agile.  Régulièrement, l’équipe examine ses performances, identifie les améliorations et les met en œuvre.  Ensuite, l’équipe confirme que les changements ont été bénéfiques.

Évaluez le processus.

Toutes les grandes organisations ont des gaspillages.  Il y a des retards excessifs, des transferts de tâches et du travail inutile.  Si nous voulons nous améliorer, nous devons faire en sorte qu’il soit plus facile pour nos équipes de fournir plus rapidement de la valeur et des solutions.

Nos processus d’entreprise et nos normes formelles sont souvent conçus pour résoudre des problèmes du passé.  Des correctifs et des pansements ont été appliqués au hasard pour répondre à des préoccupations immédiates plutôt que d’utiliser la pensée systémique et d’envisager une meilleure façon de faire les choses.

Changez les processus !  Examinez d’un œil critique ce que vous faites.  Vos processus apportent-ils une valeur ajoutée ?  Si ce n’est pas le cas, éliminez-les.  S’ils sont nécessaires, rendez-les moins lourds.

Responsabilisez l’équipe.

Les équipes autonomes excellent dans la résolution de problèmes complexes.  Les équipes produisent de meilleurs résultats que les individus seuls.  De multiples perspectives sont prises en compte et intégrées dans la solution.  Libérer le pouvoir créatif d’équipes motivées et engagées est fantastique.

Nous créons des équipes responsabilisées en poussant la prise de décision au niveau responsable le plus bas.  Les personnes les plus proches du travail connaissent le mieux le processus et sont les plus proches de l’information.  Lorsqu’elles prennent leurs propres décisions, elles sont responsables et se sentent redevables.

L’autonomisation est plus facile à dire qu’à faire.  Cela nécessite souvent de réinitialiser la culture, les normes et les standards de l’équipe et de l’entreprise.  La micro management doit être remplacé par un état d’esprit de donner son meilleur et de coaching.  Lorsque nous punissons les erreurs, elles ne s’arrêtent pas.  Elles deviennent cachées, et l’impact s’aggrave.

Ayez des processus cohérents et reproductibles.

Ne recherchez pas la standardisation.  Les projets sont uniques.  Nous ne produisons pas des gadgets.  Efforcez-vous d’assurer cohérence et répétabilité.  Développez et affinez en permanence des pratiques de management de projet contextuelles qui permettent la personnalisation.  Élaborez des modèles de livraison qui favorisent l’efficacité, la durabilité et la répétabilité.

© 2024, Alan Zucker ; Project Management Essentials, LLC

Vendez Agile à vos prospects et clients.

Vendre le travail en approche Agile à vos interlocuteurs est SIMPLE.

Sell Agile to Customers par Zuzi Sochova

https://agile-scrum.com/2024/12/11/sell-agile-to-customers/

Les gens me demandent souvent comment vendre une approche de travail agile à leurs clients. En particulier aux clients qui sont habitués à une méthode de travail traditionnelle, aux clients qui sont habitués à définir leurs exigences et à la définition figée de la portée, du temps et du budget, et aux clients qui sont habitués à une phase d’analyse initiale importante.

Ne vous attendez pas à de la magie. Vendre est simple.

Tout ce que vous avez à faire est de montrer la valeur. Montrez-leur ce qui les attend. Parce que s’ils ne comprennent pas le type de valeur qu’ils obtiennent avec cette nouvelle façon de travailler, tout ce qu’ils ont, c’est peur. Peur de l’inconnu, peur de l’échec, peur du changement. Commencez toujours par le pourquoi. Aucun changement ne se produira à moins que vous ne créiez un sentiment d’urgence.

La valeur qu’ils obtiennent variera en fonction de la situation et de leur expérience, donc mon meilleur argumentaire de vente commence toujours par des questions.

  • Que diriez-vous de votre expérience actuelle ?
  • Quelles sont les douleurs typiques ?
  • Qu’est-ce qui marche bien ?
  • Qu’est-ce qui est important pour vous ?

J’essaie d’être ouverte à de nouvelles perspectives et curieuse de leur situation. Ensuite, sur la base de ce qu’ils disent, j’essaie de proposer une nouvelle façon de travailler.

« Nous faisons *quelque chose de différent* afin que *ceci* et *cela* ne se produisent pas. »

Plus vous vous rapprochez de leur langage, mieux c’est. En règle générale, vous devez adresser les problèmes suivants: Le manque de transparence, l’incompréhension des besoins du client, le non-respect du budget et/ou des problèmes de qualité.

Ils demandent aussi souvent une référence, alors soyez prêt à en donner une.

Le plus important est que vous ne pouvez vendre que des choses en lesquelles vous croyez vraiment. Il est bon d’avoir déjà une certaine expérience, non seulement pour avoir une référence, mais aussi pour votre confiance en vous. Il est toujours visible à partir de votre langage corporel de voir si vous y croyez ou pas.

De plus, il est difficile de répondre à leurs questions curieuses de détails sur votre travail si vous ne l’avez jamais expérimenté.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Les billets DantotsuPM qui furent les plus lus au mois de Septembre 2024

Bonjour, voici les billets du blog DantotsuPM qui furent les plus appréciés au mois de Septembre 2024.

Les lectrices et lecteurs ont apprécié ces thématiques et conseils :

  • 10 nouvelles tendances en matière de gestion de projet en 2024 par Elissa Farrow et Harold Kerzner.
  • PMO versus contrôles de projets.
  • Daily Scrum – Un format simple pour arriver à « Done » par Sam Adesoga.

10 nouvelles tendances en matière de gestion de projet en 2024 par Elissa Farrow, Ph.D. et Harold Kerzner, Ph.D.

PMO vs contrôles de projet

Daily Scrum – Un format simple pour arriver à « Done » par Sam Adesoga

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Les billets DantotsuPM qui furent les plus lus en Août 2024

Bonjour, voici les billets du blog DantotsuPM qui furent les plus appréciés en Août 2024.

Les lectrices et lecteurs ont apprécié les sujets: Conduite du changement, Bien découper les User Stories et Réussir sa transformation Agile.

  • « La conduite du changement dans les projets de transformation, retour d’expérience autour de quelques incontournables » par Olivia LE JEUNE et Jean-Roch HOULLIER.
  • SPIDR : 5 façons simples mais puissantes de découper les histoires utilisateur / user stories.
  • PMO adaptatif : 13 pratiques qui fonctionnent pour une transformation Agile

« La conduite du changement dans les projets de transformation, retour d’expérience autour de quelques incontournables » par Olivia LE JEUNE et Jean-Roch HOULLIER

SPIDR : 5 façons simples mais puissantes de découper les histoires utilisateur / user stories

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

13 pratiques qui fonctionnent pour une transformation Agile