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
L’UAT continuera-t-elle à être une pratique pertinente pour les équipes agiles et leurs parties prenantes qui cherchent à créer de meilleurs produits plus rapidement ?
Impact of User Acceptance Testing (UAT) phase on Organisation Agility par Sam Adesoga
Le test d’acceptation par l’utilisateur (User Acceptance Testing / UAT) est une pratique de développement de produits très populaire dans les méthodes traditionnelles de développement de produits. Ces méthodologies traditionnelles sont caractérisées par de longues phases de développement et de déploiement du produit dans un environnement UAT, suivies d’une longue période de test dans l’environnement UAT.
La question est de savoir si l’UAT continuera d’être une pratique pertinente pour les équipes agiles et leurs parties prenantes, en partant du principe que les organisations adoptent des méthodes de travail agiles pour être en mesure de créer de meilleurs produits plus rapidement. La phase d’UAT est une pratique qui est souvent mandatée par les cadres supérieurs au sein de l’organisation et parce que la phase d’UAT ne peut pas s’intégrer dans le Sprint (dans le cas des équipes Scrum), ces équipes contournent l’« obstacle » en modifiant la définition de Done pour leur produit afin d’exclure l’UAT. En d’autres termes, l’équipe Scrum a tendance à modifier son livrable de Sprint pour en faire un produit dont le développement est terminé mais qui n’a pas encore été testé par les utilisateurs et/ou les parties prenantes.
Pour le scénario décrit ci-dessus, quelle que soit la vitesse à laquelle l’équipe Scrum travaille pour amener ses éléments de travail à l’état de développement terminé, l’équipe Scrum crée effectivement un lot de travail qui n’est pas délivré en production avant un certain temps. La phase UAT peut durer de 4 semaines à 3 mois ; et nous pensons que la phase UAT ne rend pas service à tous les efforts visant à renforcer les capacités d’agilité de l’organisation.
Les approches agiles tels que Scrum aident les organisations et les équipes produit à gérer la complexité, et les implémentations de ces approches ne doivent pas introduire de complexité supplémentaire.
Voici quelques exemples de complexité supplémentaire introduite par une pratique distincte de l’UAT et question à se poser :
Comment les équipes corrigeront-elles les défauts détectés pendant la phase d’UAT ?
Cela affectera-t-il la capacité de l’équipe à se concentrer sur le travail de sprint ?
Les défauts seront-ils corrigés par une sous-équipe de développeurs ?
Comment les équipes fusionneront-elles l’incrément de la phase UAT et l’incrément des sprints ?
Chez Valuehut, nous aidons nos clients à intégrer toutes les formes de tests au sein du Sprint (y compris les tests d’acceptation par les utilisateurs) ; La promesse de Scrum est d’aider les équipes à fournir des produits utilisables et précieux à leurs utilisateurs le plus rapidement possible et en renforçant les capacités au sein de l’équipe pour effectuer des tests d’acceptation par les utilisateurs dans le cadre du Sprint. L’équipe a alors plus de chances de fournir un produit précieux et disponible à ses utilisateurs / parties prenantes dans chaque sprint.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Il existe 3 modèles et approches associées que nous avons suivis pour aider les équipes Scrum à éliminer la phase d’UAT de leur méthodologie de livraison de produits.
#1 – Environnements de test qui ne représentent pas l’environnement de production.
Les équipes Scrum qui n’ont pas accès à un environnement de test qui est une représentation de l’environnement de production disposent généralement d’un environnement UAT, qui est partagé par de nombreuses équipes. La non-représentativité peut faire référence à la taille et à la capacité de l’environnement ou à un environnement qui n’est pas configuré correctement avec toutes les applications en amont et en aval.
Pour résoudre ces problèmes, l’équipe doit argumenter en permanence pour avoir un environnement qui représente l’environnement de production. Rendre transparentes pour la direction les implications en termes de coûts qui pourraient être des opportunités perdues en raison de délais de livraison allongés.
#2 – Cas de test et scénarios utilisateurs inconnus.
Souvent, les utilisateurs professionnels qui sont censés exécuter le test d’acceptation utilisateur ont créé un ensemble de scénarios et de cas de test qui n’ont pas été partagés avec les développeurs.
Dans ce cas, l’équipe Scrum devrait plaider pour que ces scénarios utilisateur soient partagés avec l’équipe Scrum en s’associant aux utilisateurs professionnels et en utilisant le coût de la reprise pour répondre à ces scénarios.
#3 – Indisponibilité des données de test dans l’environnement de test.
Dans cette situation, l’entreprise n’est généralement pas confortable avec l’idée de charger des données de test représentatives dans les environnements de test pour un certain nombre de raisons, telles qu’un environnement de test inadapté ou un problème de confidentialité des données.
Les développeurs doivent s’efforcer d’anonymiser les données et de créer des jeux de test qui permettent à l’équipe Scrum d’accéder de manière cohérente à des données de test représentatives.
Élimination de phase d’UAT ?
Il convient de noter que l’élimination de la phase d’UAT prend du temps et nécessite que les équipes Produit s’associent aux leaders de l’entreprise sur une longue période de temps, en effectuant de petites expériences à chaque fois jusqu’à ce que la phase d’UAT soit rendue redondante. La seule façon de rendre la phase d’UAT redondante est de rassembler suffisamment de preuves empiriques qu’aucun défaut n’est trouvé dans cette phase d’UAT ; Cela permet d’établir la confiance avec les parties prenantes au fil du temps, et l’équipe Scrum doit fournir aux parties prenantes la preuve des tests exécutés dans chaque sprint.
La capacité d’agilité organisationnelle aide les organisations à être efficaces (en créant les bons produits, par exemple un produit que les clients aiment utiliser) et efficientes (en construisant les bons produits, par exemple en réduisant les délais de mise sur le marché) ; Par conséquent :
Les organisations qui veulent être compétitives dans un monde complexe doivent repenser des pratiques telles que la phase d’acceptation par les utilisateurs, qui ralentissent le temps total nécessaire pour mettre de nouveaux produits ou fonctionnalités entre les mains de leurs clients.
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
Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?
La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.
Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.
En 1961, Little a énoncé son théorème :
Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.
Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.
De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).
Cette formule est souvent exprimée ainsi :
WIP = T x LT
ou encore
LT = WIP / T
Toute augmentation des travaux en cours WIP augmente automatiquement les délais.
Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.
De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
La loi de Little dans le cadre du management de projet
Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.
Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.
Prenez un exemple :
Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.
Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.
Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.
Bien sûr, tout n’est pas si linéaire…
En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…
Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.
Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.
Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.
Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.
Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.
Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, leswitching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.
En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.
Et pour le management de Portefeuille de Projets (PPM) ?
La loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.
Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !
Plus spécifiquement sur les projets Agiles
Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.
C’est en Agile en grande partie la responsabilité du Product Owner.
Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !
En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.
En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.
Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?
J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.
Quelle est votre expérience de cette Loi de Little ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Le billet “What does an agile project manager do?” m’a interpelé et j’ai voulu comprendre si il existe réellement des différences majeures entre un(e) manager de projet Agile par rapport à tout(e) autre manager de projet.
Personnellement, je n’en vois aucune et je rejette la vue caricaturale du manager de projet « traditionnel » qui s’enfermerait dans un mode de management de type « commande et contrôle ».
Les responsabilités et compétences listées me semblent s’appliquer à toute et tout manager de projet, que le projet soit mené avec une approche prédictive, adaptative ou hybride. Connaître les principes et approches Agile est un prérequis pour tout(e) manager de projet dans le monde où nous œuvrons.
En matière de gestion de projet, l’émergence des méthodologies agiles a transformé la façon dont les entreprises conceptualisent, planifient et exécutent les projets.
Le manager de projet Agile est crucial pour le succès de toute entreprise Agile, un rôle central chargé de rassembler des éléments distincts pour atteindre les objectifs du projet. Le manager de projet a de nombreuses responsabilités, privilégiant l’adaptabilité, la collaboration et s’assurant que les projets répondent aux attentes. Un manager de projet agile est un poste complexe et polyvalent qui nécessite diverses compétences et attributs.
Ce rôle complexe n’est pas toujours facile à comprendre. Pourtant, le succès de l’entreprise repose souvent sur le fait que le manager de projet agile favorise la collaboration entre les services et donne aux équipes les moyens de comprendre, de communiquer et de renforcer le leadership. Ainsi, lorsque tout le monde comprend le rôle du manager, les projets ont plus de chances de réussir et les méthodologies agiles peuvent être déployées efficacement.
Qu’est-ce que le management de projet agile ?
Le management de projet agile est une approche dynamique et itérative du management de projet qui favorise la flexibilité, la collaboration et l’orientation client. Contrairement aux méthodologies traditionnelles, qui suivent souvent un chemin plus rigide et linéaire, l’approche Agile embrasse le changement et donne la priorité à la création de valeur incrémentielle aux parties prenantes pour une livraison précoce et continue.
En favorisant la planification adaptative et le travail d’équipe interfonctionnelle, les méthodes agiles permettent aux équipes de répondre rapidement à l’évolution des exigences et à la dynamique du marché.
Ces dernières années, la popularité des valeurs agiles a explosé, signalant un changement de paradigme dans le management de projet. Les organisations de tous les secteurs adoptent désormais les méthodes Agiles pour améliorer leur réactivité et augmenter la satisfaction de leurs clients.
Les rôles dans les équipes de projet agiles
Une équipe de projet Agile englobe une gamme de rôles essentiels qui conduisent collectivement les projets à leur terme. Différentes équipes peuvent avoir besoin d’une adaptation des rôles principaux.
Sponsor business, qui est responsable de l’ensemble du projet, du budget et des livrables dans le cadre commercial plus large ; Visionnaire, qui est responsable de la vision et de l’orientation globales.
Coordinateur technique, qui s’assure que la solution est techniquement correcte et répond aux exigences.
Manager d’équipe, responsable des petites zones et de parties détaillées du projet.
Analyste d’affaire, travaillant à identifier les opportunités et les changements dans l’entreprise dans son ensemble qui peuvent avoir une incidence sur le projet.
Développeur de solutions, prend les exigences de l’entreprise et les utilise pour informer la solution.
Solution Tester, responsable des tests de performance à chaque étape.
Les équipes agiles ont souvent des rôles divers et variés adaptés aux objectifs du projet, ce qui favorise l’idée d’adaptabilité. Pourtant, au milieu de ces variations, le rôle central du manager de projet agile reste le même, favorisant la coordination et promouvant les principes agiles.
Qu’est-ce qu’un manager de projet Agile ?
Un manager de projet Agile est un rôle à multiples facettes qui allie leadership de haut niveau et facilitation dans un environnement de projet Agile. Leur objectif principal est de façonner l’environnement de travail en évolution de la solution et de favoriser la collaboration au sein de l’équipe de développement de la solution. Le manager de projet guide les membres de l’équipe sans imposer de plans de projet détaillés au processus de développement. Au lieu de cela, ils utilisent une approche facilitatrice, pilotant le projet sans exercer un style strict de « commandement et de contrôle ».
Le rôle du manager de projet est essentiel pour assurer la réussite du projet, englobant des responsabilités allant de la communication efficace avec les parties prenantes à la supervision de la planification et de l’ordonnancement de haut niveau du projet. De plus, le manager de projet surveille les progrès, gère les risques et les problèmes, et encourage l’autonomisation et la motivation de l’équipe.
Tout au long du cycle de vie du projet, de la fondation au déploiement, le manager de projet reste essentiel au maintien d’une coordination et d’une communication efficaces.
Principales responsabilités d’un manager de projet agile
Les managers de projet agiles assument diverses responsabilités critiques, qui sont différentes des postes de manager de projet traditionnels. Ce rôle doit être flexible et central dans le flux de travail agile. Les responsabilités sont les suivantes :
Orchestrer l’évolution du projet jusqu’à son achèvement.
Promouvoir une communication et une collaboration transparentes au sein de l’équipe agile.
Favoriser un environnement où les membres de l’équipe peuvent s’auto-organiser et prendre des décisions.
Fournir du coaching et de la formation pour faciliter l’adoption d’Agile et l’amélioration continue.
Aligner les objectifs du projet sur les objectifs plus larges de l’organisation.
Faciliter une collaboration et une intégration interfonctionnelles efficaces.
Guider l’équipe de développement dans la création et le suivi d’un plan de livraison.
Suivi de l’avancement du projet et de l’échéancier du projet.
Identifier les obstacles et résoudre les problèmes rapidement.
Assurer le management des risques et la résolution des obstacles en temps opportun.
Cultiver une culture de l’adaptabilité, de l’innovation et de l’apprentissage.
Concilier les retours et les besoins des clients avec les contraintes techniques.
Encourager les boucles de rétroaction continues pour affiner les processus et les livrables.
Collaborer avec les parties prenantes pour recueillir et hiérarchiser les exigences.
Donner à l’équipe les moyens d’accepter le changement et de s’adapter à l’évolution des circonstances.
Promouvoir les pratiques agiles au sein de l’organisation.
Les responsabilités spécifiques du rôle de manager de projet agile varient en fonction des particularités de l’environnement Agile, de la nature du projet et des exigences de l’entreprise.
Quelle est la différence entre un manager de projet traditionnel et un manager de projet agile ?
La différence entre un manager de projet traditionnel et un manager de projet agile réside dans son approche du management de projet :
Manager de projets traditionnels
Met l’accent sur un style « commander et contrôler », en prescrivant des tâches et des processus. Se concentre sur la planification initiale détaillée, en visant un plan de projet complet dès le début. Principalement responsable de la répartition des tâches et de la supervision des contributions individuelles.
Manager de projets Agiles
Privilégie la collaboration et l’adaptabilité, en favorisant le travail d’équipe et la communication ouverte. Adopte une planification itérative et agile, permettant des ajustements flexibles tout au long du projet. Encourage le leadership partagé au sein d’équipes auto-organisées, en donnant aux membres les moyens de prendre collectivement des décisions et d’obtenir des résultats.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Les compétences essentielles nécessaires pour réussir en tant que manager de projet Agile
Devenir un manager de projet Agile compétent implique de perfectionner un mélange de compétences techniques, interpersonnelles et de leadership pour guider les projets avec succès dans le paysage dynamique Agile. Les managers de projet Agile ont la responsabilité globale de gérer les projets agiles du début à la fin, ce qui nécessite un éventail de compétences uniques et adaptables, notamment :
Solides compétences organisationnelles : Capacité à gérer des projets complexes, à allouer efficacement les ressources et à s’assurer que les tâches sont accomplies à temps.
Excellentes compétences en communication : Aptitude à articuler les idées, les besoins et les progrès à différents niveaux de l’organisation, en favorisant la transparence.
Gestion des risques : Aptitude à identifier les risques potentiels du projet, à évaluer leur impact et à élaborer des stratégies d’atténuation.
Résolution de conflits : Capacité à gérer les désaccords et les différences au sein de l’équipe, à favoriser un environnement productif et agile et à améliorer l’efficacité de l’équipe.
Leadership adaptatif : Capacité à ajuster le style de leadership en fonction des besoins de l’équipe, en encourageant l’autonomie et l’auto-organisation.
Expertise Agile : Une compréhension du manifeste Agile et des quatre valeurs clés pourrait être avantageuse. Une connaissance approfondie d’un cadre Agile, tel que l’approche de projet DSDM, ainsi que des outils Agile, est essentielle pour une mise en œuvre réussie.
Flexibilité : Capacité à naviguer dans les incertitudes et les changements inhérents au travail Agile tout en se concentrant sur les objectifs.
Collaboration : Volonté de travailler en étroite collaboration avec les équipes interfonctionnelles, les parties prenantes et les clients afin de créer de la valeur en collaboration.
Approche centrée sur le client : Concentrez-vous sur la compréhension et la satisfaction des besoins des clients, en favorisant la satisfaction des clients et la collaboration.
Prise de décision : Capacités supérieures de pensée critique et de prise de décisions éclairées et opportunes.
Certifications et formations en management de projet agile
Alors que les approches de management de projet Agile continuent de dominer le management de projet, APMG propose une gamme variée de certifications de premier plan parmi lesquelles les apprenants peuvent choisir. Nos qualifications et formations en gestion de projet agile permettent aux managers de projet de développer des compétences et d’apprendre des approches agiles.
Cours et certifications agiles APMG :
Gestion de projet Agile (AgilePM) : Apprenez à appliquer le cadre de référence pour la réalisation de projets Agile
Gestion de programme Agile (AgilePgM) : Découvrez comment créer des programmes agiles flexibles, capables de répondre à l’évolution des besoins de l’entreprise.
Analyse d’affaires agile (AgileBA) : Maîtriser le rôle d’un Business Analyst dans un environnement Agile.
DASA DevOps : Transformez l’informatique de votre organisation en mettant en œuvre le DASA DevOps Principes.
Avec une qualification APMG, les managers de projet deviennent adeptes des processus agiles et des méthodologies agiles populaires, ce qui leur confère un avantage concurrentiel distinct.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Conclusion
Alors que les organisations reconnaissent de plus en plus le besoin de flexibilité, de collaboration et de progrès itératif, les managers de projet sont apparus comme des facilitateurs de ce changement de paradigme. En adoptant l’état d’esprit Agile, les managers de projet ne se contentent pas de superviser les projets, mais guident activement les équipes vers l’adaptabilité et l’orientation client.
En fin de compte, en incarnant l’éthique Agile et en cultivant un environnement qui nourrit les valeurs Agile, les managers de projet ouvrent la voie à des projets réussis, innovants et axés sur le client dans le paysage moderne dynamique.
Depuis son lancement en 2010, AgilePM s’est rapidement imposé comme le premier cadre et certification au monde pour le management de projet Agile, avec plus de 200 000 examens dans le monde.
La qualification AgilePM est basée sur le manuel AgilePM, publié par l’Agile Business Consortium.
Guide sur Amazon
Le manuel offre une méthodologie pratique et reproductible qui permet d’atteindre un équilibre idéal entre les standards, la rigueur et la visibilité requises pour un bon management de projet avec le rythme rapide, le changement et l’autonomisation fournis par Agile.
Avec la formation et la certification en management de projet agile vous :
Appliquez la philosophie et les principes sous-jacents d’AgilePM dans une situation de projet.
Configurez de manière appropriée le cycle de vie d’un projet Agile en fonction d’un scénario donné.
Identifiez et appliquez les techniques Agiles populaires dans une situation de projet, y compris la hiérarchisation MoSCoW, le développement itératif et le timeboxing.
Comprenez et attribuez des rôles et des responsabilités au sein d’un projet Agile.
Comprenez les mécanismes de gouvernance et de contrôle d’un projet Agile.
Comprendre comment tester, estimer et mesurer l’avancement d’un projet Agile
Décrivez et appliquez l’approche Agile à la gestion des exigences.
Vidéo de présentation d’AgilePM
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.
DantotsuPM.com 