Après la publication de leur 1er guide de bonnes pratiques en management de projet, l’initiative Lab Hybrid du PMI France se retrouve pour une nouvelle saison.
Cette année s’annonce encore riche en retours d’expérience et propice au développement de nouvelles réflexions autour de l’hybridation.
Disponible sur Amazon
Que vous soyez débutant ou expérimenté en management de projets hybrides, vous avez votre place au sein de l’équipe !
Venez échanger autour de cas pratiques découverts dans le guide ou partager votre propre expérience terrain et apprendre de nouvelles pratiques.
Pour plus d’informations ou envie de contribuer, connectez-vous sur la page PMI France ou contactez l’équipe à l’adresse : labhybrid@pmi-france.org
Les participants à notre formation Scrum me demandent souvent quel est le format que je préfère pour un Daily Scrum. Je ne sais pas si j’ai un format préféré, mais ce n’est certainement pas : « Ce que j’ai fait hier, ce que je prévois de faire aujourd’hui et discussion sur les bloqueurs ».
Cependant, si je peux vous amener à réfléchir à l’objectif du Guide Scrum,
… pour inspecter la progression vers l’objectif de sprint et adapter le backlog de sprint si nécessaire, en ajustant le travail prévu à venir. Guide Scrum, 2020
Un bon format pourrait être :
Les développeurs se remémorent l’objectif du sprint ; ce simple point de départ permet de ramener les objectifs de sprint au centre de l’attention des développeurs.
Passez en revue les éléments du backlog (l’arriéré de produit) dans le Sprint ; Discutez de l’état d’avancement de ces items et soulignez tout problème concernant chacun. Il est important de toujours penser à la « définition de Done » lorsque vous discutez de l’avancement des éléments du backlog qui contribuent à l’objectif du sprint.
Assurez-vous qu’il existe un plan pour progresser vers les objectifs de sprint, par exemple, en s’assurant que chaque membre de l’équipe est clair sur la voie à suivre pour atteindre l’objectif de sprint.
Dans le cadre de l’élaboration du plan pour les prochaines 24 heures, les développeurs doivent prêter attention aux membres de l’équipe qui pourraient avoir besoin d’aide ; des pratiques telles que le mobbing (une approche collaborative où un groupe de membres de l’équipe, souvent l’ensemble de l’équipe, se concentre simultanément sur une seule tâche ou un seul problème) ou le pairing (la programmation en binôme est une technique de développement logiciel Agile dans laquelle deux développeurs font équipe sur un seul ordinateur. Les deux personnes travaillent ensemble pour concevoir, coder et tester des user stories) peuvent aider à faire passer des éléments spécifiques du backlog de sprint à « Done ».
Passez en revue tous les autres éléments du backlog du Sprint Backlog qui ne contribuent pas nécessairement à l’objectif du produit.
Quel que soit le format que vos équipes choisissent d’adopter, il est important que les développeurs comprennent l’objectif du Daily Scrum et continuent à y trouver de la valeur. En tant que coach agile chez J P Morgan, j’ai encouragé les développeurs à réfléchir régulièrement sur le Daily Scrum, à identifier les pratiques qui ne servaient pas l’équipe et les développeurs ont expérimenté différents formats de Daily Scrum jusqu’à ce qu’ils trouvent un format adapté à leur contexte.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Nous savons tous que le Daily Scrum ne doit pas être une mise à jour de statut pour le Scrum Master, le Delivery Lead ou le Product Owner, mais une réunion de planification pour les développeurs. Cependant, j’ai observé que lorsque les équipes n’utilisent pas d’objectif de sprint, le Daily Scrum dégénère très rapidement en une mise à jour de statut.
Pour en savoir plus sur le Framework Scrum et ses principes, rejoignez l’un de nos Scrum Workshops dans les semaines à venir.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
La première grande décision d’un manager de projet est le choix de l’approche et du cycle de vie. Historiquement, ce n’était pas un problème. L’option par défaut était prédéterminée en fonction du type de projet, des préférences organisationnelles et de l’inertie. Mais ce n’est plus le cas !
Picking the Hybrid Project Management Approach by Alan Zucker
La première grande décision d’un manager de projet est le choix de l’approche et du cycle de vie. Historiquement, ce n’était pas un problème. L’option par défaut était prédéterminée en fonction du type de projet, des préférences organisationnelles et de l’inertie.
Les projets de construction et d’ingénierie ont toujours été prédictifs. Pour les projets logiciels, des facteurs organisationnels indépendants de la volonté du manager de projet ont souvent conduit à la décision prédictive ou agile. Les approches de projet ad hoc et maison sautaient les pratiques standard et manquaient de répétabilité ou de cohérence.
Le choix de l’approche du projet doit être réfléchi et intentionnel. Il y a plusieurs rubriques de prise de décision et aucune « bonne » réponse. Chaque projet et chaque équipe sont uniques. Il est essentiel de comprendre le contexte et d’envisager les options.
Deux facteurs prédominants influencent la décision de sélection de l’approche :
Problèmes et solution. Quelle est la nature du problème ? Quelle approche est susceptible de mener à une solution réussie ?
L’organisation et les gens. Quels sont les facteurs organisationnels à prendre en compte ? Quelles sont les compétences et le niveau de maturité de l’équipe projet ?
Espace Problèmes et Solution
Les projets résolvent des problèmes. La compréhension du problème fournit un contexte pour structurer l’approche de la solution.
Il classe les problèmes en quatre types principaux :
Évident. Des problèmes qui sont bien compris et qui ont des relations de cause à effet claires. Les solutions sont simples et peuvent être résolues à l’aide de procédures établies. La standardisation améliore l’efficacité.
Compliqué. Problèmes avec plusieurs solutions potentielles. Une expertise est nécessaire pour analyser le problème et développer l’approche. L’ingénierie et le développement de nouveaux produits en sont des exemples.
Complexe. Problèmes caractérisés par l’incertitude et l’ambiguïté. La solution peut émerger par itération et expérimentation. L’exploration, l’adaptation et la collaboration sont nécessaires pour résoudre ces problèmes.
Chaotique. Des problèmes intrinsèquement imprévisibles. La situation doit être stabilisée avant que le problème puisse être résolu.
Ralph Stacey a développé un modèle similaire qui a été adapté pour décrire la complexité du projet.
Il cartographie ce que l’on sait du problème (exigences) par rapport à la solution (technologie), ce qui peut ensuite éclairer l’approche :
Les problèmes simples ont des exigences et des solutions claires. Les approches prédictives ou Kanban sont efficaces.
Les problèmes complexes ont des exigences et des solutions moins claires. Des approches prédictives ou hybrides-prédictives utilisant la livraison incrémentale ou itérative peuvent être utilisées. Par exemple, les ingénieurs résolvent des problèmes complexes en les décomposant, puis en agrégeant la solution.
Les problèmes complexes ont des exigences et des solutions peu claires et nécessitent l’approche incrémentale et itérative d’Agile. Les scientifiques utilisent cette approche pour expérimenter et s’adapter en fonction de ce qui a été appris.
Modèle Nieto-Rodriguez
Le professeur Antoni Nieto-Rodriguez a proposé un modèle de sélection de l’approche de projet basé sur l’évaluation des critères suivants dans chaque phase du projet. L’approche a été présentée lors d’un webinaire organisé par le PMI en janvier 2024 et accompagnée d’un article dans la Harvard Business Review, « It’s Time to End the Battle Between Waterfall and Agile ».
Pour chaque phase ou composante importante du projet, évaluez les facteurs sur une échelle de 1 (faible) à 5 (élevée) :
Incertitude de la portée. Dans quelle mesure les exigences sont-elles incertaines et instables ?
Adaptabilité du changement. Quelle est la probabilité que des changements critiques devront être abordés ?
Engagement et rétroaction des parties prenantes. Quelle est l’importance des retours et de l’engagement fréquents des clients ?
Délai de livraison. Quelle est l’urgence pour que les livrables soient terminés dans un court délai ?
Management des risques et complexité. Quel niveau de risque et quelle complexité devraient être pris en compte dans la planification et l’évaluation ?
Le score total identifie l’approche préférée :
Waterfall (1-9),
Hybride (10-21) ou
Agile (22-25).
Les phases ou les composants de notation prennent en charge une approche mixte, telle que l’utilisation de Waterfall pour l’infrastructure et d’Agile pour les interfaces utilisateur.
Modèle Boehm-Turner
Lors du choix de l’approche de projet, la dynamique d’équipe, les facteurs humains et les exigences du projet doivent être pris en compte. Le modèle Boehm-Turner et l’arbre de décision Disciplined Agile intègrent ces deux facteurs dans leurs rubriques de sélection d’approche.
Les professeurs Barry Boehm et Richard Turner ont mis au point un modèle adaptable et fondé sur le risque pour sélectionner l’approche de projet. Le modèle évalue l’équipe à travers 5 catégories quantifiables :
Personnel. Quelle est la maturité agile de l’équipe ?
Dynamisme. Les exigences sont-elles susceptibles de changer ?
La culture. L’équipe prospère-t-elle dans le chaos ou l’ordre ?
Taille. Quelle est la taille de l’équipe projet ?
Criticité. Le projet apporte-t-il une solution vitale ?
Le guide de pratique agile du PMI comprenait une version modifiée du modèle qui évalue le projet à travers neuf domaines organisés en trois catégories : équipe, culture et projet.
Arbre de décision Disciplined Agile
Disciplined Agile (DA) est une boîte à outils qui prend en charge plusieurs cycles de vie agiles. Les principales options sont basées sur l’itération (DA Agile) et sur le flux (DA Lean). Les deux approches peuvent être renforcées par des options de livraison continue pour les équipes matures. Bien que DA se concentre sur l’agilité, il reconnaît également que le séquentiel (prédictif) peut être le bon choix pour certains projets et équipes.
La boîte à outils de Disciplined Agile comprend un arbre de décision pour aider les équipes à choisir la meilleure approche en fonction d’une évaluation de plusieurs facteurs :
Compétences d’équipe. Les compétences et la maturité sont des considérations importantes. Le prédictif peut être le meilleur choix pour les équipes moins qualifiées ou moins matures. La livraison continue nécessite plus de compétences.
Organisation et culture d’équipe. Le prédictif peut être le meilleur choix pour les projets confrontés à des contraintes rigides, car l’agilité nécessite une plus grande flexibilité et adaptabilité.
Nature du problème. Le prédictif est conçu pour les grandes solutions. Agile pour les plus petites et les plus rapides.
Contraintes business. Un engagement régulier des parties prenantes est essentiel pour l’agilité, mais moins important pour le mode prédictif.
Options agiles
L’agilité est un état d’esprit décrit par un ensemble de valeurs et de principes. De multiples cadres, méthodologies et boîtes à outils permettent l’agilité. Les cadres formels ont d’importants points communs et se chevauchent. En pratique, les équipes matures mélangent librement les meilleures pratiques en fonction des besoins spécifiques de leurs équipes.
Les principaux choix de cadre agile sont basés sur l’itération, le flux et la mise à l’échelle.
Basé sur l’itération. Scrum est l’approche agile basée sur l’itération la plus couramment utilisée. De petites équipes auto-organisées apportent une valeur ajoutée à leurs clients, généralement toutes les deux semaines. Cette approche est optimisée pour résoudre des problèmes adaptatifs complexes.
Basé sur le flux. Kanban est l’approche basée sur les flux la plus couramment utilisée. Son objectif principal est de fournir de petites augmentations de valeur avec le délai de livraison répétable le plus court possible. De nombreuses équipes Scrum adoptent des principes basés sur le flux, créant une pratique hybride agile parfois appelée « Scrum-Ban ».
Échelle. Scrum et Kanban sont des pratiques d’équipe. Les grandes organisations ont souvent besoin de programmes ou d’équipe d’équipes agiles pour mettre en œuvre des solutions à grande échelle. Plusieurs cadres soutiennent ces efforts, notamment Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) et Scrum of Scrum.
L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente de montrer ses livrables et de s’adapter en permanence en fonction des retours des utilisateurs.
Releasing new features nobody cares about par David Pereira
Quelle est votre expérience lors de la sortie de nouvelles fonctionnalités ? Peut-être est-ce un peu aléatoire. Malheureusement, de nombreuses équipes tombent dans le piège de devenir des usines à fonctionnalités. Dans son livre, David Pereira, coach produit et auteur, aide les équipes à surmonter ces pièges dangereux et à créer des produits que les clients aiment vraiment.
Vous trouverez ci-dessous un court extrait de son livre sur la sortie de fonctionnalités dont personne ne se soucie. Si vous aimez ce que vous lisez, vous pouvez obtenir le livre complet ici.
Comment fonctionnent les entreprises « Feature Factory » (usines à fonctionnalités) ?
Après des mois de travail acharné et une coordination exhaustive, l’équipe produit publie enfin une nouvelle fonctionnalité. Tout le monde dans l’équipe et dans l’entreprise l’adore. La nouvelle fonctionnalité brillante est prête pour les clients, mais quelque chose d’inattendu se produit. Les clients qui interagissent avec la nouvelle fonctionnalité ne comprennent pas son objectif et n’en tirent pas de bénéfices. Confus, les clients rejettent la nouvelle fonctionnalité brillante tant appréciée des parties prenantes de l’entreprise, et inévitablement, tout le monde est frustré.
Construisez-vous des fonctionnalités dont les clients n’ont pas besoin ?
Ce n’est pas la raison d’être des équipes produit que de créer des solutions que leur entreprise adore mais dont les clients se moquent. Pourtant, cela se produit plus souvent qu’il ne le devrait. J’appelle cela un bug, pas une fonctionnalité. Comme pour tous les bogues critiques, il nécessite un correctif.
Le remède : Des équipes responsabilisées grâce à des flux collaboratifs.
Si l’usine à fonctionnalités est un bogue, qu’est-ce qui résoudrait cela ? Vous ne pouvez pas vous attendre à une solution simple, mais la promotion d’équipes autonomes avec des flux collaboratifs transformera la situation.
Marty Cagan, partenaire SVPG, définit les équipes responsabilisées comme suit :
« Les grandes équipes sont composées de gens ordinaires qui sont responsabilisés et inspirés. Ils sont habilités à résoudre des problèmes difficiles d’une manière que leurs clients aiment, tout en travaillant pour leur entreprise. Ils sont inspirés par des idées et des techniques pour évaluer rapidement ces idées afin de découvrir des solutions qui fonctionnent : elles sont précieuses, utilisables, réalisables et viables. »
Comment les méthodes de travail courantes piègent-elles ou libèrent-elles les équipes ?
Les équipes responsabilisées ont beaucoup plus de chances de créer de la valeur que les équipes d’usine à fonctionnalités. Pourtant, il n’est pas facile de responsabiliser les équipes. Pour l’instant, concentrons-nous sur les défis de la collaboration.
Flux de développement de produits coordonnés ou collaboratifs
Au fil des ans, j’ai remarqué 2 flux standard de développement de produits dans les entreprises, quel que soit leur cadre :
Flux de coordination : Les membres de l’équipe passent beaucoup de temps à coordonner les activités entre eux, les parties prenantes et les autres équipes. La majeure partie de leur énergie est consacrée à l’organisation de la façon de faire le travail. Cette approche vise à éviter les erreurs et les échecs, obligeant les équipes à être rigides dans leur flux de développement. Cela devient un contrat « strict » parce que quelqu’un est blâmé lorsque quelque chose ne va pas.
Flux collaboratif : Les membres de l’équipe se concentrent sur la collaboration pour utiliser leurs connaissances actuelles afin de découvrir des opportunités prometteuses. L’objectif ultime est de créer de la valeur pour les clients et l’entreprise. L’équipe est flexible dans la façon dont elle fait le travail tout en se concentrant sur la création de valeur. La confiance est à la base de l’approche collaborative. Lorsque quelque chose déraille, l’équipe prend ses responsabilités et trouve ensemble une solution.
Le flux coordonné : Une façon logique de travailler avec des résultats inattendus
Comment transformer une idée en quelque chose de précieux ? C’est l’une des questions les plus importantes pour les entreprises. Une mauvaise réponse conduit au gaspillage et à la démotivation.
Les étapes d’un flux coordonné
Priorisation : Le flux de coordination commence par la hiérarchisation, visant à trouver l’idée la plus prometteuse. Cependant, c’est plus facile à dire qu’à faire car plusieurs tours de discussion auront lieu. Lorsque vous dites oui à une idée, vous dites non à de nombreuses autres, et presque aucune partie prenante de l’entreprise n’accepte facilement cette réponse
Conception : La phase de conception commence une fois que vous avez défini ce sur quoi l’équipe va travailler. Le résultat est souvent un prototype haute-fidélité que les parties prenantes de l’entreprise approuvent. Cette approche est dangereuse car les ingénieurs logiciels et les clients ont tendance à être laissés à l’écart. Malheureusement, la solution devient l’objectif, et non le résultat.
Test utilisateur : Après beaucoup de coordination, les parties prenantes de l’entreprise approuvent finalement la conception et il est temps de la tester avec des clients potentiels. Les résultats sont probablement biaisés car tout le monde aime déjà la solution. Malheureusement, être la proie du biais de confirmation n’est pas l’exception, mais plutôt le résultat typique. Compte tenu de leur passion pour la solution, les concepteurs de produits recherchent des signes positifs et, sans surprise, ils les trouvent. Ils peuvent accepter des ajustements mineurs de la solution, mais aucun pivot ou abandon de solution ne se produira dans cette phase.
Développement : Une fois que les concepteurs de produits ont confirmé que le prototype haute-fidélité a du sens pour les utilisateurs finaux, il est temps de développer la solution. Les concepteurs de produits jettent les spécifications par-dessus le mur et espèrent que les ingénieurs logiciels font le bon travail. Bien sûr, il est peu probable que les ingénieurs logiciels accueillent la solution à bras ouverts, car ils n’ont pas participé aux étapes précédentes. Malgré cela, c’est à eux de transformer le prototype haute-fidélité en une solution fonctionnelle.
Lancement : Compte tenu de la quantité de coordination nécessaire, il faut des mois pour transformer une idée en solution. Vous ne devriez pas être surpris quand quelque chose prend six mois. Chaque phase est strictement définie et comporte de nombreuses étapes pour assurer une solution parfaite à la fin de celle-ci. Pourtant, quelque chose d’inattendu se produit lorsque vous lancez la solution. Malgré tout l’enthousiasme interne et l’amour pour la nouvelle solution sophistiquée, les clients ne s’y intéressent pas, et vous ne savez pas pourquoi.
Ce qui me choque, ce n’est pas de me retrouver dans cette situation tragique. J’y suis allé plus de fois que je ne peux compter, mais j’ai appris la leçon. La question est de savoir ce que vous faites après avoir été confronté à un résultat indésirable. La réponse la plus courante n’a guère de sens pour moi. Revenez à la hiérarchisation, choisissez une autre idée et recommencez. Lorsque vous suivez la même approche, il y a de fortes chances que vous soyez à nouveau confronté aux mêmes résultats. Le flux de coordination oblige les équipes à se concentrer sur les résultats plutôt que sur les résultats, ce qui les réduit au rang d’usines.
9 idées sur 10 échoueront
Notre taux de réussite est pire que ce que nous pouvons imaginer. Regardez les start-up : 90% d’entre elles ne tiennent pas plus de cinq ans. Les idées subissent à peu près le même sort. Curieusement, cela passe inaperçu car les équipes investissent beaucoup de temps à trouver comment réduire le temps de développement. Je vois de la valeur dans cette affaire, bien que je perçoive une autre question comme plus urgente : « A quelle vitesse pouvez-vous laisser tomber les mauvaises idées ? »
Nous supposons que nos idées sont bonnes, mais la réalité nous montre le contraire. Pourtant, nous insistons pour suivre la même approche à plusieurs reprises. Pas étonnant que nous soyons confrontés à des résultats indésirables.
Un bon management de produit nécessite de s’adapter en apprenant. C’est OK de se tromper. Il n’est pas bon d’ignorer la réalité. La collaboration plutôt que la coordination est le principe qui peut vous sortir de ce piège. Au lieu de rendre votre flux de développement rigide et complexe, vous bénéficierez d’une simplicité et d’une flexibilité accrues. Explorons une autre méthode de travail qui augmente les chances de générer de la valeur plus rapidement.
Flux collaboratif : Une méthode de travail simple qui apporte des résultats exceptionnels.
Personne ne mérite de perdre du temps. Après de nombreuses années d’expérience, j’ai appris que les échecs sont inévitables. Au lieu d’ajouter des étapes pour prévenir les échecs, il est plus logique d’identifier et d’abandonner rapidement les mauvaises idées. Contrairement au flux coordonné, le flux collaboratif se concentre sur des itérations plutôt que sur des phases.
Les étapes d’un flux collaboratif
Évaluez : Le début d’un flux collaboratif est le même que pour un flux coordonné. Vous avez plein d’idées, et tout le monde veut que tout soit terminé d’hier. L’astuce n’est pas d’identifier les idées les plus prometteuses dès le départ, mais plutôt de les évaluer toutes et de laisser tomber celles qui ne conviennent pas. Laisser tomber des idées vous donne de la liberté parce que vous avez moins d’attentes à gérer.
Apprenez : L’itération d’apprentissage commence par des idées adaptées à votre stratégie, mais cela ne signifie pas qu’il faille passer directement à la mise en œuvre. Vous devriez laisser tomber les idées que vos clients ne désirent pas, que l’entreprise ne peut pas soutenir, que vous n’avez pas la technologie pour développer ou qu’il est contraire à l’éthique de poursuivre. Restez simple et posez les questions suivantes sur chaque idée restante :
À quel point les clients veulent-ils ceci ? (Désirabilité)
Quels sont les bénéfices pour l’entreprise ? (Fiabilité)
Dans quelle mesure pouvons-nous le faire ? (Faisabilité)
À quel point est-il bien de le faire ? (Éthique)
Expérimentez : Après avoir compris les aspects clés de vos idées, il est temps de mener des expériences plus robustes. Vous voulez tester les solutions qui peuvent donner les résultats potentiels. Il est essentiel d’explorer quelques alternatives et de s’en tenir aux plus prometteuses. Il est trop courant de choisir une solution et de se lancer à fond. Je vous décourage de suivre cette voie, car elle augmente rapidement l’engagement. En tant qu’êtres humains, plus nous sommes investis dans quelque chose, plus nous y investissons volontiers.
Déployez : Les idées qui survivent à l’itération de l’expérience sont les plus importantes. Dans l’itération précédente, vous avez construit pour apprendre. Maintenant, vous créez pour évoluer. Il est fondamental de rembourser la dette technologique avant de mettre la solution à la disposition de l’ensemble de votre public ou de passer à votre prochaine opportunité
Principaux points à retenir
La première étape pour libérer votre équipe consiste à examiner votre situation actuelle. Comprendre la dynamique peut révéler des opportunités pour simplifier votre flux de développement.
Les symptômes d’une usine à fonctionnalités comprennent l’absence d’objectifs, l’obsession de la production, la fourniture de solutions qui ne résolvent aucun problème, une direction peu claire, une réticence à laisser tomber des idées et un manque d’attention aux résultats. L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente d’examiner ses livrables et de s’adapter en permanence.
Plus vous vous rapprochez d’un flux de développement coordonné, plus il faut de temps pour générer de la valeur et plus vous créez de déchets. Les flux coordonnateurs transforment involontairement les plans en objectifs.
Plus vous vous rapprochez d’un flux de développement collaboratif, plus tôt vous créez de la valeur et moins vous produisez de déchets. La collaboration vous aide à adapter vos plans pour atteindre vos objectifs lorsque la réalité rend votre plan obsolète.
Lorsque vous comprenez parfaitement le flux de développement d’un produit, vous pouvez favoriser les changements étape par étape. La première étape consiste à collaborer avec les parties prenantes de l’entreprise et les membres de l’équipe pour reconnaître ce qui est inutilement complexe. Équipé de cette compréhension, vous pouvez obtenir du soutien et collaborer pour simplifier votre travail.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les temps changent et les organisations doivent se préparer dès maintenant et en permanence à répondre avec agilité à tout ce qui pourrait arriver.
Qu’est-ce que l’Agilité Organisationnelle ?
Téléchargez le livre blanc.
Ce concept qui fut à la mode dans le passé, a été reconnu comme une capacité business essentielle pendant la pandémie et les perturbations économiques qui ont suivi, et il son urgence s’ est accrue en 2023 avec la montée en puissance de l’IA.
Votre organisation doit être capable de s’adapter à des circonstances qui évoluent et changent rapidement. Vous devez rester à l’affût des risques et des opportunités, manager vos équipes distribuées et vous appuyer sur une main-d’œuvre collaborative auto-managée.
À l’aide des conseils de ce livre blanc, vous découvrirez 7 actions de management de projet transformatrices pour une organisation adaptative.
Privilégiez les bénéfices.
Mettez en place un PMO agile.
Mesurez la maturité et les progrès.
Formez-vous pour l’état d’esprit, pas pour la conformité.
Choisissez la bonne approche.
Suivez des principes, pas des procédures.
Faites confiance à vos équipes.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’équipe se réunit régulièrement pour réfléchir aux événements les plus importants survenus depuis la dernière réunion et identifier les possibilités d’amélioration.
Le terme « radiateur d’information » désigne l’un des nombreux affichages visuels qu’une équipe place dans un endroit très visible, de sorte que tous les membres de l’équipe peuvent voir les dernières informations en un coup d’œil.
Une fonctionnalité minimale commercialisable est une petite fonctionnalité autonome qui peut être développée rapidement et qui offre une valeur significative à l’utilisateur.
L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper des histoires utilisateur. Je suis sûr que vous avez aussi eu du mal avec cela. C’est certainement ce que m’est arrivé au début.
En fait, quand j’ai commencé à utiliser Scrum, dans certains de nos arriérés de produit, les histoires étaient si grosses que nous avons parfois opté pour des sprints de six semaines. Avec un peu plus d’expérience, cependant, cette équipe et moi avons vu suffisamment de façons de décomposer le travail pour que nous puissions faire des sprints d’une journée si nous l’avions voulu.
Mais décomposer les histoires a été difficile au début. Vraiment dur.
J’ai de bonnes nouvelles pour vous. Non seulement j’ai compris comment découper des histoires par moi-même, mais j’ai aussi appris à expliquer comment le faire afin que tout le monde puisse rapidement devenir un expert. (Si vous voulez jeter un coup d’œil dans les coulisses de vraies histoires d’utilisateurs de certains de mes premiers backlogs de produits, avec des commentaires sur ce que je ferais différemment aujourd’hui : Télécharger 200+ exemples de User Story).
Ce que j’ai découvert, c’est que presque toutes les histoires peuvent être divisées avec l’une des cinq techniques suivantes. Apprenez ces cinq techniques simples et vous êtes prêt.
Mieux encore, les cinq techniques forment un acronyme facilement mémorisable : SPIDR.
Je présente chaque technique ci-dessous, et cette vidéo les montre en action.
Technique SPIDR pour diviser les histoires
Il y a quelques années, je créais le cours « Better User Stories ». Parce que ce cours couvrirait tout ce que quelqu’un doit savoir pour travailler efficacement avec des histoires, je savais qu’il fallait d’un module sur le fractionnement.
Pour créer ce module, j’ai imprimé plus d’un millier d’histoires ‘utilisateur que j’avais rassemblées pendant 15 ans. Pour chaque histoire, j’avais l’histoire originale et les sous-histoires dans lesquelles elle avait été divisée. J’ai collé chaque histoire sur le mur, en les regroupant en fonction de la façon dont elles avaient été divisées. Je cherchais les approches communes utilisées pour découper toutes ces histoires. Je suis passé par une variété de regroupements, en essayant de trouver le plus petit ensemble d’approches possible. Je savais qu’il serait plus facile de se souvenir de 5 techniques de fractionnement plutôt que de 20.
Les cinq que j’ai obtenues forment l’acronyme SPIDR : S, P, I, D et R (spider sans E).
Jetons un coup d’œil aux cinq techniques de fractionnement des user stories qui composent l’acronyme SPIDR, avec des exemples de la façon dont votre équipe pourrait les utiliser.
#1 – Diviser les User Stories à l’aide d’un Spike
S comme Spike. C’est un problème que la plupart des équipes agiles connaissent. Un spike est une activité de recherche qu’une équipe entreprend pour en savoir plus sur un élément de l’arriéré. Les spikes peuvent également donner aux équipes les connaissances dont elles ont besoin pour diviser une histoire complexe. Considérez-le comme une activité de recherche, mais il peut inclure du prototypage ou du codage expérimental.
Au cours d’un spike, une équipe n’essaie pas de développer la nouvelle fonctionnalité, mais plutôt de développer de nouvelles connaissances qui l’aideront à développer la fonctionnalité plus tard.
Prenez YouTube par exemple. Remontez dans le temps, à l’époque où YouTube ajoutait le sous-titrage automatique. L’équipe qui s’est chargée de cela aurait peut-être été confrontée à une décision de construction ou d’achat. Utilisent-ils un logiciel disponible dans le commerce pour générer les sous-titres ? Ou leurs besoins sont-ils si uniques qu’ils doivent développer quelque chose à partir de zéro ? La façon de régler cela serait un spike pour tester un ou plusieurs produits de sous-titrage disponibles dans le commerce.
L’extraction d’un spike réduit la taille de l’article d’origine, car une partie ou la totalité des recherches incluses dans l’article d’origine est supprimée. C’est absolument un moyen essentiel de diviser les histoires. L’extraction d’un spike est donc l’une des cinq techniques de fractionnement que vous devriez utiliser. Mais normalement, ce ne sera pas la première technique que vous utiliserez.
#2 – Diviser les User Stories par Path (chemin)
P comme Path. Si un utilisateur peut faire quelque chose de plusieurs façons (par exemple, payer avec une carte ou Apple Pay), c’est un excellent domaine pour diviser.
Pour diviser une histoire en chemins, recherchez d’autres chemins d’accès à travers l’histoire.
Pour rester sur YouTube, utilisons l’histoire : « Je peux partager une vidéo avec mes amis ».
Lorsque je clique sur le bouton « Partager » sur YouTube aujourd’hui, on me montre 14 boutons sur lesquels je peux cliquer pour partager directement sur divers réseaux sociaux. On me montre également un lien que je peux copier. Et j’ai la possibilité de personnaliser ce lien pour démarrer la lecture de la vidéo partagée à un moment précis de la vidéo.
Il s’agit de 16 chemins différents à travers l’histoire « Je peux partager une vidéo ». Je ne sais pas si cette histoire a besoin d’être divisée en autant de sous-histoires plus petites. C’est à l’équipe de décider en fonction de l’effort impliqué. Mais, avec la seule technique du chemin, nous avons identifié 16 chemins à travers l’histoire originale.
#3 – Diviser les User Stories par Interfaces
I est pour Interfaces : Diviser votre histoire par navigateur ou matériel, ou fournir une interface complexe par itérations. Par exemple, vous pouvez proposer une version qui ne fonctionne que dans Chrome dans cette itération et prévoir Safari pour une autre itération.
Dans d’autres cas, le découpage par interface signifie la création d’une version simple de l’interface et d’une version plus complexe en tant qu’histoires distinctes. Cela s’applique généralement à l’interface utilisateur.
En appliquant cela à notre exemple de partage de vidéos YouTube, au lieu de diviser cette histoire par des chemins, nous aurions pu séparer une histoire de partage de base telle que : « En tant que spectateur de vidéos, je peux obtenir une URL que je peux partager ». Cela pourrait être mis en œuvre sans autre interface utilisateur qu’un bouton de partage sur la page vidéo. La fenêtre contextuelle avec les 16 différentes façons de partager ne serait pas nécessaire si la seule façon de partager est avec une URL.
Une histoire ultérieure pourrait être : « En tant que spectateur, je peux partager une vidéo sur divers sites de médias sociaux. » Cela pourrait être fait avec une interface utilisateur très simple au début – pas de fantaisie de faire défiler une liste de logos, peut-être juste une liste déroulante de texte avec les noms des sites sociaux.
L’histoire finale pourrait alors ressembler à quelque chose comme : « En tant que spectateur, je peux choisir le réseau social sur lequel partager en faisant défiler une liste montrant les logos de chacun. »
La division par interface fonctionne parce que la fonctionnalité finalement souhaitée peut être atteinte par des interfaces de plus en plus détaillées et meilleures.
#4 – Diviser les User Stories par Data / Données
Le D de l’acronyme SPIDR signifie Données. Pour diviser une histoire par données, demandez-vous si vous pouvez apporter de la valeur dans une itération en simplifiant ou en limitant les données prises en charge. Peut-être pouvez-vous faire une version initiale d’une histoire qui ne traite qu’un sous-ensemble des données qui devront finalement être prises en charge. Par exemple, n’autorisez pas les soldes bancaires négatifs dans la première itération. Ajoutez la prise en charge de ceux avec une histoire utilisateur différente dans la prochaine itération.
Pour revenir à l’exemple de YouTube, YouTube vous permet de télécharger une vidéo dans l’un des 16 formats de fichiers différents. Si nous construisons un concurrent de YouTube, oublions les 16 formats de fichiers. Commençons par 1. Nous allons prendre en charge un type de données. Pour l’instant, tous les téléchargements doivent être au format MP4. Nous ajouterons tous les autres plus tard en tant qu’histoires distinctes.
Le fractionnement par données est une approche efficace. Souvent, il y a quelques types de données qui ajoutent beaucoup de complexité. Eh bien, faites une mise en œuvre initiale qui ignore les données les plus complexes. Faites en sorte que cela fonctionne, puis ajoutez la prise en charge des données plus complexes. Vous ne pouvez probablement pas mettre en production la version la plus simple, mais vous pouvez toujours la construire dans cet ordre.
J’ai travaillé sur un système de ressources humaines qui faisait exactement cela. Le système suivait qui était le manager pour chaque employé et faisait des choses comme acheminer les demandes de congé à ce manager. La plupart des employés ont un manager, mais certains employés en ont plusieurs. Nous devions supporter le fait d’avoir plusieurs managers, mais certaines histoires ont été simplifiées au départ en supposant que chaque employé avait uniquement un manager.
#5 – Diviser les User Stories par des Règles / Rules
R comme Règles. Le relâchement temporaire de l’implémentation de règles qu’un article devra au final prendre en charge peut réduire la taille des grandes histoires.
Si l’on s’en tient à YouTube, par exemple, YouTube a des règles strictes concernant l’inclusion de musique protégée par des droits d’auteur dans les vidéos. Si nous construisons un concurrent à YouTube, la première histoire de notre équipe sera : « Je peux télécharger une vidéo pour que d’autres puissent la regarder. » Cette histoire semble probablement simple, mais il y a déjà beaucoup de choses à faire.
Donc, dans la première itération, ignorons la règle selon laquelle les vidéos ne peuvent pas contenir de musique protégée par des droits d’auteur. De toute façon, nous n’annonçons pas notre nouveau concurrent à YouTube au monde après une seule itération. Nous aurons tout le temps après ce premier sprint de nous conformer à notre règle interne interdisant les vidéos contenant de la musique protégée par des droits d’auteur.
Comme cet autre exemple lié à YouTube, supposons que nous voulions empêcher certains textes d’apparaître dans les commentaires. Il peut s’agir de jurons ou de commandes SQL qui peuvent être des tentatives de piratage. Bonne idée : Protégeons nos utilisateurs et notre système de ce type de texte dans les commentaires. Mais une première histoire du type « En tant qu’utilisateur, je peux entrer un commentaire sur une vidéo » peut ignorer cette règle. Cela rend l’histoire plus petite afin qu’elle puisse s’intégrer dans une itération. Et la prise en charge de la règle peut être ajoutée quelques itérations plus tard.
S’améliorer dans le fractionnement des histoires
S’améliorer dans le découpage des histoires d’utilisateurs est une compétence importante. Avec les courtes itérations utilisées en agile, il est utile d’avoir de petites unités de travail. Les cinq techniques que nous avons abordées ici (fractionnement par Spikes, Paths, Interfaces, Données et Règles) devraient vous permettre de fractionner n’importe quelle histoire.
Les techniques SPIDR sont faciles à retenir, mais leur mise en pratique peut nécessiter un peu d’entraînement et beaucoup de pratique. C’est pourquoi j’ai mis en place un cours vidéo « Better User Stories » qui inclut la méthode SPIDR pour diviser les histoires, et bien plus encore.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans un récent webinaire, Melanie Franklin a offert une mini-session de formation sur les techniques pour travailler plus intelligemment plutôt que plus dur. L’objectif est de vous aider à faire face à votre écrasante charge de travail.
Using Agile Change techniques to work smarter, not harder par Melanie Franklin
Nous sommes tous tellement occupés, sous tellement de pression pour faire avancer les choses. Nous avons besoin de techniques qui nous aident à utiliser le moins d’énergie possible pour obtenir le meilleur retour sur nos efforts.
Les meilleures techniques pour travailler plus intelligemment, pas plus dur
Voici le résumé des techniques pour travailler plus intelligemment, pas plus dur.
Travaillez en courtes salves
Fragmentez le travail : Décomposez les tâches en petits morceaux gérables pour réduire la surcharge et augmenter la concentration.
Adoptez une approche itérative : Décomposez le travail en itérations ou en incréments pour le rendre gérable et maintenir le focus.
Utilisez des outils visuels
Représentez visuellement : Utilisez des visuels pour réduire la charge cognitive et faciliter le traitement de l’information.
Priorisez avec Kanban : Utilisez des tableaux visuels pour suivre les tâches et la progression (par exemple, À faire, En cours, Terminé).
Structurez une feuille de route : Créez d’une feuille de route pour visualiser et planifier le voyage, en apportant certitude et une approche étape par étape.
Utilisez les neurosciences pour travailler d’une manière respectueuse du cerveau
Comprenez les états cérébraux : Reconnaissez comment le cerveau réagit au stress (état de menace) et aux stimuli positifs (état de récompense) pour optimiser les performances.
Créez des émotions positives : Utilisez des techniques pour déclencher des substances chimiques positives du cerveau comme la dopamine (réalisations), les endorphines (substances chimiques de bien-être) et l’ocytocine (confiance et liaison).
Reconnaissez les réalisations
Recherchez les bénéfices : Concentrez-vous sur les tâches les plus précieuses et réfléchissez régulièrement aux progrès pour maintenir la motivation et la direction.
Célébrez et réfléchissez : Prenez le temps de célébrer les réalisations et de réfléchir à ce qui a été appris pour renforcer les expériences positives et l’amélioration continue.
Définissez vos critères de qualité et d’acceptation
Définissez les critères de réussite : Posez des critères de qualité et d’acceptation clairs dès le départ pour vous assurer que le travail répond aux normes requises et minimise le besoin d’être retravaillé
Gérez la charge de travail
Établissez des structures et des modèles reproductibles pour aider le cerveau à reconnaître et à anticiper les prochaines étapes.
Implémentez des techniques de hiérarchisation : Utilisez des méthodes comme Moscow (Must have, Should have, Could have, Won’t have) pour hiérarchiser les tâches en fonction de leur valeur et de leur urgence.
Capturez les idées : Notez rapidement vos idées pour éviter l’encombrement mental et rester concentré sur les tâches en cours.
Il est important de vous concentrer sur des techniques qui vous aideront à travailler plus intelligemment, et pas plus dur.
Ces techniques vous permettent de tirer parti des méthodologies agiles et des dernières idées des neurosciences et de la psychologie positive pour augmenter votre efficacité au travail. Ces techniques renforcent votre résilience au changement, et vous pouvez les utiliser pour gérer votre propre charge de travail et aussi pour aider vos collègues et les membres de votre équipe.
partagez ce billet avec vos amis, collègues et relations professionnelles
En 2018, The Adaptive Organization : A Benchmark of Changing Approaches to Project Management a identifié un certain nombre de bonnes pratiques pour les PMOs dans les organisations qui s’efforcent d’adopter des approches adaptatives et agiles pour les projets, les programmes et les portefeuilles.
En 2020, notre recherche sur l’état du management de projet a montré que les PMOs des organisations les plus performantes avaient adopté ces pratiques, obtenant de meilleurs résultats dans tous les domaines.
Avance rapide jusqu’en 2024 : Une nouvelle version de l’étude nous a permis d’établir une tendance dans la capacité des PMOs sur chaque pratique… ainsi qu’une nouvelle pratique qui montre la popularité croissante du management de projet en tant que service (PMaaS).
Les 13 meilleures pratiques des PMOs
Choisir l’approche de management de projet (prédictive, adaptative ou hybride) la plus appropriée pour livrer le produit, le service ou le résultat.
Conseiller la direction sur la valeur commerciale des projets qui utilisent des approches adaptatives.
S’efforcer de fournir ce dont on a besoin et de prendre le pouls des clients.
Fonctionner comme s’il s’agissait d’une entreprise de conseil, adaptant ses efforts pour répondre à des besoins spécifiques.
Attendre que ses clients (clients, équipes) sollicitent ses services plutôt que de forcer des approches.
Fournir des outils et des modèles adaptatifs.
Fournir des cours de formation adaptés, des coachs ou des mentors.
Coordonner les cours de formation adaptative, les coachs ou les mentors.
Coordonner la communication entre les équipes qui utilisent des approches adaptatives.
Faciliter l’apprentissage organisationnel dans les approches adaptatives.
Élaborer des lignes directrices pour le recrutement, l’évaluation et la sélection des leaders d’équipe.
Élaborer et mettre en œuvre des standards pour l’utilisation d’approches adaptatives.
Utiliser le PMaaS* en faisant appel à un tiers pour gérer le PMO.
Erreur : Traiter l’objectif de sprint comme facultatif ou comme une simple liste de tâches, ce qui entraîne un manque de concentration et de direction pour l’équipe Scrum.
Pourquoi c’est une erreur : L’équipe n’a pas d’objectif unifié sans un objectif de sprint clair, ce qui entraîne des efforts fragmentés, une réduction de la valeur globale et des difficultés à mesurer le succès. L’équipe peut se retrouver sans direction, travaillant sur des tâches qui ne s’alignent pas sur l’objectif du produit ou les objectifs stratégiques du produit en général.
Opportunité d’apprentissage : Les débutants légitimes se rendent rapidement compte de l’importance d’un objectif de sprint bien défini comme phare guidant les efforts de l’équipe. Il favorise la collaboration et garantit que l’équipe apporte une valeur significative à chaque sprint. Pour vous y entraîner, essayez un atelier sur les objectifs de sprint avant le prochain sprint, au cours duquel l’équipe collabore pour rédiger un objectif clair et cohérent. Apprenez-en plus à leur sujet avec Le fantastique livre de Maarten Dalmijn sur les objectifs de sprint. [Lien d’affiliation Amazon.]
Microgestion de l’équipe
Erreur : Agir en tant que chef de tâche ou de projet, superviser et diriger constamment le travail des développeurs.
Pourquoi c’est une erreur : Les Scrum Masters doivent servir l’équipe en supprimant les obstacles et en facilitant les processus, et non en contrôlant le travail car les développeurs ont le pouvoir et la responsabilité de faire leur part. La microgestion étouffe l’autonomie et l’innovation de l’équipe, entraînant une baisse du moral et un manque d’appropriation parmi les membres de l’équipe, ce qui entrave finalement la productivité et la créativité.
Opportunité d’apprentissage : Les vrais débutants apprennent à faire confiance aux capacités de leur équipe, en se concentrant plutôt sur la possibilité pour l’équipe de s’auto-organiser et de résoudre les problèmes de manière indépendante, ce qui conduit à un engagement plus élevé et à une meilleure résolution des problèmes. Un exercice pour y remédier consiste à vous abstenir de résoudre les problèmes pendant un sprint, mais d’observer et soutenir la progression de vos coéquipiers.
Négliger de renforcer la confiance et la sécurité psychologique de l’équipe
Erreur : Ne pas créer un environnement de confiance et de sécurité psychologique où tous les membres de l’équipe se sentent à l’aise pour partager leurs idées et leurs préoccupations.
Pourquoi c’est une erreur : Sans confiance et sécurité, les membres de l’équipe sont moins susceptibles de s’engager pleinement, de collaborer efficacement ou de prendre des risques. Négliger la confiance étouffe l’innovation et l’amélioration continue, ce qui conduit à un environnement de travail avec des problèmes non divulgués, un engagement d’équipe terne et une créativité restreinte. Cela peut également entraîner un taux de rotation élevé et une faible satisfaction au travail.
Opportunité d’apprentissage : Les Scrum Masters compétents travaillent activement à créer et à maintenir une culture de confiance et de sécurité psychologique. Ils/elles encouragent une communication ouverte et une rétroaction constructive. Un exercice pratique consiste à organiser régulièrement des activités de renforcement de l’esprit d’équipe et des exercices de confiance, tels que le partage d’histoires personnelles de réussite, de défis et d’échecs, afin de développer l’empathie et la compréhension entre les membres de l’équipe.
Se concentrer uniquement sur les indicateurs et les rapports
Erreur : En mettant trop l’accent sur les métriques, les OKR et les KPI, le rôle de Scrum Master se transforme en un commis à la saisie de données accablé de rapports excessifs.
Pourquoi c’est une erreur : Bien que les mesures puissent fournir des informations précieuses, une insistance excessive peut détourner l’attention du véritable objectif de Scrum, qui est de fournir de la valeur grâce à des efforts de collaboration et à un retour d’information continu basé sur des publications fréquentes et un processus empirique. Une approche axée sur les indicateurs peut également conduire à jouer avec le système, où les membres de l’équipe se concentrent sur l’atteinte des indicateurs plutôt que sur la création d’une véritable valeur, déformant ainsi les priorités de l’équipe.
Opportunité d’apprentissage : Les Scrum Masters efficaces équilibrent les indicateurs avec des informations qualitatives, en les utilisant pour soutenir, et non dicter, les décisions et les progrès de l’équipe. Ils/elles comprennent que les mesures sont des outils, et non des objectifs en soi. Pour mettre en œuvre cet objectif, vous devez examiner périodiquement les indicateurs avec l’équipe, en discutant de leur pertinence et de la manière dont ils s’alignent sur la valeur réelle, afin d’assurer une approche équilibrée.
Ne pas responsabiliser l’équipe
Erreur : Ne pas donner à l’équipe les moyens de prendre des décisions et de résoudre des problèmes, intervenant souvent pour prendre des décisions ou résoudre des conflits.
Pourquoi c’est une erreur : Cette approche sape la confiance de l’équipe et sa capacité à s’autogérer, ce qui entraîne une dépendance vis-à-vis du Scrum Master et une réduction de l’appropriation du travail par l’équipe. Cela entrave la croissance, la créativité et la capacité d’innovation de l’équipe, car les membres ne sont pas encouragés à penser de manière indépendante ou à prendre des initiatives.
Opportunité d’apprentissage : Les bons Scrum Masters apprennent à prendre du recul et à faciliter les processus de prise de décision de l’équipe, encourageant les membres de l’équipe à s’approprier leur travail et à développer leurs compétences en résolution de problèmes. Un exercice utile consiste à utiliser une matrice de décision, par exemple, basée sur le résultat d’une session de Delegation Poker, où l’équipe décide de manière collaborative de solutions aux problèmes sans intervention directe du Scrum Master, favorisant ainsi l’autonomie et la confiance.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Pratiques utiles pour les débutants afin d’éviter les erreurs de débutant commises par les Scrum Masters
Quelques pistes de réflexion pour l’apprenant en herbe : Il n’est pas nécessaire pour vous de réinventer la roue.
Adoptez l’apprentissage continu : Les Scrum Masters doivent toujours être sur la voie de l’apprentissage continu. Les pratiques Scrum et Agile évoluent, tout comme votre compréhension et leur application. Recherchez des opportunités de formation, de certifications et de réseautage avec d’autres professionnels Scrum. Par exemple, rejoignez la communauté Slack Hands-on Agile ou notre communauté Meetup.
Comprenez le contexte organisationnel : Chaque organisation a sa propre culture et ses propres défis. Comprendre le contexte plus large dans lequel votre équipe fonctionne peut vous aider à mieux soutenir et défendre les pratiques Scrum. Engagez avec les parties prenantes et la direction pour aligner Scrum sur les objectifs de l’organisation. N’oubliez pas que vous ne pouvez pas changer un système au niveau de l’équipe Scrum.
Équilibrez empathie et responsabilité : La constitution d’une équipe performante nécessite un équilibre délicat entre empathie et responsabilité. S’il est essentiel de favoriser un environnement favorable, il est tout aussi important de tenir l’équipe responsable des engagements et des normes de qualité. Les grandes équipes Scrum se tiennent responsables tout le temps ; Ce sont des professionnels.
Soyez un leader serviteur : En tant que Scrum Master, votre rôle principal est de servir l’équipe, par exemple, en supprimant les obstacles, en facilitant la communication et en soutenant l’auto-organisation de l’équipe. Le succès de l’équipe mesure votre succès, alors concentrez-vous sur leur responsabilisation.
L’adaptabilité est essentielle : il n’y a pas deux équipes identiques, et ce qui fonctionne pour l’une peut ne pas fonctionner pour l’autre. Soyez flexible et prêt à adapter votre approche en fonction des besoins et des commentaires de l’équipe. Inspectez et adaptez en permanence non seulement les processus de l’équipe, mais aussi vos propres pratiques et votre état d’esprit.
Favorisez un état d’esprit de croissance : Encouragez une culture où l’échec est considéré comme une opportunité d’apprendre et de grandir. Associé à un état d’esprit de croissance, ceci peut améliorer considérablement la capacité de l’équipe à innover et à s’améliorer continuellement. Célébrez les réussites, mais discutez aussi ouvertement des échecs et des leçons qui en ont été tirées.
Valorisez les boucles de rétroaction: Le retour d’information est la pierre angulaire de l’amélioration continue. Assurez-vous que votre équipe sollicite et donne régulièrement des commentaires, non seulement lors d’événements formels tels que les revues de sprint et les rétrospectives, mais aussi lors des interactions quotidiennes. Un retour pris au sérieux aidera à identifier les problèmes tôt et à promouvoir une culture de transparence et d’amélioration.
La différence essentielle entre les erreurs et les actions d’un débutant et celles de l’imposteur ignorant est la volonté de réfléchir, de s’adapter et de grandir à partir de ses expériences.
Les experts autoproclamés qui comprennent mal et, par conséquent, appliquent mal les principes de Scrum ne parviennent pas à reconnaître et à rectifier leurs erreurs. Dans le même temps, les vrais débutants utilisent ces premiers faux pas comme tremplin pour devenir des Scrum Masters efficaces et respectés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Agile était autrefois salué comme le sauveur d’une livraison rapide et efficace, et il y avait plus de demandes de coachs agiles que le marché du travail ne pouvait en fournir, mais il a fait face à des critiques et à un déclin important ces dernières années. Bien qu’il soit facile de pointer du doigt le leadership, la disparition d’Agile est un problème multi-facette qui va au-delà des décisions et du soutien du leadership. Explorons les différentes raisons pour lesquelles Agile a eu du mal à tenir sa promesse et son efficacité initiales.
L’essor et le décrochage d’Agile
Agile est apparu au début des années 2000 en réponse aux méthodologies rigides en cascade qui dominaient le développement logiciel. En mettant l’accent sur la flexibilité, la collaboration avec les clients et l’itération rapide, Agile promettait de révolutionner l’industrie. Et pendant un certain temps, c’est ce qui s’est passé. Les équipes ont bénéficié d’une productivité accrue, de délais de livraison plus rapides, d’une plus grande satisfaction des clients et même d’un sentiment d’unité et d’enthousiasme.
Cependant, à mesure qu’Agile s’est étendu des petites équipes dédiées aux grandes organisations, des fissures ont commencé à apparaître. Agile avait été le nouvel outil brillant que tout le monde voulait adopter. Mais cette adoption généralisée s’est souvent produite en silos.
L’adoption des pratiques Agile s’est concentrée uniquement sur l’espace technologique, laissant d’autres parties de l’organisation derrière elles.
Ce parcours cloisonné est devenu un énorme goulot d’étranglement, car le reste de l’organisation a eu du mal à suivre le rythme des changements rapides et des exigences des équipes Agile.
Mauvaise interprétation et mauvaise application
L’un des principaux problèmes conduisant au déclin d’Agile est la mauvaise interprétation et la mauvaise application généralisées de ses principes. De nombreuses organisations ont adopté les pratiques Agile de manière superficielle, sans vraiment comprendre ou s’engager envers ses valeurs.
Les stand-ups quotidiens, sprints et backlogs sont devenus un autre ensemble de tâches plutôt que des outils pour favoriser la collaboration et l’innovation.
De plus, l’utilisation des story points s’est transformée en une compétition, où les équipes étaient récompensées en fonction du nombre de story points qu’elles avaient complétés au cours d’un sprint.
Dans certains cas, les entreprises ont mis en œuvre Agile comme ordre venant d’en haut, sans fournir la stratégie de management du changement nécessaire pour soutenir le changement culturel nécessaire à son succès. Cela a conduit à la désillusion des équipes, qui considéraient Agile comme une autre mode de management plutôt que comme un changement significatif dans leur façon de travailler.
Résistance culturelle
Agile nécessite un changement culturel important, ce qui peut être un obstacle majeur dans les organisations établies. L’évolution vers des équipes auto-organisées et une prise de décision décentralisée contraste fortement avec les structures hiérarchiques traditionnelles. La résistance des cadres intermédiaires, qui se sentent souvent menacés par la perte de contrôle, peut étouffer l’adoption d’Agile.
De plus, l’accent mis par Agile sur la transparence et la responsabilité peut être inconfortable pour les équipes habituées à fonctionner sans sécurité psychologique et sans confiance au sein de l’équipe et avec la direction.
Sans un environnement favorable, ces changements culturels peuvent entraîner des frictionset, en fin de compte, saper les initiatives Agile.
Des stratégies de management du changement, telles que l’établissement de stratégies d’intervention et d’encadrement pour gérer la résistance, auraient favorisé les changements culturels. Par exemple, des séances de coaching sur mesure, des ateliers de renforcement de l’esprit d’équipe, des forums ouverts pour recueillir des commentaires et un soutien continu de la direction auraient pu atténuer les craintes et créer une culture plus tolérante.
Trop d’importance accordée aux outils et aux processus
Au fur et à mesure que l’agilité gagnait en popularité, une pléthore d’outils et de processus ont émergé pour soutenir sa mise en œuvre. Bien que ceux-ci puissent être bénéfiques, une dépendance excessive à leur égard peut entraîner une perte de concentration sur les principes fondamentaux d’Agile.
Les équipes s’enlisent dans la gestion des outils plutôt que dans la création de valeur.
De plus, la commercialisation d’Agile a conduit à la prolifération des certifications et des cadres de travail, créant un paysage fragmenté où l’essence d’Agile est souvent perdue. L’accent est mis sur l’amélioration de la collaboration et de l’adaptabilité pour cocher des cases et obtenir des certifications.
Le rôle du leadership
Bien que le leadership ne soit pas le seul responsable du déclin d’Agile, il joue un rôle crucial. Les leaders qui ne comprennent pas ou ne soutiennent pas les principes Agile peuvent entraver son succès. L’adoption efficace d’Agile nécessite des dirigeants prêts à défendre la cause, à fournir les ressources nécessaires et à favoriser une culture de confiance et d’autonomisation.
Cependant, il est également important de reconnaître que les leaders sont souvent contraints par des pressions et des exigences organisationnelles plus larges.
Le besoin de résultats à court terme et le respect des mesures traditionnelles de réussite peuvent entrer en conflit avec la nature itérative à long terme d’Agile.
Par conséquent, il est essentiel d’avoir un coach de haut niveau spécialisé dans le changement organisationnel et l’agilité pour guider le leadership. Un tel coach peut aider à combler le fossé entre la vision de la direction et l’exécution de l’équipe, en veillant à ce que les principes Agile soient appliqués efficacement et que le changement culturel soit géré en douceur.
Le vrai problème : l’absence de changement stratégique
De nombreuses organisations ont embauché des professionnels ayant des références et une expérience en Agile, mais ont négligé un élément essentiel à une transformation réussie : Une stratégie de changement.
Sans un plan clair pour le changement organisationnel nécessaire au succès d’Agile, ces efforts sont devenus fragmentés et ont souvent conduit à une mise en œuvre incohérente.
Les organisations ont commencé à étendre leur adoption d’Agile sans former d’alliances et obtenir le soutien de tous les secteurs touchés par le changement. En conséquence, les méthodes de travail Agile sont devenues une autre case à cocher, certaines équipes résistant complètement à Agile, disant : « Je n’ai pas le temps pour Agile ! ». L’absence d’une stratégie cohérente de changement culturel et organisationnel a donné lieu à des pratiques Agile qui n’avaient d’Agile que le nom.
Aller de l’avant : Apprendre de l’échec
La disparition d’Agile dans de nombreuses organisations ne signifie pas l’échec de ses principes, mais plutôt les challenges dans leur mise en œuvre dans des environnements variés et complexes. Pour aller de l’avant, il est essentiel de tirer les leçons de ces expériences et de souligner l’importance d’une stratégie globale de management du changement pour véritablement intégrer l’agilité dans la culture de l’organisation. Agile est une approche de travail très puissante, et ses bénéfices peuvent s’étendre au-delà du développement logiciel, répondant ainsi à une idée fausse mais répandue.
Adoptez la véritable agilité : Concentrez-vous sur les valeurs et les principes sous-jacents d’Agile plutôt qu’adhérer de manière rigide à des pratiques spécifiques.
Investissez dans la culture : Donnez la priorité au changement culturel, en favorisant un environnement de collaboration, de transparence et d’amélioration continue. Mettez en œuvre des stratégies de management du changement qui soutiennent ce changement culturel, en veillant à ce qu’Agile soit ancré dans l’ADN de l’organisation.
Engagez les leaders, la direction : Assurez-vous que les leaders sont formés à Agile et s’engagent à soutenir sa mise en œuvre par des actions, et pas seulement par des paroles. Avoir un coach de haut niveau ayant une expertise en changement organisationnel et en agilité peut guider efficacement le leadership.
Étendez Agile au-delà de l’informatique : Reconnaissez qu’Agile n’est pas seulement destiné au développement de logiciels. Appliquez les approches de travail Agile à d’autres domaines de l’organisation, en brisant les silos et en favorisant une culture agile holistique.
Développez un plan stratégique : Créez une stratégie complète pour l’adoption d’Agile qui comprend des objectifs, des délais et des mesures de réussite clairs. Ce plan devrait impliquer la formation d’alliances et l’obtention du soutien de toutes les régions touchées par le changement.
Conclusion : Agile n’est pas mort, mais sa vie ne tient plus qu’à un fil !
La morale de l’histoire est qu’Agile n’est pas vraiment mort, mais qu’il ne tient qu’à un fil. La vérité est que de nombreuses organisations ont embauché des coachs Agile pour former et coacher les équipes sans élaborer de plan stratégique pour le changement nécessaire au succès d’Agile. En comblant ces lacunes stratégiques et culturelles, et en étendant les pratiques Agile au-delà du développement logiciel, les organisations peuvent continuer d’exploiter les avantages d’Agile et s’adapter aux exigences en constante évolution du paysage business moderne.
Britt Smith
Human Centered Agility (Agilité centrée sur l’humain)
Fervente défenseuse de la résilience organisationnelle, Britt se consacre à donner aux entreprises les moyens de naviguer dans l’environnement business dynamique d’aujourd’hui avec force et agilité.
Britt s’est donnée pour mission d’intégrer l’agilité centrée sur l’humain dans les organisations, permettant aux leaders et aux équipes de manager efficacement le changement et de s’adapter aux défis avec innovation et résilience.
Elle est motivée par la vision de réinventer l’avenir du travail. Un avenir où le développement centré sur l’humain est primordial, où les équipes excellent dans un contexte de changement continu et où les organisations non seulement survivent mais prospèrent en donnant la priorité à leurs employés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici un livre blanc qui donne un aperçu de la manière dont l’intelligence artificielle remodèle la gestion des projets Agiles.
Au fur et à mesure que les technologies de l’IA évoluent, elles offrent des outils permettant d’améliorer les processus de prise de décision, d’automatiser les tâches routinières et de personnaliser les interactions avec les parties prenantes. Cette fusion de l’IA avec les méthodologies Agiles permet non seulement d’augmenter l’efficacité des processus, mais aussi de naviguer plus efficacement dans la complexité des demandes de projets modernes.
Dr. Leon Herszon, MSc, PhD, PMP, CSM, CSPO, DASSM. Dr. Herszon is a highly accomplished, versatile, and respected executive with over 30 years of extensive achievements within diverse environments utilizing exemplary management, analytical, organizational, and people skills. He has experience leading teams to improve performance and manage business transformation focused on agility, transparency, teamwork, experimentation, and innovation. Dr. Herszon’s doctoral research explored factors that contribute to project complexity and proposed a model to manage complexity.
Dr. Herszon performed roles as executive and managing director, Chief Agility Officer, entrepreneur, portfolio, program and project director, business transformation leader, corporate educator, and is currently the Head of IIL’s global consulting practice. He is also an Adjunct Professor at the prestigious Rutgers Business School. Dr. Herszon can communicate in English, French, Portuguese, German, and Spanish, and is also a several times Ironman triathlon finisher.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les meilleures pratiques du management de projet, programme et portefeuille de projets, partage d’expériences, questions/réponses sur les thèmes de ce domaine qui vous intéresse.
Ce blog est également ouvert aux discussions sur le leadership, l’innovation, les petites idées qui permettent de se faciliter la vie professionnelle et de progresser.
Ci-dessus, un extrait du contenu du tout premier billet, le 26 Juin 2009 !
Le blog DantotsuPM est né de mon envie de partager (dans la continuité de la création du PMI® France-Sud dans les années 2000).
Pourquoi ce nom « DantotsuPM » ?
Comme beaucoup d’entre vous qui suivez mes publications, je cherche en permanence à améliorer les multiples compétences qui permettent de progresser dans ma vie et mes pratiques.
C’est d’ailleurs de là que vient le nom du blog car le mot Dantotsuque j’ai croisé lors de voyages professionnels au pays du soleil levant signifie en Japonais « rechercher en permanence le meilleur du meilleur ».
J’ai accolé PM à Dantotsu pour Project Management, ma passion : DantotsuPM était né !
Je sélectionne, traduit en français et publie sur ce blog des billets liés au management de projets, programmes, Project Management Office (PMO) et Portfeuilles de projets (PPM), aux soft skills, à l’agilité, à l’analyse des besoins business et au leadership.
N’hésitez pas à réagir aux billets avec vos commentaires.
Contactez-moi sur LinkedIn pour publier vos propres articles.
Si votre société souhaite accroitre sa visibilité auprès des managers de projets et de leurs organisations, devenez sponsor-partenaire du blog DantotsuPM.
Il y a déjà plus de 4000 billets en ligne et j’en publie un nouveau chaque jour…
Je vous invite donc à venir y piocher à votre rythme et selon vos besoins.
Visitez également l’espace ressources gratuitesqui contient de nombreux pointeurs vers des documents utiles aux managers de projets.
J’espère que vous apprécierez d’utiliser les catégories qui regroupent les billets autour de grands thèmes ainsi que les mots clés qui rendront vos recherches plus faciles (dans la colonne de droite).
Voilà, je vous souhaite de belles lectures et de riches échanges et contributions à notre communauté de passionné.e.s du management de projets.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pour qu’une approche Agile, itérative et adaptative, fonctionne pour votre projet, vous devez avoir le bon état d’esprit et l’insuffler dans toute votre organisation.
L’adoption réussie des méthodologies agiles nécessite d’avoir le bon état d’esprit.
Pour que cette approche itérative et adaptative marche, vous devez adopter les éléments et caractéristiques suivants.
#1 – Rapidité et expérience.
Agile produit des résultats rapidement, mais cette vitesse a un coût. Vous avez besoin de personnes expérimentées et dédiées dans l’équipe pour produire des résultats de qualité et vous avez besoin d’une chaine de management impliquée dans l’effort, afin qu’elle sache ce qu’elle obtient. N’essayez pas de demander à des personnes moins expérimentées de produire des livrables intermédiaires, qui sont ensuite examinés par des personnes plus expérimentées. Si vous faites cela, les personnes expérimentées peuvent trouver des lacunes dans les livrables et demander des modifications. Pour que l’agilité fonctionne, les livrables et les décisions doivent être « à l’épreuve du veto ». C’est-à-dire qu’ils ne peuvent pas être annulés par un responsable d’équipe ou un manager qui n’aime pas le résultat. Cela démoralise l’équipe et sacrifie la vitesse que l’agilité est censée générer.
#2 – Un état d’esprit de « permettre l’apprentissage ».
L’un des bénéfices de l’agilité est qu’il permet aux parties prenantes et aux membres de l’équipe d’apprendre. L’utilisation des livrables inspire l’apprentissage et l’amélioration continue des produits du projet. Cela signifie que les parties prenantes doivent être prêtes à ce que les produits soient retravaillés après l’installation. De plus, cet apprentissage déplace souvent les priorités de la production de nouveaux livrables vers la refonte des précédents. Dans l’ensemble, cette volatilité dans ce sur quoi l’équipe travaille est productive. L’inconvénient est que les parties prenantes désireuses d’utiliser de nouvelles fonctionnalités pourraient être déçues. Pour soutenir l’état d’esprit de l’organisation apprenante, assurez-vous de communiquer et de rassurer les parties prenantes.
#3 – Encourager de petites améliorations fréquentes.
Agile produit rapidement les livrables les plus importants pour améliorer l’entreprise. Cette livraison rapide de valeur peut créer des attentes selon lesquelles les améliorations de l’entreprise se poursuivront à ce même rythme. Oui, l’amélioration se poursuivra, mais pas au même rythme qu’au début du projet. Les résultats produits par l’agilité sont généralement des améliorations progressives. Il est rare que l’agilité produise de grands sauts quantiques. Assurez-vous que les parties prenantes comprennent que les améliorations seront mineures et que des changements se produiront souvent au fur et à mesure que le projet se poursuit.
#4 – Confiance et responsabilisation.
Pour qu’une équipe agile prospère, les parties prenantes, la direction, même les utilisateurs finaux, doivent faire confiance à l’équipe. L’équipe doit avoir la permission de décider comment atteindre les objectifs business. Cela inclut la prise de décisions sur l’ajustement des processus métier. Si la confiance n’est pas là, la valeur de l’agilité diminue. La vitesse diminue et les membres de l’équipe seront frustrés.
#5 – Simplicité.
Les méthodologies agiles privilégient la simplicité à la complexité et à la documentation excessive. La simplicité s’applique aux processus, à la communication et aux livrables. Les parties prenantes doivent renoncer à la bureaucratie et à la documentation qu’elles ont reçues dans le passé. L’accent est plutôt mis sur la livraison de solutions fonctionnelles. La documentation est développée à partir d’un exercice d’observation de la façon dont les utilisateurs finaux utilisent ces solutions fonctionnelles.
Avez-vous d’autres suggestions à ajouter pour un bel état d’esprit agile ? Partagez-les avec nous.
Pour en savoir plus sur l’agilité, consultez la formation de Doug RoeAgile Foundations.
partagez ce billet avec vos amis, collègues et relations professionnelles
La session d’affinement de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit et des priorités.
La session d’affinement de l’arriéré de produit (Product Backlog Refinement) n’est pas un événement Scrum officiel, mais c’est une activité cruciale qui aide les équipes Scrum à parvenir à une compréhension commune des éléments de l’arriéré de produit en préparation à la planification du sprint. Les équipes qui adoptent l’amélioration de l’arriéré de produit comme pratique complémentaire ont tendance à avoir des événements de planification de sprint plus fluides. Le nombre de sessions de raffinement au sein d’un sprint dépend de divers facteurs tels que l’état de l’arriéré de produit, la maturité du produit, la disponibilité et l’expérience de l’équipe Scrum.
Il y a de nombreuses de façons de faciliter une session d’affinement de l’arriéré de produit, mais je présente ici certaines des activités que j’attendrais d’une équipe Scrum dans l’une de ces sessions. Celles-ci ne sont pas présentées dans un ordre particulier.
Ventiler les éléments de l’arriéré de produit (Product Backlog Items / PBI)
Dans la session d’affinement de l’arriéré de produit, l’équipe Scrum doit chercher à décomposer les PBI jusqu’à ce qu’ils soient suffisamment petits pour tenir dans le sprint.
La définition de terminé (done) doit être utilisée comme guide pour discuter du travail à accomplir pour chaque PBI du sprint.
Il y a de nombreuses techniques qui peuvent être utilisées pour décomposer les PBI, mais je préfère le découpage vertical des PBI, car l’équipe Scrum a une plus grande probabilité de fournir un incrément utilisable à partir d’un PBI, lorsque le PBI est découpé verticalement.
Estimer les PBI
Les équipes Scrum qui pratiquent l’estimation en tant que pratique complémentaire doivent fournir une prévision de l’effort requis pour fournir des PBI en utilisant la définition de terminé (done) pour le produit comme guide.
Pour ces équipes, l’estimation des PBI aide l’équipe Scrum à sélectionner des éléments de l’arriéré de produit jusqu’à la pleine capacité des développeurs. Si des estimations ont déjà été fournies pour les PBI, l’animateur de la session d’affinement de l’arriéré de produit doit reconfirmer que chaque développeur reste à l’aise avec l’estimation qui a été précédemment enregistrée sur le PBI.
Les critères d’acceptation devraient être revus pour en vérifier la clarté et l’exhaustivité lors de la séance d’amélioration de l’arriéré de produit. L’animateur doit inviter les participants à la session d’amélioration de l’arriéré de produit à poser des questions et à demander des éclaircissements si nécessaire. Il y a des cas où l’équipe n’arrive pas à s’entendre sur les critères d’acceptation, en particulier pour un PBI complexe ; L’équipe Scrum pourrait alors trouver utile de réexaminer le « pourquoi ? ». Le Product Owner doit être en mesure d’exprimer clairement la valeur du PBI ; D’après mon expérience, une fois que la valeur est transparente pour tous les participants, les développeurs peuvent s’autogérer pour déterminer les détails de ce qui doit être fait et comment le travail serait accompli.
Discutez des dépendances et des blocages
Attention aux dépendances croisées qui s’emmêlent et créent des nœuds inextricables.
Cela n’aurait aucun sens d’intégrer une histoire utilisateur / story avec des dépendances et des blocages dans un sprint, car cette story ne sera probablement pas terminée dans le sprint. L’équipe Scrum doit discuter de toutes les dépendances et de tous les bloqueurs pour s’assurer que tout le monde a une compréhension commune des dépendances et des blocages ; L’équipe Scrum doit mettre en place un plan pour résoudre ces dépendances et ces blocages. Le cas échéant, ces dépendances et blocages doivent être représentés dans l’arriéré de produit et attribuées aux personnes qui travaillent à les supprimer. À titre indicatif, l’équipe Scrum ne doit PAS présenter d’éléments avec des dépendances et des blocages non résolus pour la planification du sprint, sauf s’il existe un plan pour résoudre ces obstacles au sein du sprint.
Priorisez l’arriéré de produit
Le Product Owner est responsable de la priorisation de l’arriéré de produit et il existe un certain nombre de raisons qui peuvent être prises en compte telles que la Valeur, la Priorité, la Cohérence Business, la Cohérence Technique, etc. Le Product Owner doit prendre l’habitude de garder l’arriéré produit ordonné à tout moment et une session telle que la session d’affinement de l’arriéré de produit est un bon moment pour examiner et mettre à jour l’ordre des PBI dans l’arriéré de produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Comme indiqué dans l’introduction, la session d’amélioration de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit qu’il contient et des éléments de l’arriéré de produit qui ont émergé pour atteindre l’objectif produit.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si certains pensent que « Agile » ou les idées propagées par les praticiens Agile ne devraient jamais être critiquées, Michael Küsters explique ici pourquoi ceci est totalement l’inverse de ce qu’il convient de faire.
Certaines personnes pensent que « Agile » ou les idées propagées par les praticiens Agile ne devraient pas être critiquées. Elles considèrent ces critiques comme un manque de compréhension de l’agilité ou un manque de respect pour les agilistes. Je ne suis pas d’accord. Approfondissons cette question et explorons comment la critique se croise avec la science, le raisonnement et la croissance pour donner vie aux principes Agile.
Agile n’est pas une religion
Il est tentant de défendre Agile contre les critiques. Mais cela transforme l’approche pragmatique et empirique en fanatisme religieux. Nous ne rédigeons pas de Sainte Écriture ni de prophéties sur une vérité et des preuves observables.
L’agilité n’est pas dogmatique.
Elle se nourrit de l’ouverture, de l’interaction et d’une diffusion objective d’idées plausibles. La traiter comme un dogme inattaquable transforme cette façon dynamique de faire la meilleure chose possible en une pratique sectaire.
Le culte du dogme
Essayer de défendre farouchement « Agile » contre la critique crée un paradoxe : Agile, de par sa conception, se nourrit de l’ouverture, de l’interaction et de la recherche de meilleures solutions.
En faire un dogme étouffe le progrès et la croissance. Le dogmatisme, qu’il soit religieux ou idéologique, résiste à la remise en question et à la dissidence. Agile, cependant, accueille les deux.
Agile, c’est le dynamisme
« Agile » n’est pas gravé dans le marbre : c’est vivant, évolutif. Ses valeurs fondamentales soulignent la nécessité d’une réflexion et d’une adaptation continues.
Les praticiens agiles doivent adopter la critique comme catalyseur de croissance.
Science et Agile : Des âmes sœurs
« Agile » a été conçu à partir de la frustration face aux méthodologies de gestion de projet lourdes qui ont conduit à plus d’échecs que de succès. Ses fondateurs recherchaient une alternative qui valorise l’interaction, la collaboration, la flexibilité et la réactivité. C’est le contraire des dogmes religieux : Agile n’exige pas une foi inébranlable. Au lieu de cela, Agile encourage l’expérimentation empirique et l’adaptation.
Une place pour le scepticisme
Le progrès scientifique repose sur le scepticisme, la curiosité et la volonté de remettre en question les théories dominantes. Agile partage cet état d’esprit. Lorsque les praticiens remettent en question les hypothèses, expérimentent et apprennent, ils incarnent l’état d’esprit scientifique. L’approche empirique d’Agile nous encourage à examiner les pratiques, à écarter ce qui ne fonctionne pas et à affiner ce qui fonctionne. C’est une dérogation au dogme, où l’adhésion l’emporte sur les preuves.
Bienvenue à la critique valide
Une idée ou une pratique qui ne résiste pas à la critique est intrinsèquement imparfaite. Un examen rigoureux affûte nos outils. Lorsque la critique surgit, nous devons soit démystifier la critique avec des preuves, soit adapter notre approche à la critique. La résilience de l’agilité réside dans sa capacité à évoluer sur la base de retours valides. Cela ne correspond pas au rejet catégorique des idées inconfortables.
Conditions de laboratoire
Imaginez Agile comme un laboratoire : Un espace où les hypothèses sont testées, les résultats analysés et les théories affinées. Tout comme les scientifiques révisent leurs modèles en fonction des retours et des preuves empiriques, les praticiens agiles doivent faire de même. Un état d’esprit de laboratoire nous encourage à accepter la critique, à apprendre de nos échecs et à itérer vers l’excellence.
Pas de vaches sacrées
Soyez factuel, examinez les preuves tangibles.
Tant que nous nous en tiendrons à nos hypothèses, quelles que soient les preuves, nous aurons du mal à produire les meilleurs résultats possibles.
Faire preuve de souplesse
L’agilité repose sur la flexibilité, l’adaptabilité et l’apprentissage. La rigidité étouffe la croissance. En restant ouverts au changement et en remettant en question les normes établies, nous créons un environnement propice à l’innovation.
Lâcher prise sur les idées
Métaphoriquement parlant, les agilistes doivent manier une arme pour abattre les vaches sacrées, ces croyances ou pratiques incontestées qui se dressent entre nous et l’excellence. Cela nous aide à évoluer, à apprendre de nos erreurs et à affiner nos approches.
Examen minutieux et validité des réflexions
Les idées doivent faire l’objet d’un examen constant. Un examen rigoureux affine notre compréhension et garantit que seuls les concepts les plus fiables sont propagés. Les réactions émotionnelles ou l’arrêt de la réflexion entravent les progrès.
Le creuset de l’examen minutieux
L’agilité s’épanouit lorsqu’elle est soumise à un examen rigoureux. Tout comme les métaux sont raffinés dans un creuset, les idées agiles sont affinées par l’examen. Lorsque nous remettons en question des hypothèses, nous affinons notre compréhension et écartons ce qui ne tient pas la route. L’examen minutieux n’est pas une menace ; C’est un catalyseur de croissance.
Résilience émotionnelle
Les émotions ont leur place, mais elles sont souvent de mauvaises conseillères lorsqu’il s’agit de faire face aux critiques. Il est naturel de répondre à la critique par une réaction émotionnelle qui obscurcit notre jugement. La raison, la logique et les preuves sont des guides beaucoup plus fiables lorsque les émotions s’enflamment.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Critique constructive
« Agile » bénéficie d’une critique constructive. Plutôt que d’aborder la dissidence avec négativité, nous pouvons la voir comme un moyen de favoriser la croissance, d’affiner nos pratiques et d’élever notre performance.
Évitez le jargon à la mode
Les arguments « agiles » se réduisent souvent en une liste de mots à la mode, où les slogans remplacent la substance. Évitez le jargon et concentrez-vous sur le fond : Montrez-moi la « meilleure façon » avec clarté, preuves à l’appui. Les mots à la mode n’impressionneront pas ceux qui cherchent des réponses sérieuses.
Soyez positif
La critique n’est pas une attaque contre laquelle il faut se défendre. Au lieu de couper court à la question, ouvrons une conversation. En remettant en question les hypothèses, nous contribuons à la croissance. Mais de la même manière, le simple fait de s’en prendre à quelque chose étouffe le progrès. Cela ne conduira pas à une amélioration.
Soyez raisonnable
Les attaques ad hominem et la manipulation psychologique n’ont pas leur place dans un environnement collaboratif. Au lieu de cela, engageons-nous dans un raisonnement réfléchi. Lorsque vous n’êtes pas d’accord, présentez votre cas de manière logique. « Agile » se nourrit du respect des points de vue divergents, percevant les questions inconfortables comme des invitations à apprendre.
L’agilité n’est pas un monument figé ; C’est un jardin dynamique.
Arrosez-le de critiques constructives, élaguez les branches mortes et regardez-le s’épanouir. Cultivons la croissance, l’apprentissage et un discours respectueux.
partagez ce billet avec vos amis, collègues et relations professionnelles
La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.
Il existe un certain nombre d’approches qui ont été recommandées pour les Technical Spike.
Il s’agit notamment de :
Estimation et dimensionnement d’une histoire de Technical Spike
Limiter dans le temps (Timeboxing) un Technical Spike.
Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.
Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.
Je suggérerais au Product Owner / Business Analyst en collaboration avec unmembre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les avantages de la spécification des exigences axée sur le comportement dès le départ sont les suivants.
L’objectif du Technical Spike est clairement défini à l’avance et, en tant que tel, le développeur est clair sur ce qu’est le livrable.
La définition de DONE pour le Technical Spike est dès que toutes les exigences spécifiées sont satisfaites.
Le développeur ou un testeur peut automatiser le script de développement axé sur le comportement en exigences exécutables.
Le risque de consacrer trop de temps/d’efforts au Technical Spike est minimisé.
Une ligne de base d’exigences pour la mise en œuvre réelle évolue à partir du Technical Spike.
Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevésuffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.
Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’agilité organisationnelle implique que l’ensemble de l’organisation soit un réseau interdépendant d’équipes autogérées. De telles organisations nécessitent un type de leadership différent aux différents niveaux de l’organisation.
Scrum et d’autres cadres d’agilité se basent sur des équipes auto-organisées / autogérées.
L’agilité organisationnelle implique que l’ensemble de l’organisation soit un réseau interdépendant d’équipes autogérées. De telles organisations nécessitent un type de leadership différent aux différents niveaux de l’organisation.
« Les individus et les interactions plutôt que les processus et les outils »
Ma phrase préférée dans le Manifeste Agile est « Les individus et les interactions plutôt que les processus et les outils ». Cela implique que les leaders doivent créer un environnement permettant aux équipes de collaborer au sein des équipes et entre les équipes.
Dans cet article, je décris 5 caractéristiques des leaders qui réussissent à créer un environnement propice à l’épanouissement des équipes agiles.
#1 – Des leaders qui responsabilisent les équipes.
Ces leaders démontrent aux équipes qu’elles peuvent et doivent prendre des décisions qui affectent leurs équipes. Ils veillent à ce que leurs équipes possèdent les compétences appropriées et disposent en permanence d’informations qui leur permettent de s’autogérer.
Les équipes autonomes ont le pouvoir de prendre des décisions qui affectent leur façon de travailler et le produit qu’elles créent. Elles ont également la permission d’expérimenter et d’échouer (d’apprendre).
#2 – Des leaders qui font confiance à leurs équipes.
La confiance est une condition fondamentale pour que l’agilité prospère. Les leaders qui ont peu confiance en l’équipe ont tendance à micro-manager leur équipe, ce qui entraîne la frustration des personnes qui travaillent dans ces équipes. Un processus de gouvernance trop restrictif pourrait être le signe d’un manque de confiance dans le fait que l’équipe fera ce qu’il faut. Les contrôles sont une bonne chose, mais dans les situations où ils entravent la création de valeur, les leaders doivent se poser la question de la confiance.
#3 – Les leaders qui capturent, suivent et améliorent les indicateurs de valeur.
Le type de leaders qui soutiennent l’agilité s’intéresse à des indicateurs tels que :
Contrairement aux leaders qui s’intéresseraient qu’à des indicateurs tels que la quantité de travail effectuée par l’équipe, l’utilisation des ressources et nombreux autres indicateurs qui ne correspondent pas à l’agilité.
Les leaders qui se concentrent sur leur équipe et travaillent avec elle pour améliorer les indicateurs de valeur constituent des équipes et des organisations solides qui sont bien positionnées pour apporter de la valeur à leurs clients.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
#4 – Des leaders qui se concentrent sur les résultats plutôt que sur les livrables.
Faire rêver ces équipes plutôt que les surveiller.
Nous avons souffert de leaders qui se concentraient trop sur les résultats tels que le nombre de lignes de code produites, les articles de communication écrits, les billets publiés sur les médias sociaux, etc. car ceux-ci sont faciles à capturer.
Nous coachons ces leaders pour qu’ils aident leurs équipes à définir des résultats, ce n’est qu’alors que ces leaders auront plus de chances de constituer des équipes autogérées. Ces leaders co-créent des objectifs avec leurs équipes et les aident à atteindre ces objectifs. Il peut s’agir, par exemple, d’améliorer le Net Promoter Score de 20 % ou d’améliorer la fidélisation des clients de 30 % d’une année sur l’autre. Une fois les objectifs fixés, les leaders doivent permettre à leurs équipes de trouver des idées qui pourraient les aider à atteindre ces objectifs et à mesurer leurs progrès.
#5 – Des leaders qui coachent leurs équipes.
Une organisation agile est une organisation dans laquelle chaque leader est un coach, c’est-à-dire qu’il aide les membres de son équipe à être de meilleures versions d’eux-mêmes. Ces leaders sont des cheerleaders pour leur équipe, ils n’entravent pas le travail et ils déploient de l’autonomie, de la maîtrise et de la détermination pour motiver leur équipe. Ces leaders délèguent autant que possible à leur équipe et « révèlent plutôt que résolvent » lorsque leurs équipes sont confrontées à des défis.
Notre travail a vu beaucoup trop d’organisations commencer leur parcours agile en formant leurs équipes alors que les leaders sont généralement trop occupés pour se former. Les leaders ne peuvent pas mener des efforts de changement dont ils ne font pas eux-mêmes partie.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous vous retrouvez souvent à devoir repousser des histoires utilisateur d’un sprint au suivant, peut-être n’utilisez-vous pas les bonnes métriques ?
Flow Metrics and Why They Matter to Teams and Managers par Johanna Rothman
Je continue à travailler avec des gens qui ont du mal avec leur approche agile. Ils me disent que leur estimation relative ne fonctionne pas pour eux. Ils continuent de repousser des items, d’un sprint à l’autre. Ils ont repoussé certains items 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 remédier à la situation.
C’est alors que je leur recommande d’utiliser les métriques de flux au lieu d’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles n’aident pas.
Les métriques de flux sont l’unique « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces métriques exposent les principes qui sous-tendent l’agilité. Lorsque les équipes mesurent ces 4 métriques, 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 sont importants pour les équipes et les managers.
Tout d’abord, voyons quelles sont les métriques de flux.
4 Métriques de flux
WIP / Work In Progress, Travail en cours : Tout le travail qui est en cours : commencé et pas encore terminé.
Throughput, Débit : Nombre d’items de travail qu’une équipe/responsable peut effectuer par unité de temps.
Cycle Time, Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
Aging, Vieillissement : Depuis combien de temps un travail est en cours.
Bien que les métriques de flux soient indépendantes, elles créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager. Commençons par une équipe.
Interaction entre les métriques de flux
Imaginez une équipe qui termine régulièrement un item de travail chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense qu’il 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 item de plus 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 juste parce qu’elle a commencé un item supplémentaire.
En fait, leur débit a diminué parce qu’ils travaillent sur deux éléments en même temps et qu’ils n’ont terminé aucun d’entre eux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux items de travail plus anciens, ce qui augmente le vieillissement de tous les items.
La demande de travail augmente, tout cela parce que l’équipe n’en a pas terminé « assez ».
C’est une boucle de rétroaction qui se renforce. Au fur et à mesure que l’encours augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des items plus anciens. Tout cela augmente leurs travaux en cours.
Nous tournons en rond, créant un environnement de pire en pire pour l’équipe.
Si vous avez déjà vu une équipe « repousser » des histoires utilisateur d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse ne sont pas utiles, mais la mesure du temps de cycle fonctionne.
La bonne nouvelle, c’est que l’équipe peut intervenir n’importe où dans ce cycle et apporter des améliorations.
Interventions d’équipe
Voici les questions que l’équipe peut poser :
Quelle est la seule et unique chose sur laquelle nous devrions travailler et terminer ? (Commencez par les travaux en cours.)
Quel âge a notre item le plus ancien ? Est-ce qu’il a encore de la valeur ? (Commencez par considérer le vieillissement.)
Que devrions-nous changer dans notre travail pour réduire notre temps de cycle ? (Concentrez-vous sur le temps de cycle.)
Comment pouvons-nous augmenter notre débit ? (Concentrez-vous sur le débit.)
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 travail en cours à un seul élément, elle doit modifier sa façon de travailler.
Ensuite, plus le WIP est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens éléments est réduit.
C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.
Est-ce que « un » item est toujours le bon nombre pour les travaux en cours ? Non, je recommande à l’équipe de commencer par diviser par deux le nombre de personnes dans l’équipe (pour déterminer le WIP optimal de l’équipe). Si vous avez un nombre impair de personnes, arrondissez en dessous. Donc, si vous avez cinq personnes, utilisez « deux » comme travail en cours maximal.
Mais votre équipe peut commencer par des changements au sein de l’équipe pour réduire le temps de cycle et augmenter le rendement. Vous pouvez commencer n’importe où car c’est une boucle de rétroaction.
Interventions du management
Les managers travaillent différemment. Les métriques ne changent pas, mais les interventions du management sont différentes.
Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne produisent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées de « Pourquoi minimiser le temps de décision de la direction/ Why Minimize Management Decision Time” sont si importantes.
Plus les managers ont de décisions non finalisées (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus l’encours WIP d’un responsable 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 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 le WIP.)
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 qui fonctionne pour eux, et non contre eux.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les métriques de flux peuvent guider de meilleures décisions
Lorsque les équipes et les responsables voient clairement leurs travaux en cours/WIP, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils souhaitent modifier.
Est-il temps de renforcer la collaboration ?
Commencez peut-être par la question de la valeur, comme dans « Quelle est la chose la plus précieuse que nous puissions terminer aujourd’hui ? »
Les métriques de flux sont importantes car elles permettent aux équipes et aux responsables de voir et de gérer leur façon de travailler.
Utilisez-les pour avoir un aperçu de l’endroit où vous pourriez choisir de modifier votre travail.
Cette lettre d’information aborde les sujets abordés dans les livres :
Une équipe autonome et autogérée s’épanouit lorsque les liens hiérarchiques sont relégués au second plan, ce qui permet aux responsabilités Scrum de guider les méthodes de travail. Bien que les hiérarchies organisationnelles persistent, en particulier lors de la formation des équipes Scrum, il est crucial de discuter des privilèges et de leur impact sur la capacité d’une équipe à s’auto-gérer.
Privilège hiérarchique
Cette forme explicite de privilège survient lorsqu’une équipe Scrum est composée d’employés ayant différents niveaux d’ancienneté. Les cadres supérieurs exercent une influence, prenant parfois des décisions unilatérales qui affectent l’ensemble de l’équipe. Par exemple, un responsable hiérarchique, également développeur au sein de l’équipe Scrum, pourrait choisir d’annuler une rétrospective de Sprint sans consulter les autres membres de l’équipe.
Privilège d’expertise
Accordé aux personnes expérimentées dans le domaine ou les compétences requises. Ce privilège peut conduire à une prise de décision rapide par les développeurs seniors et les responsables techniques, ce qui peut étouffer la contribution des membres moins expérimentés de l’équipe. Bien que des décisions rapides puissent être nécessaires dans certaines situations, il est essentiel d’assurer l’inclusivité.
Privilège culturel
Dans les équipes Scrum géographiquement distribuées, les nuances culturelles peuvent créer une dynamique de privilège. Les membres de l’équipe issus de cultures plus expressives peuvent involontairement dominer les discussions, ignorant les autres moins enclins aux confrontations. La reconnaissance et l’atténuation de ce privilège culturel favorisent un environnement véritablement inclusif et collaboratif.
Ces privilèges conduisent souvent quelques membres de l’équipe à prendre des décisions pour l’ensemble de l’équipe Scrum, s’écartant ainsi de l’essence de l’auto-gestion.
Le Scrum Master étant au service de l’équipe Scrum, ses interventions sont essentielles.
Reconnaître les privilèges au sein de l’équipe : Animez une conversation pour discuter de toutes les formes de privilèges au sein de l’équipe. La sensibilisation est la première étape pour faire prendre conscience aux membres de l’équipe de leurs privilèges et leur impact sur la collaboration et l’auto-gestion.
Discuter des techniques de gestion des privilèges : Aidez l’équipe à explorer les techniques permettant de gérer les privilèges. Les membres de l’équipe peuvent suggérer de créer de l’espace pour les autres et d’être plus conscients de ceux qui ne sont pas dans des positions privilégiées. Des techniques telles que la LiberatingStructure 1-2-4-All offrent des chances égales à chaque membre de l’équipe de participer.
Tenir chacun mutuellement responsable : Établissez ou mettez à jour un accord de travail qui comprend des techniques pour s’assurer que les décisions sont prises avec un minimum de privilèges. Définissez comment n’importe quel membre de l’équipe peut intervenir si cet accord de travail n’est pas respecté.
Pour illustrer l’impact des privilèges, prenons l’exemple d’une expérience récente.
Lors d’une session de planification de sprint avec un nombre limité de membres de l’équipe, le Product Owner, en raison de son rang supérieur, a proposé d’annuler la réunion sans consulter tous les membres de l’équipe. Reconnaissant ce privilège, le Scrum Master est intervenu, ce qui a déclenché une discussion qui a mené à un processus décisionnel plus inclusif.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
La prise en compte de la dynamique des privilèges garantit que les équipes Scrum incarnent les principes d’autonomie, de collaboration et d’auto-gestion, ce qui conduit au développement d’équipes hautement efficaces capables d’apporter de la valeur à leurs parties prenantes.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 