L’intention de ce Code de conduite éthique (Code) est de fournir des conseils aux personnes qui entreprennent des activités de coaching agile, afin de guider les types de comportements, de conseils et d’approches attendus d’elles.
Le coaching agile est une pratique évolutive englobant de nombreuses disciplines, y compris le coaching individuel, d’équipe et systémique, la facilitation, l’enseignement et le mentorat, toutes appliquées avec un parti pris ouvert et délibéré vers l’utilisation d’approches agiles pour aider à répondre aux besoins du client.
La complexité du coaching agile signifie que vous rencontrerez inévitablement des situations difficiles. Ce Code vous aidera à prendre ces décisions difficiles et vous pourrez le fournir en support de vos décisions avec vos clients.
Toute personne qui adhère au Code s’efforce d’agir de manière éthique, même si cela implique de prendre des décisions difficiles. Ils agissent courageusement, même s’il y a un impact négatif sur le plan personnel.
Les signataires de ce Code sont multiculturels, multigénérationnels et affiliés à de nombreux groupes différents. Nous croyons que la puissance de ce mouvement est amplifiée lorsque nous mettons de côté les différences et que nous nous aidons les uns les autres à nous élever dans la poursuite d’une meilleure voie. Nous nous engageons à nous soutenir mutuellement dans les décisions difficiles et les conversations courageuses.
En tant que personne qui pratique le coaching agile de manière éthique, je m’engage à ce qui suit.
#1 – Protéger la confidentialité, la propriété intellectuelle et la sécurité de l’information
Je protégerai les renseignements qui m’ont été communiqués et je ne les divulguerai que pour des raisons juridiques ou lorsque j’aurai un accord clair avec mon client et les parties prenantes.
J’attribuerai les idées des autres de manière appropriée et j’éviterai de donner l’impression qu’elles sont les miennes.
#2 – Agir selon mes capacités
Je ferai preuve d’ouverture et de transparence quant à mes compétences, mon expérience et mes qualifications.
Je serai clair avec mon client et les parties prenantes s’ils font une demande au-delà de mes capacités.
Je serai ouvert avec le client si je pense qu’il a besoin d’une autre forme d’aide professionnelle.
#3 – Pratiquer l’introspection et le développement professionnel continu
Je m’engagerai avec un groupe de pairs ou un mentor pour explorer les défis éthiques et autres dans mon travail de coaching agile.
Je chercherai à améliorer ma conscience de soi et mon efficacité par l’introspection et le développement professionnel.
#4 – Gérer les conflits d’intérêts
Je ferai preuve de transparence quant à tout conflit d’intérêts potentiel avec toutes les personnes qui pourraient être touchées.
J’éviterai consciemment les situations où je m’enrichis au détriment du client et des parties prenantes afin de conserver un jugement professionnel et une pensée objective.
Je résoudrai les conflits d’intérêts en travaillant avec le client et les parties prenantes, je demanderai de l’aide au besoin et je suspendrai ou mettrai fin à la relation si nécessaire.
#5 – Garantir la valeur de la relation
Je vérifierai auprès de mon client et des parties prenantes pour m’assurer que la relation est de valeur et qu’elle ne se prolonge que d’un commun accord.
Je ferai preuve de transparence si mon client est dépendant de mes services et je m’efforcerai de lui permettre d’atteindre sa propre agilité.
Je serai ouvert avec le client si je crois que la valeur de la relation diminue.
#6 – Défendre la responsabilité sociale, la diversité et l’inclusion
Je chercherai des occasions d’apporter des voix différentes à la conversation.
Je prendrai des mesures pour décourager et éliminer la discrimination sous toutes ses formes.
Je m’efforcerai de laisser l’entreprise meilleure que je ne l’ai trouvée, par mon action ou mon inaction.
#7 – Se mettre d’accord sur les limites
Je veillerai à ce que nous ayons une portée convenue, même si elle évolue.
Je travaillerai avec le client pour comprendre ses besoins et éviter d’imposer des solutions basées sur mes préférences et mes désirs personnels.
Je contesterai ouvertement lorsque mon client poursuit des objectifs en contradiction avec les valeurs et les principes du Manifeste Agile.
#8 – Gérer les différences de statut et de pouvoir
Je n’utiliserai pas mon autorité, mon pouvoir ou mon influence pour obtenir un gain personnel ou saper les objectifs de mon client.
Je créerai une prise de conscience lorsque le pouvoir, les privilèges et le rang entravent les objectifs de mon client ou ma capacité à le servir efficacement.
#9 – Faire preuve de responsabilité envers la profession
J’inviterai les autres personnes qui pratiquent le coaching agile à adopter les normes professionnelles et ce code de déontologie.
J’améliorerai et élèverai la réputation de la profession de coach agile.
J’encouragerai un dialogue et une réflexion sains lorsque je rencontrerai un comportement contraire à l’éthique chez les autres.
Remerciements
Des codes de déontologie existent déjà pour le coaching, la facilitation et d’autres disciplines incluses dans la pratique du coaching agile. En préparant ce code, nous nous sommes inspirés de ces codes existants et du travail de nombreuses personnes qui ont contribué aux conversations sur l’éthique dans le coaching agile au fil des ans. Ce code de déontologie est étayé par des explications supplémentaires dans les scénarios d’éthique connexes.
Dans le domaine des projets, la méthodologie de gestion de projet, la gestion des parties prenantes et la planification occupent une place cruciale, et elles ont un impact très significatif sur le résultat final du projet, qu’il soit couronné de succès ou qu’il échoue.
Toutefois, deux aspects essentiels sont souvent sous-estimés : la culture et la structure organisationnelle de l’entreprise où le projet sera mené.
Cet article examine comment la culture d’entreprise influe de manière significative sur le cours d’un projet.
Des structures bureaucratiques héritées des années 60s
Revenons en arrière, dans les années 60, lorsque les entreprises étaient ancrées dans l’ère du Fordisme, caractérisée par une forte emphase sur les structures bureaucratiques, la hiérarchie et la division du travail.
À cette époque, la gestion de projet n’était pas aussi avancée qu’aujourd’hui, ce qui est d’ailleurs corroboré par la fondation du Project Management Institute (PMI) à la fin de cette décennie, en 1969. Dans les entreprises largement bureaucratiques de cette période, l’accent était principalement mis soit sur la compétence technique des employés, soit sur la planification, en raison de la proximité temporelle de la Seconde Guerre mondiale.
Henry Gantt
Par exemple, à cette époque, le chef de projet était embauché principalement pour ses compétences dans la création de diagrammes de GANTT, de PERT, et pour sa capacité à donner des ordres. Son style de Management était principalement basé sur l’autorité directe, et il était souvent perçu comme un administrateur de ressources. Cette approche prévalait jusqu’aux années 1990, mais elle a progressivement diminué avec l’émergence de nouvelles cultures d’entreprise telles que l’Agile, le Lean, et les concepts d’Entreprise Libérée.
Comme vous avez pu le constater, lorsque l’on déploie un projet au sein d’une entreprise caractérisée par une culture directive, hiérarchique, et un fonctionnement en silos, le projet suivra également ce schéma, et le chef de projet sera recruté principalement pour ses compétences techniques, plutôt que ses compétences relationnelles qui ne sont pas prioritaires dans ce type d’entreprise. Il est donc fréquent que de nombreuses personnes pensent qu’un projet sera couronné de succès au sein de cette organisation.
Cependant, il est essentiel de se demander comment un projet peut réussir lorsque les différents services ne communiquent pas entre eux, qu’il n’y a pas de démarche d’amélioration continue en place, et que le leadership est moins valorisé que la maîtrise d’outils tels que MS Project ou JIRA.
Prenons un exemple concret : Avez-vous déjà eu l’occasion de travailler avec le cadre de travail Scrum au sein d’une entreprise traditionnelle ?
Vous seriez peut-être surpris de constater que le Scrum Master doit parfois surveiller de près les activités des Développeurs lors des Daily Scrum, ou encore que le sponsor considère le Scrum Master comme un chef de projet. En effet, étant donné que Scrum fournit un cadre Agile, son application au sein d’une entreprise caractérisée par une bureaucratie bien établie peut s’avérer complexe. Les philosophies et dogmes des entreprises traditionnelles et Agile sont fondamentalement différentes, et cela peut avoir un impact significatif sur la gestion des projets, comme c’est le cas avec Scrum.
Quels éléments de la culture d’entreprise ont une incidence sur le projet ?
La figure ci-dessous évoque les facteurs qui influencent un programme composé de projets.
Environnement du projet
Vous voyez, cela ne repose pas uniquement sur la méthodologie de gestion de projet, mais sur plusieurs facteurs qui relèvent de la culture de l’entreprise. Permettez-moi d’en lister quelques-uns.
1. L’organigramme du projet
Dans une entreprise traditionnelle, la structure est généralement pyramidale. Cependant, selon Mintzberg et d’autres experts en théorie des organisations, un projet doit adopter une structure en réseau dédié ou circulaire, plutôt que pyramidale.
Organigramme du projet
Supposons que vous travailliez au sein d’une grande entreprise bureaucratique ou traditionnelle et qu’on vous charge, en tant que chef de projet, d’implémenter un projet en utilisant une approche Agile. Selon une étude menée par la Scrum Alliance, il en ressort que 80 % à 90 % des équipes agiles, qui évoluent au sein d’une structure circulaire, éprouvent des tensions en raison de l’incohérence et de la difficulté à concilier les structures pyramidales et circulaires au sein d’une organisation bureaucratique.
D’ailleurs la figure ci-dessous, illustre la complexité d’allier deux organigrammes différents :
Réseau Agile – Source Frank Taillandier : Expliquer l’Agile
2. Le mode de management du chef de projet
Alors qu’autrefois, on valorisait le fait que le chef de projet soit un expert des outils et des méthodes, aujourd’hui, avec l’émergence d’entreprises axées sur le Lean, l’Agilité et l’innovation, on attend du chef de projet qu’il soit un véritable leader. Cette évolution a même conduit à inverser l’équation. Autrefois, le savoir-faire était essentiel, tandis qu’aujourd’hui au sein de ce type d’entreprises, c’est le savoir-être qui prend le dessus. Il est intéressant de noter que des organisations professionnelles telles que PMI® ou Prince2® accordent désormais une grande importance à cet aspect.
Voici l’évolution du chef de projet en fonction de la culture d’entreprise
Évolution du chef de projet en fonction de la culture d’entreprise
Ce diagramme que j’ai élaboré illustre que si vous travaillez dans une entreprise bureaucratique, on accorde de l’importance à vos compétences techniques. D’ailleurs, vous pouvez le constater lors de vos entretiens d’embauche.
livre sur Amazon
Néanmoins, si vous êtes chef de projet dans une entreprise qui se revendique « Lean« , alors on recherche un chef de projet pour piloter des projets où il y aura de la résistance aux changements, et où vous devrez maîtriser à la fois les outils et les méthodes Lean et de gestion de projet. Ayant commencé ma carrière en tant que Chef de projet Lean, je peux vous dire que ces entreprises sont très exigeantes et attendent que le chef de projet soit à la fois rigoureux et un leader.
Enfin, dans les entreprises Agiles, ce qui est demandé, c’est l’écoute active, l’empathie, et simplement aider les parties prenantes. Toutefois, le savoir-faire reste important, mais ce type d’entreprise cherche à recruter des chefs de projet Agile qui adhèrent d’abord à la vision et à la culture de l’entreprise avant même de considérer les compétences.
3. La maturité de l’entreprise
Travailler dans son coin sur un découpage des tâches et livrables.
Supposons qu’un chef de projet souhaite mettre en œuvre une méthodologie PMI ou PRINCE2 au sein d’une entreprise caractérisée par une bureaucratie bien établie. Cette démarche est particulièrement difficile, et il se voit souvent contraint de travailler
en isolation pour élaborer un diagramme de Gantt dans MS Project et générer des documents imprimés pour assurer le suivi du projet. Il peut également rencontrer des obstacles lors des comités de pilotage (COPIL), car certaines parties prenantes clés pourraient être absentes en raison du manque de maturité de l’entreprise dans ce domaine.
En fin de compte, cette approche peut convenir pour des projets simples, mais elle s’avère inadaptée pour des projets complexes. Cela vient du fait que l’entreprise accorde de l’importance aux opérations et moins ou pas aux projets.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
4. Le chef de Projet et ses Parties prenantes
Votre entreprise fonctionne-t-elle en « silos » ? (lisez ce billet)
Si vous évoluez au sein d’une entreprise où tous les services sont compartimentés, il ne devrait pas être surprenant que le chef de projet rencontre des défis similaires au sein de son équipe.
De nombreuses entreprises traditionnelles ont tenté de remédier à cela en recrutant de nouveaux chefs de projet ayant une expérience significative dans des projets Agile ou Lean.
Malheureusement, ce qui se produit souvent, c’est que le nouveau chef de projet tente initialement de créer un climat de confiance, de communiquer avec diverses parties prenantes et de négocier avec les responsables fonctionnels de ces parties prenantes. Hélas, après un certain temps, ce nouveau chef de projet finit par se conformer à la culture de l’entreprise et cesse d’innover, car cela n’est pas encouragé.
En revanche, dans une entreprise innovante où une culture d’amélioration continue est déjà en place, le chef de projet aura des relations plus harmonieuses avec ses parties prenantes. Dans un tel environnement, l’efficacité sera accrue, car chacun sera déjà conscient et engagé dans cette démarche.
Comment mettre en œuvre un projet de manière efficiente au sein d’une entreprise traditionnelle ?
Imaginons que vous venez d’être embauché dans ce type d’entreprise, et on vous a confié un projet d’envergure. Par où et par quoi commencer ?
Tout d’abord, ne soyez pas focalisé seulement sur le projet, mais analysez la culture de votre entreprise (rituels, leaders, etc.).
Par exemple, observez si les parties prenantes du projet ont l’habitude de communiquer entre elles ou non. Vérifiez si le comité de direction encourage les employés à prendre des initiatives.
De même, renseignez-vous sur l’utilisation d’une méthodologie de gestion de projet au sein de l’entreprise, qu’il s’agisse du PMI, de Prince 2 ou même de Scrum (bien que ce dernier ne soit pas strictement une méthodologie de gestion de projet).
Ensuite, prenez le temps de discuter de vos préoccupations avec votre sponsor et soumettez des propositions.
Salle Obeya
Par exemple, si les employés de l’entreprise ne communiquent pas entre eux, envisagez de créer une salle Obeyaavec la participation des parties prenantes et établissez un rituel où chacun s’engage à se réunir à une heure précise dans un lieu déterminé.
Ensuite, en plus de votre rôle de chef de projet, adoptez également celui de formateur. Vous devrez vous impliquer dans la conduite du changement, dispenser des formations en gestion de projet, et envisager la mise en place de séminaires ou de team building afin de renforcer la confiance et de favoriser les liens informels.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Pour terminer, assurez-vous de toujours communiquer de manière transparente. Lorsque vous remontez des informations lors des comités avec le sponsor et la direction, assurez-vous de faire un retour transparent à vos parties prenantes. Appliquez le bon sens en toutes circonstances, et vous gagnerez la confiance de vos parties prenantes.
Cas extrême : Envisageons un scénario où toutes les parties prenantes s’opposent aux changements.
Dans de telles circonstances, vous pourriez envisager de faire appel à au moins deux ou trois consultants spécialisés en gestion de projet, afin de ne pas vous retrouver seul(e) et élever le niveau de compétence en gestion de projet. Cela peut contribuer à instaurer un climat de confiance. Bien que cette approche ne fonctionne pas toujours, elle a fait ses preuves en tant que stratégie efficace.
En fin de compte, la méthodologie de gestion de projet, la gestion des parties prenantes et la planification… sont toutes influencées par la culture de l’entreprise.
Si, par le passé, il était courant d’attendre d’un chef de projet qu’il soit un expert sans nécessairement être un leader, c’était dans un contexte qui prévalait à cette époque.
Cependant, aujourd’hui, nous sommes en pleine transition, avec un monde en constante évolution, et il est de plus en plus important que, en plus de votre rôle de chef de projet, vous incarniez également le rôle de leader et d’accompagnateur du changement.
Vous devrez acquérir certaines compétences pour aider les organisations à passer d’une culture d’entreprise traditionnelle à une culture innovante.
N’oublions pas que l’objectif ultime du projet est d’apporter de la valeur ajoutée à l’entreprise, et toute transformation passe par la mise en œuvre de programmes et de projets.
Yanis IOUALITENE est chef de projet Lean.
Yanis Ioualitene
Il est diplômé de Skema Business School en management de Projets & Programmes.
Il est certifié PMP ®, Prince2, ITIL 4, PSM I, Agile PM DSDM et Green Belt Lean.
Yanis a contribué au groupe de travail sur le PMBoK 7 organisé par le PMI Francophone.
« A la différence, de l’adhocratie, où votre pouvoir est limité. Vous serez tel le Scrum Master qui est présent pour guider son équipe (mais sans la diriger), tout en sachant canaliser et centraliser les relations informelles. »
partagez ce billet avec vos amis, collègues et relations professionnelles
Le but de ce rapport anonyme sur les salaires des Scrum Master est de créer un benchmark clair, basé sur des données réelles, qui permet à tous les membres de la communauté Agile de comprendre si leur rémunération est bien positionnée. Le rapport couvre les Scrum Masters et les Coachs Agile, employés comme indépendants.
L’objectif est d’avoir au moins 1 000 réponses d’ici la fin novembre 2023 pour créer le rapport à temps pour janvier 2024. Bien entendu, le rapport sera disponible gratuitement.
J’ai trouvé ce billet très vrai par rapport à mon vécu personnel sur des projets Agiles qui se sont tellement concentrés sur produire un « Minimum » MVP que leurs premiers livrables n’étaient que très rarement utilisables / « Viables » en situation réelle.
Vos clients détestent les MVPs. Faites plutôt un SLC.
[…]
Les équipes produit ont répété le mantra du MVP (Minimum Viable Product) depuis toute une décennie sans réévaluer si c’est réellement la bonne façon de maximiser l’apprentissage tout en satisfaisant le client.
Eh bien, ce n’est pas le meilleur système !
Cette approche MVP est égoïste et fait mal aux clients.
[…]
La motivation qui dirige le MVP est toujours valable :
Construisez quelque chose de petit, parce que les petites choses sont rapides et peu coûteuses à tester.
Mettez-la rapidement sur le marché, car le véritable apprentissage ne se produit que lorsque de vrais clients utilisent un vrai produit.
Jetez-la ou changez complètement de direction s’il s’agit d’un échec, ou investissez davantage s’il s’agit d’un semis avec du potentiel.
Les MVPs sont parfaits pour les startups et les équipes produit car ils maximisent le plus rapidement possible ce que l’on appelle « l’apprentissage validé ». Et, bien que les entretiens avec les clients soient utiles, vous apprenez de nouvelles choses lorsqu’un client utilise réellement le produit. Mais les MVPs sont un acte égoïste.
Le problème est que les clients détestent les MVPs.
Les startups sont encouragées par le célèbre Reid Hoffman à « lancer le produit assez tôt pour que vous soyez embarrassé par votre version V1.0. ». Mais aucun client ne veut utiliser un produit inachevé qui embarrasse ses créateurs. Les clients veulent des produits géniaux qu’ils peuvent utiliser immédiatement.
Les MVPs sont trop M et rarement V.
Les clients le voient et détestent cela. C’est peut-être génial pour l’équipe produit, mais c’est mauvais pour les clients. Et en fin de compte, ce qui est mauvais pour les clients est mauvais pour l’entreprise.
[…]
Soyez « Slick » (habile et astucieux) !
À partir de ce raisonnement, il y a des années, j’ai nommé ce que je pense être la bonne alternative au MVP : Simple, Lovable/Aimable et Complet (SLC). Nous le prononçons « Slick ». Comme dans : « Quelle est la version (habile et astucieuse) ‘Slick’ de votre idée ? ».
Un autre avantage de SLC devient évident lorsque vous considérez la prochaine version du produit.
Un produit SLC ne nécessite pas de développement continu pour ajouter de la valeur. Il est possible que la V1 évolue pendant des années en une V4, mais vous avez également la possibilité de ne pas investir davantage dans le produit, tout en ajoutant de la valeur. Un MVP qui ne recevra jamais d’investissement supplémentaire n’est qu’un mauvais produit. Un SLC qui n’obtient jamais d’investissement supplémentaire est un bon produit, même s’il est modeste.
Henrik Kniberg, un coach agile et produit de longue date pour Spotify, a créé l’illustration populaire ci-dessus pour donner un exemple à suivre aux équipes produit lorsqu’elles envisagent de livrer un produit minimum viable, ou MVP, à leurs clients.
Une planche à roulettes est un produit SLC. C’est plus rapide que la marche, c’est simple, beaucoup de gens l’adorent, et c’est un produit complet qui n’a pas besoin d’ajouts pour être amusant ou pratique. En même temps, vous pouvez faire évoluer le skateboard en ajoutant une potence et un guidon, pour créer une trottinette (seulement un peu moins simple, et certainement appréciable et complet). Ensuite, vous pouvez faire grandir les roues, ajouter un siège et des pédales, et vous avez un vélo. Encore une fois, moins simple, mais vous avez maintenant un produit avec des avantages massifs de vitesse, de distance et d’efficacité énergétique…
[…]
Avec SLC, les résultats sont meilleurs et vos options pour les prochaines étapes sont meilleures.
Si le SLC échoue, ce n’est pas grave : C’est une expérience ratée. Les SLCs et les MVPs atteindront parfois ce résultat parce que le but est d’ expérimenter. Mais si un SLC réussit, vous avez déjà apporté une valeur réelle aux clients et vous avez plusieurs futurs possibles à votre disposition, dont aucun n’est urgent. Vous pourriez construire une V2, et parce que vous générez déjà de la valeur, vous avez plus de temps pour décider à quoi elle devrait ressembler. Vous pouvez même interroger les clients existants pour déterminer exactement ce que la V2 devrait impliquer, au lieu d’un groupe d’alpha-testeurs qui veulent juste savoir « Quand allez-vous réparer cette chose qui ne fonctionne pas ? »
Ou, vous pouvez décider de ne plus travailler dessus. Tous les produits ne doivent pas nécessairement devenir complexes. Tous les produits n’ont pas besoin de nouvelles versions majeures tous les deux trimestres.
Certaines choses peuvent juste rester Simples, aimables/Lovable et Complètes.
Demandez à vos clients. Ils seront d’accord.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Certains propriétaires de produits (Product Owners) pensent qu’un arriéré de produit (Product Backlog) complet est le meilleur moyen d’atteindre l’objectif du produit et d’être en même temps totalement transparent .
The Expensive Folly of the Oversized Product Backlog par Stefan Wolpers
Apprenez-en davantage sur l’impact négatif d’un Product Backlog surdimensionné sur l’innovation, la capacité de votre équipe Scrum à créer de la valeur et vos relations avec les parties prenantes.
Les effets secondaires coûteux d’un arriéré de produit surdimensionné
Certains Product Owners estiment en effet que tenir un Product Backlog surdimensionné est une stratégie optimale pour atteindre l’objectif du produit et maintenir une transparence totale, garantissant qu’aucune idée de valeur potentielle ne soit perdue. Cependant, construire à l’avance une liste complète de tous les éléments de travail imaginables n’est pas seulement une perte de temps pour une équipe Scrum, un Product Backlog surdimensionné est une erreur coûteuse à long terme.
Voici 8 effets secondaires critiques de cet anti-pattern (contre-modèle ou fausse bonne idée) du Product Backlog.
#1 – Encourage le gaspillage
Un Product Backlog surdimensionné favorise le gaspillage en investissant du temps dans des éléments qui ne seront peut-être jamais développés en raison de la découverte continue de tâches plus précieuses. C’est une violation claire des principes du Manifeste Agile. En particulier, la simplicité – l’art de maximiser le travail non fait – qui est essentielle.
#2 – Augmente les risques du piège des coûts irrécupérables
Les « sunk costs » sont des dépenses non récupérables quoi que l’on fasse ou décide maintenant. Relisez ce billet.
Un important Product Backlog peut favoriser le syndrome des coûts irrécupérables. Les équipes peuvent continuer à affiner et à prioriser des éléments parce qu’elles y ont déjà investi du temps plutôt que parce qu’ils ajoutent une valeur significative. Ce comportement contredit le principe d’amélioration continue et d’adaptation du Manifeste Agile.
#3 – Conduit à la paralysie d’analyse
Un énorme Product Backlog peut provoquer ce que l’on appelle la paralysie d’analyse, où le volume d’items devient écrasant, conduisant à l’indécision et aux retards. L’équipe peut passer trop de temps à évaluer, hiérarchiser et redéfinir les priorités, ce qui nuit à sa capacité à se concentrer sur le développement réel du produit. Cet excès de choix ralentit souvent les processus de prise de décision, ce qui rend difficile pour l’équipe de déterminer par où commencer ou sur quoi se concentrer ensuite. En fin de compte, cela ralentit l’ensemble du projet, détournant l’énergie de la création de valeur pour le client vers la gestion du Product Backlog lui-même.
#4 – Nuit à l’engagement des parties prenantes
Un Product Backlog gonflé présente un défi important en matière de communication efficace. Le grand nombre d’items peut rendre difficile pour les intervenants de comprendre le plan, les progrès et les priorités, ce qui peut entraîner un décalage dans les attentes. Les intervenants peuvent avoir du mal à trouver leurs intérêts spécifiques dans la longue liste, ce qui les rend confus et peut causer un sentiment de détachement.
#5 – Produit un effet d’éviction
Un Product Backlog complet et surdimensionné peut décourager sans le vouloir les parties prenantes et les membres de l’équipe de faire part de leurs réflexions et de leurs idées. L’exhaustivité perçue du Product Backlog pourrait donner l’impression qu’il n’y a pas de place ni de besoins supplémentaires à ajouter, ce qui pourrait faire perdre des idées précieuses.
#6 – Inhibe l’innovation
Un énorme Product Backlog peut involontairement étouffer l’énergie créative au sein de l’équipe Scrum. La longue liste de tâches peut créer une culture de « cocher les cases » où l’équipe se concentre davantage sur compléter des tâches plutôt que sur explorer et innover. L’équipe peut se sentir contrainte, percevant qu’il n’y a pas de place pour de nouvelles idées, ce qui peut limiter leurs compétences créatives en résolution de problèmes et les dissuader de trouver des solutions innovantes. Cet état d’esprit contredit la valeur Scrum de « l’ouverture » et le principe Agile d’exploiter le changement pour le bénéfice business du client.
#7 – Donne un faux sentiment de sécurité
Guide téléchargeable gratuitement
Un Product Backlog exhaustif peut donner un faux sentiment de sécurité, une illusion de contrôle. Il peut sembler que l’équipe Scrum a identifié tout le travail nécessaire, réduisant ainsi le besoin perçu de découverte et d’apprentissage. Ce décalage avec le Guide Scrum, qui préconise l’apprentissage itératif et la découverte, peut être nuisible.
#8 – Encourage l’optimisation précoce
Un Product Backlog enflé peut conduire à une optimisation prématurée. L’équipe peut se sentir forcée de concevoir des systèmes ou des flux de travail qui anticipent l’achèvement des futurs éléments du backlog, ce qui entraîne une complexité inutile, contribuant au gaspillage si ces tâches changent ou sont dépriorisées par la suite. Cette approche entre en conflit avec le principe agile de simplicité (l’art de maximiser la quantité de travail non effectué) et la valeur Scrum de focus, car elle encourage l’effort dirigé vers des besoins futurs incertains plutôt que vers les besoins présents les plus précieux.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Comment contrer au mieux les effets d’un Product Backlog surdimensionné
Heureusement, il existe de nombreuses façons d’éviter de créer un Product Backlog surdimensionné dès le départ. Mieux encore, c’est à l’équipe Scrum de les utiliser à bon escient. Voici 8 tactiques pour commencer :
#1 – Adoptez la simplicité
Tenez-vous-en au principe de simplicité du Manifeste Agile, qui implique de maximiser le travail non effectué. Concentrez-vous sur les articles les plus précieux pour offrir la plus grande valeur client et business.
#2 – Limitez les travaux en cours (Work in Progress : WiP)
Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.
#3 – Affinez régulièrement le Product Backlog
Gardez le Product Backlog gérable en organisant régulièrement des sessions d’affinement pour vous assurer que les éléments sont toujours pertinents, précieux et correctement hiérarchisés.
#4 – Affinez juste-à-temps
Évitez de trop affiner les éléments qui ne sont pas imminents pour le développement. Plus un élément est éloigné de la sélection pour un Sprint, moins il devrait être détaillé. L’équipe Scrum ajoute des détails lors des séances de raffinement juste à temps.
#5 – Hiérarchisez et dépriorisez
Acceptez le fait que tous les éléments du Product Backlog ne seront pas implémentés. Établissez régulièrement des priorités et, si nécessaire, supprimez les priorités ou supprimez les éléments du Product Backlog qui ne correspondent plus à l’objectif du produit.
#6 – Responsabilisez les équipes
Encouragez l’auto-organisation au sein de l’équipe Scrum. Donnez-leur les moyens de proposer et de négocier des éléments dans le Product Backlog, renforçant ainsi leur sentiment d’appartenance et d’engagement. Les meilleurs développeurs challengent toujours leurs Product Owners !
#7 – Faites la promotion un dialogue ouvert
Favorisez une culture de dialogue ouvert et de collaboration entre l’équipe Scrum, les parties prenantes et le Product Owner. Encouragez tout le monde à apporter des idées et à remettre en question celles qui existent déjà, en évitant l’effet d’éviction.
#8 – Favorisez l’apprentissage continu et l’adaptation
Adhérez au processus empirique de « transparence, inspection et adaptation » de Scrum. Apprenez de chaque Sprint, adaptez le Product Backlog en fonction des informations, par exemple, de la revue de Sprint (Sprint Review), et soyez ouvert aux changements.
Pour terminer
Le Product Backlog est un outil essentiel dans le développement de produits avec Scrum. Son efficacité est liée à la simplicité, à la limitation du travail en cours, au raffinement régulier, aux détails juste-à-temps, à la priorisation, à l’autonomisation des équipes, au dialogue ouvert et à l’apprentissage continu.
Tous ces principes fonctionnent ensemble pour garder le Product Backlog concentré, exploitable et aligné sur l’objectif du produit, améliorant ainsi la transparence et favorisant une culture de collaboration et d’amélioration continue.
Comment empêchez-vous un nouveau Product Backlog de devenir surdimensionné ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans sa série de nouvelles en prévision de la rentrée, Mike Cohn de Mountain Goat Software a abordé un problème fréquent : « Comment présenter des user stories à votre équipe ? »
Astuce #1: Commencez par quelques définitions.
Une user story (ou histoire utilisateur) décrit quelque chose qu’un utilisateur veut. L’histoire suit généralement ce modèle: « En tant que [type d’utilisateur], je [veux, j’ai besoin ou je suis obligé de faire cette chose] afin que [je puisse atteindre cet objectif]. »
Une epic (ou épopée) est une grande user story. Voilà. Rien de plus, rien de moins.
Un thème est une collection d’histoires utilisateurs connectées entre elles. Certaines personnes ont introduit le terme de feature (fonctionnalité) pour désigner une histoire utilisateur suffisamment grande pour être livrée ou peut-être assez grande pour que les utilisateurs la remarquent et soient plus heureux.
Toutes ces définitions ne sont utiles que si elles simplifient la discussion sur le produit que vous développez. Pour en savoir plus sur comment et pourquoi utiliser ces termes (et pourquoi les outils ont ajouté à la confusion), consultez Epics, Features et User Stories.
Astuce #2: Ajoutez le bon niveau de détails au bon moment.
Comme Boucle d’or et les trois ours, nous ne voulons pas d’articles dans l’arriéré de produits avec trop peu ou trop de détails. Nous voulons juste le bon niveau de détails.
Si un Product Owner écrit une user story qui inclut trop peu de détails, les développeurs n’en sauront pas assez lors de la planification du sprint pour comprendre ce qu’il faut construire. Lorsque des détails excessifs sont inclus, le temps et l’argent dépensés à ajouter ces détails inutiles sont gaspillés.
Il est peu probable que le product backlog (l’arriéré de produit) d’une équipe soit parfaitement détaillé dès le départ. Cela signifie que l’équipe devra probablement itérer pour aller vers la bonne quantité de détails.
Je trouve qu’il est beaucoup plus facile pour les membres de l’équipe de trouver le bon équilibre lorsqu’ils commencent avec trop peu de détails. Commencez donc par remplir le modèle d’histoire utilisateur avec le strict minimum de fonctionnalités et de détails du produit, et partez de là.
Astuce #3: Apprenez la méthode SPIDR pour découper les histoires
L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper les histoires utilisateurs. Je parie que vous avez eu du mal avec cela, parce que je l’ai certainement connu au début. C’est pourquoi j’ai trouvé un acronyme facile à retenir pour détailler les cinq facteurs différents qui pourraient vous aider à diviser une histoire.
J’espère que ces conseils vous aideront, vous et votre équipe, à réussir avec agile,
* Spike : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Les mégaprojets fournissent souvent des leçons applicables aux projets de toutes tailles. Le livre du professeur Bent Flyvbjerg et Dan Gardner « How Big Things Get Done » propose 15 heuristiques ou principes qui s’appliquent à tous les projets.
À lire les nombreux articles qui fleurissent un peu partout, la gestion de projet hybride semble parée de toutes les vertus. Si cela n’est pas dénué de certains fondements, cette approche possède également quelques inconvénients que l’on oublie trop souvent de présenter.
La team PMI Disciplined Agile de Poche, composée des bénévoles Claudine Blanquier, Laurent Thomas, Frédéric Martin et Selim Khaldi, facilite la découverte de Disciplined Agile avec des mémentos de poche résumant les fondamentaux de Disciplined Agile, et en FRANÇAIS !
Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.
Dans Scrum, un incrément de produit est ce que vous avez précédemment construit, plus tout ce que vous venez de terminer dans le dernier sprint, le tout intégré, testé et prêt à être livré ou déployé.
Pour réussir avec Agile, assurez-vous d’utiliser des critères bien réfléchis pour qualifier vos projets comme de bons candidats pour une approche Agile.
Comment avoir une approche de management de projet en laquelle on a déjà confiance et y ajouter le nouveau ‘ test de pertinence ’ pour s’assurer que l’approche adoptée est la bonne pour le projet en question ?
Il y a un certain nombre de défis dans les projets de développement qui suivent le chemin de méthodologies de développement plus rigides comme la méthode dite « en cascade ».
Aujourd’hui, comme la communauté IT a bien adopté et s’est adaptée aux pratiques Agile, en faites-vous assez pour instruire et informer votre écosystème et surtout vos clients ?
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Comme toute autre initiative visant à apporter des améliorations, le succès de la transformation Agile est déterminé par le fait de savoir pourquoi et où vous voulez vous améliorer.
J’ai eu l’opportunité de participer à notre événement Czech PMI Chapter et de répondre aux questions du public sur la façon d’aborder la transformation Agile, quels sont les bénéfices attendus et comment les atteindre. J’aimerais poursuivre le partage et approfondir un peu certains des sujets qui ont été ouverts lors de l’événement.
L’attente générale d’une transformation Agile est de renforcer votre capacité à vous adapter et à réagir rapidement à l’échelle de l’entreprise. Si une entreprise veut devenir plus efficace, il y a plusieurs sujets connexes qui doivent être abordés simultanément et ils vont bien au-delà de la façon de travailler des équipes agiles individuelles (culture d’entreprise, développement stratégique des compétences, systèmes de management de la performance, alignement efficace de plusieurs équipes accédant aux mêmes plates-formes technologiques et bien d’autres).
Et pour toute initiative visant à apporter des améliorations, le succès de la transformation est déterminé par le fait de savoir pourquoi et où nous voulons nous améliorer. Nous devons être clairs sur les bénéfices que nous aimerions obtenir, puis définir l’objectif principal des efforts de transformation pour commencer le voyage.
Dans cet article, j’aimerais partager mon expérience pratique avec trois domaines qui sont répertoriés par le 13th Annual State of Agile Report comme les avantages les plus fréquemment obtenus.
La capacité à manager les priorités changeantes (signalée par 69% des participants à la recherche)
La visibilité du projet (65%)
L’alignement des activités et des systèmes d’information (64%)
#1 – Votre capacité à manager des priorités changeantes
Voyons d’abord pourquoi nous voudrions améliorer le management des priorités changeantes. Quel est l’impact si nous ne réagissons pas et n’adaptons pas l’allocation actuelle ou prévue des ressources ?
Pour le dire simplement, sans la capacité de manager les priorités changeantes, nous continuons ce que nous faisions, quelles que soient les circonstances qui nous disent d’abandonner nos initiatives actuelles et de commencer à faire autre chose.
Pour changer cela, nous devons surmonter les 3 aspects suivants au niveau de l’entreprise (inutile de dire que chacun d’eux est assez difficile en lui-même) :
Parvenir à un accord entre les départements sur quelle est la chose la plus importante à faire en ce moment.
Réallouer des ressources au cas où nous aurions besoin de nous concentrer en priorité sur un domaine sous-financé, ce qui peut signifier rediriger temporairement les ressources de certaines équipes vers d’autres.
Changer l’état d’esprit des personnes responsables de la définition et de la mise en œuvre des initiatives, passant d’une approche où «seule la solution complète a du sens » à une feuille de route basée sur la valeur avec des initiatives plus petites apportant de la valeur par elles-mêmes.
Pour aborder les deux premiers points, il est indispensable d’inculquer une attitude « une équipe » ( one team ) à votre équipe de direction. Ils sont censés, eux aussi, être une équipe.
Je vois souvent un investissement d’énergie et de ressources dans le team-building au niveau des équipes inter-fonctionnelles agiles, mais le domaine du team-building au niveau de l‘équipe de management ne reçoit pas l’attention requise (ou nous nous attendons simplement à ce que ces cadres supérieurs rattrapent d’eux-mêmes leur retard).
Pourtant, tout désaccord continu ou attitude défensive au niveau de la direction peut avoir un impact direct sur la coopération aux niveaux inter-équipes et entraver toute volonté de sortir des sentiers battus lorsque les ressources doivent être réorientées. L’alignement des priorités et l’allocation des ressources sont souvent facilités par un processus trimestriel de revue des activités étroitement lié aux objectifs et aux résultats clés (Objectives and Key Results – OKR) des départements de l’entreprise.
Apporter la plus grande valeur possible, aussi rapidement que possible.
Pour réussir dans le troisième domaine listé ci-dessus, il est nécessaire d’adopter pleinement le mode de développement itératif en mettant l’accent sur la valeur client. Je trouve toujours utile de démontrer avec des exemples comment la valeur est construite par des étapes progressives où la technologie est le catalyseur, pas l’objectif.
Afin de parvenir à un changement de mentalité, permettez suffisamment de discussions jusqu’à ce que le sujet soit clarifié et soutenez vos équipes par le coaching.
#2 – La visibilité du projet
Adoptez une plus grande transparence comme base de relations et de travail.
La visibilité du projet signifie la transparence dans ce que nous faisons, où nous investissons nos ressources et pourquoi cette initiative particulière a été lancée. Une telle visibilité devrait également inclure une rétroaction ouverte sur le succès de la production, ce qui permettra d’améliorer la qualité de nos estimations, la capacité à maintenir le travail en cours dans des limites raisonnables et de rester concentré sur la création de valeur pour le client.
Pour atteindre une telle transparence, il faut généralement choisir le bon outil de communication et disposer d’une équipe qui aide à collecter et à communiquer ces informations entre les équipes. Mais la question la plus importante est la suivante :
Comment la visibilité des projets contribue-t-elle à l’agilité à l’échelle de l’entreprise ?
Comme l’une de mes collègues l’a récemment déclaré, la visibilité du projet apporte une grande compréhension de ce qui est fait, mais elle peut aussi montrer les points faibles. Personnellement, je ne pourrais pas être plus heureuse d’entendre ce commentaire prononcé à haute voix. La prise de conscience des points faibles et leur acceptation est la première étape vers l’amélioration.
Pour profiter pleinement de la visibilité des projets, nous devons fournir à nos équipes un environnement sûr qui favorise l’apprentissage rapide et une approche valorisant l’échec rapide. En d’autres termes, nous devons accroître la confiance dans le partage des opinions, établir la confiance entre les équipes elles-mêmes et guider la direction de l’entreprise vers l’adoption d’une approche de leadership au service des autres.
Relisez ce billet sur le Servant Leadership
#3 – L’alignement des activités et des systèmes d’information
L’alignement des activités et du SI est au cœur de la mise en place d’équipes inter-fonctionnelles avec des experts métier et informatiques (idéalement colocalisés) ; cet alignement doit être organisé autour des livrables et des parcours clients plutôt qu’autour des systèmes informatiques ou des composants d’infrastructure.
Mais il existe un piège : Le changement organisationnel seul ne suffit pas à atteindre l’alignement.
Commencer une transformation par une grande réorganisation et l’internalisation de rôles nouvellement définis peut créer de la frustration chez les gens. Ils peuvent ne pas se considérer comme étant prêts à assumer leurs nouveaux emplois transformés ni à rejoindre de nouvelles équipes avec une méthode de travail agile.
Mais pour l’instant, je préfère me concentrer sur quelque chose qui peut apporter des bénéfices significatifs même si vos équipes restent séparées entre métiers et informatique : Pour tracer le chemin vers l’alignement entre les experts métier et informatiques, concentrons-nous d’abord sur le langage qu’ils parlent ensemble.
Le langage dans lequel les attentes de l’entreprise sont formulées est le premier indicateur de l’existence ou non d’un objectif commun. Combien de fois avons-nous entendu : « Les utilisateurs ne peuvent pas exprimer clairement leurs exigences et ils les modifient constamment » ou « Encore une fois, les nouvelles fonctionnalités informatiques ne m’ont pas donné ce dont j’avais besoin ».
Dans de telles situations, les user stories sont d’une grande aide. Une user story partage qui, quoi et pourquoi elle est nécessaire. Les user stories ne contiennent pas de description de la solution, mais clarifient plutôt la valeur client attendue que nous voulons obtenir en livrant l’histoire.
Penser et parler de cette façon plutôt qu’attendre des spécifications fonctionnelles de la part de l’utilisateur professionnel fait une grande différence. En maîtrisant la communication dans les user stories, les équipes parviennent à établir un objectif commun : La création de valeur business. L’expertise de l’équipe informatique reste dans la conception de la solution, tandis que la responsabilité de l’équipe business est de déterminer ce qui apporte de la valeur aux clients. Les user stories agissent comme l’élément de connexion qui a autant de sens pour les deux équipes impliquées, tout en leur permettant de s’épanouir dans ce qu’elles font le mieux.
La refonte organisationnelle est une seconde étape.
Pour résumer, sur la base de mon expérience avec différentes approches pour connecter les unités commerciales et informatiques, je préfère concevoir une culture d’alignement en établissant un langage commun et en aidant les gens à se préparer au changement comme une première étape. La refonte organisationnelle devrait ensuite être utilisée pour soutenir la culture et rendre la coopération encore plus facile, mais je vois cela comme un catalyseur plutôt que l’objectif de transformation lui-même.
PMI is a registered mark of Project Management Institute, Inc.
Lenka est cadre exécutive avec une expérience internationale et une expérience reconnue dans l’établissement d’une vision stratégique et son exécution. Elle excelle dans la conduite de transformations numériques et l’amélioration de l’agilité organisationnelle. Lenka a acquis une expérience multisectorielle en dirigeant des initiatives stratégiques dans les domaines de la banque, de l’industrie manufacturière, de la distribution et de l’automobile. Elle travaille actuellement comme chef de cabinet du président du Project Management Institute®, une organisation à but non lucratif mondiale qui offre un soutien à l’éducation et à l’évolution de carrière aux professionnels qui conduisent les changements et la transformation.
Elle est titulaire du Digital Excellence Diploma de l’IMD Business School of Switzerland, graduated C-level School de European Women in Boards, d’un Master of Science en informatique et de plusieurs certifications en management de projet, pratiques agiles et analyses business.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les mégaprojets fournissent souvent des leçons applicables aux projets de toutes tailles. Le livre du professeur Bent Flyvbjerg et Dan Gardner « How Big Things Get Done » propose 15 heuristiques ou principes qui s’appliquent à tous les projets.
Applying the heuristics of “How Big Things Get Done” to adaptive delivery par Kiron Bondale
Je n’ai jamais eu l’occasion de diriger un mégaprojet (le terme est généralement utilisé pour les projets qui ont un budget supérieur à 1 milliard de dollars), mais au cours des quinze dernières années, j’ai lu un certain nombre d’articles publiés par le professeur Flyvbjerg sur le sujet et j’ai toujours appris des leçons applicables aux projets auxquels j’ai participé.
Dans le livre, les auteurs fournissent de nombreuses études de cas soutenant onze heuristiques dérivées des décennies de recherche du professeur Flyvbjerg sur de grands projets complexes. Bien que le terme « heuristique » soit approprié car chacun est un raccourci mental utile, ils pourraient également être utilisés comme principes.
Relisez ce billet de Grace Najjar sur les mégaprojets au Moyen-Orient.
Étant donné que 22 des 23 catégories de projets évalués sont des projets physiques (p. ex. construction, exploitation minière, aérospatial), il est tentant de supposer que ces heuristiques ne sont pertinentes que pour les projets réalisés avec une approche prédictive.
Ce serait une hypothèse erronée car sur les onze heuristiques, j’ai constaté que la plupart de ces principes sont également applicables à l’approche adaptative. En voici quelques-uns.
Embauchez un ou une maître d’œuvre
Vous voulez avoir quelqu’un avec une expérience significative du domaine et une expérience prouvée de succès à mener ce travail.
De même, que vous cherchiez à remplir le rôle de chef de projet, de responsable agile (par exemple, Scrum Master) ou de propriétaire de produit, une expérience et des connaissances pertinentes sont essentielles.
Donnez raison à votre équipe
La première déclaration de valeur du Manifeste pour le développement logiciel Agile est « Les individus et les interactions plutôt que les processus et les outils ».
Et comme le dit le professeur Flyvbjerg, le travail principal du maître d’œuvre est de choisir les bons membres dans l’équipe pour faire le travail.
Demandez « Pourquoi ? »
Bien que l’on s’attende à ce que la portée d’un projet émerge au cours de sa vie lors de l’utilisation d’une approche adaptative, ce peut être une erreur fatale que de ne pas passer suffisamment de temps à identifier une vision finale attendue.
Relisez ce billet sur l’art de savoir communiquer une vision claire.
Cette étoile polaire permet à l’équipe de questionner les éléments de travail qui ne permettront pas d’atteindre les résultats souhaités et ce questionnement réduira la probabilité qu’une approche de livraison adaptative ne devienne une marche aléatoire vers nulle part.
Construisez avec des Legos
L’idée de créer de grands systèmes à partir de composants plus petits s’inscrit naturellement dans la nature incrémentale de l’approche adaptative.
Lorsqu’une équipe prend un gros élément de travail et trouve un moyen de le découper en morceaux plus petits qui fournissent toujours individuellement de la valeur, elle applique cette heuristique.
Pensez lentement, agissez vite
En surface, cette heuristique sonne comme une invitation à une grande planification, lourde et initiale basée sur le papier que les agilistes évitent. Ce n’est pas ce que préconise le professeur Flyvbjerg.
Ce qu’il recommande, c’est de réduire le coût des essais et des erreurs en prenant le temps d’identifier les principaux domaines d’incertitude qui pourraient avoir une incidence sur la réussite et d’apprendre et trouver des moyens de les résoudre efficacement le plus tôt possible dans le cycle de vie du projet.
Les exemples fournis sur la façon dont Pixar planifie ses films ou comment Frank Gehry a conçu le musée Guggenheim de Bilbao démontrent tous deux que la réduction précoce des risques est un attribut essentiel de l’approche adaptative.
Dites non et partez
Le professeur Flyvbjerg souligne l’importance de la concentration lors de la réalisation de projets complexes. Si une action ne contribue pas à l’atteinte des résultats du projet, ignorez-la.
Cela correspond bien au dixième principe du Manifeste : « La simplicité – l’art de maximiser la quantité de travail non effectuée – est essentielle. »
Bien que je n’aie pas couvert toutes les heuristiques et leur applicabilité adaptative dans cet article, j’espère vous avoir tous encouragés à lire ce livre, quel que soit le domaine ou l’approche utilisée pour livrer vos projets.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Vos clients ou parties prenantes viennent-ils parfois vous voir et font pression pour un changement immédiat ? Je suis sûr qu’au moins quelques-uns d’entre eux le font. Les miens l’ont toujours fait.
J’ai remarqué quelque chose à ce sujet, cependant.
La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.
Ces clients et parties prenantes ont appris au fil des ans que s’ils ne parviennent pas à obtenir notre attention immédiate, la demande disparaîtra dans le puits sans fond des demandes et ne sera jamais faite.
Un réel avantage de travailler de manière agile est que nous pouvons changer la conversation avec ces personnes. Au lieu de tout laisser tomber pour répondre à leur besoin immédiat, nous pouvons plutôt leur expliquer que notre équipe évite d’introduire des changements dans une itération, mais sera heureuse de planifier ce nouveau travail dans la prochaine itération.
J’ai eu beaucoup de succès en répondant quelque chose comme ceci
Cela semble important et j’aimerais que nous nous y mettions. Mais nous travaillons par blocs de temps de deux semaines que nous appelons itérations [ou sprints] et nous en sommes au milieu d’une itération en ce moment. Nous essayons vraiment d’éviter d’ajouter un nouveau travail à l’un de ces blocs de temps, car cela affecte notre capacité à tenir les promesses que nous avons pu faire aux autres parties prenantes. Nous avons une nouvelle itération qui commence la semaine prochaine. Que se passe-t-il si je m’engage à planifier cette demande dans cette itération et à vous la donner quelques jours après [ou à la fin de l’itération] ?
Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.
Cela permet aux équipes de mieux planifier leurs itérations et d’avoir moins d’interruptions. Ceci vous aidera à réussir avec agile.
PS: Le management des parties prenantes est quelque chose que Mountain Goat Software couvre dans les cours CSM et CSPO. En tant que Scrum Master, vous apprendrez à minimiser les conflits et à éviter les perturbations lors de réunions clés telles que le daily scrum. Et en tant que Product Owner, vous apprendrez à communiquer efficacement entre les parties prenantes et l’équipe pour apporter constamment de la valeur. Vous pouvez trouver les détails des deux cours ici.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
À lire les nombreux articles qui fleurissent un peu partout, la gestion de projet hybride semble parée de toutes les vertus.
Si cela n’est pas dénué de certains fondements, cette approche possède également quelques inconvénients que l’on oublie trop souvent de présenter.
Qu’est-ce qu’une méthode hybride
Pour commencer, il semble intéressant de revenir à la définition même de la gestion de projet hybride.
Une méthode hybride en management de projet est une approche qui combine différentes méthodes et techniques de gestion de projet pour répondre aux besoins spécifiques d’un projet donné. Elle peut inclure des éléments de méthodes agiles et traditionnelles, ainsi que d’autres approches adaptatives ou itératives.
Pour avoir pratiqué de nombreuses méthodes de gestion de projet durant plus de 25 ans, je reconnais un certain nombre de qualités à l’approche hybride.
En effet, elle permet de combiner les éléments issues des méthodes agiles pour la rapidité de livraison et la réactivité aux changements, avec des éléments issus de la méthode traditionnelle (cycle en V) pour une planification plus structurée et une gestion plus rigoureuse des coûts et des ressources.
Le célèbre cycle en V des approches prédictives
Ainsi, cette approche hybride peut aider à maximiser les avantages de chaque méthode, tout en réduisant les risques et en garantissant une livraison de projet réussie.
Les prérequis trop souvent oubliés
Mais, trop souvent, nous oublions le fait que tirer parti des avantages de chaque méthode nécessite de les connaître en profondeur, de les avoir éprouvées au travers d’expériences concrètes, de succès mais aussi d’échecs.
Cet apprentissage par la pratique rejoint le fameux principe du shuhari, issu des arts martiaux japonais et repris par Alistair Cockburn, figure emblématique de la communauté Agile :
Shu: Découvrir et suivre les règles à la lettre pour les conserver et les protéger
Ha: Comprendre les règles, se les approprier, les éprouver pour en comprendre les limites, faire le lien avec d’autres techniques.
Ri: S’en détacher, les adapter au contexte, voir créer ses propres règles.
La gestion de projet hybride représente donc l’étape ultime, le « Ri » de ce processus d’apprentissage auquel on ne peut accéder qu’au travers des étapes précédentes.
De fait, nous sommes assez loin de la situation trop classique d’une « méthodologie » créée en mode pompier, souvent sur un coin de table et à partir de petits bouts de savoir théoriques, pour tenter de sauver un projet devenu incontrôlable.
La gestion de projet hybride n’est là ni pour pallier à l’absence de formation ni au manque d’expérience pratique des parties prenantes. Et encore moins à l’absence de volonté de transformation des organisations, de formation et d’accompagnement nécessaires lors du passage en mode Agile.
Le côté obscur de l’approche hybride
Se lancer dans une approche hybride sans en maîtriser l’ensemble des composantes présente aussi de nombreux inconvénients qui peuvent rapidement devenir des risques projet.
Les principaux inconvénients :
Le manque de clarté de la démarche : L’accumulation de pratiques disparates, parfois redondantes ou qui présentent des ruptures, est source de confusion et de complexité. Il en résulte souvent une définition floue des rôles et responsabilités de chacun. Ce qui entraîne des erreurs, des retards et surtout de la tension. Ajoutez à cela l’impact du télétravail et le cycle naturel de création des équipes et vous obtenez rapidement une bombe à retardement.
Des coûts supplémentaires : Une méthodologie hybride constituée de techniques mal maîtrisées demande du temps pour se stabiliser. L’affiner et la formaliser nécessite des investissements en formation, en description des processus, en formations à l’utilisation des outils (mal) adaptés à cette méthodologie. Le moindre ajustement vous oblige à reprendre l’ensemble. Bref, tout le monde passe plus de temps sur la méthodologie que sur la production en elle-même.
Le manque de répétabilité : C’est l’une des raisons pour lesquelles la plupart des discours sur les méthodologies hybrides ne se réfèrent qu’à des anecdotes et des expériences auxquelles on ajoute plus ou moins de storytelling. En effet, étant par principe destinée à s’adapter à une situation particulière, chaque méthodologie hybride est unique. Il est donc impossible d’établir des processus standardisés et donc d’établir des études comparatives sérieuses ni même d’en mesurer l’efficacité. Cela rend également obsolète la notion de capitalisation du savoir et de retour d’expérience.
La gestion de projet hybride répond efficacement à certaines situations
En conclusion, oui, la gestion de projet hybride répond à certaines situations. Tous les projets ne nécessitent pas obligatoirement de passer en mode Agile. Apporter de la flexibilité, de la réactivité et mettre la valeur au centre des préoccupations sont de bonnes pratiques qu’il faut encourager.
Mais attention, l’approche hybride ne doit pas être le joker destiné à masquer le manque d’expérience et de maîtrise des méthodologies projet, qu’elles soient classiques ou Agiles.
Contrairement, à ce que l’on entend trop souvent, elle n’est pas non plus un « premier pas » vers l’agilité. En effet, soit votre méthodologie hybride donnera de mauvaises habitudes / pratiques qu’il sera très difficile de changer par la suite. Soit son échec sera utilisé comme un argument de poids par vos détracteurs pour démontrer que l’agilité ne fonctionne pas. Et cela, même si vous ne l’avez pas mis en œuvre dans sa forme la plus basique.
Bref, entre le cycle en V, le Lean, le Kanban, le SCRUM ou le SAFe, il existe de nombreuses méthodes et outils à explorer avant de vouloir faire preuve de créativité.
Ne tombez pas dans l’effet Frankenstein : Une accumulation d’outils et de techniques non maîtrisés ne fait pas une méthode de projet viable. Le monstre aura tôt fait de se retourner contre son créateur et de semer la terreur autour de lui.
Qui est Pierre-Étienne Pernet ?
Pierre-Étienne Pernet
Après 10 ans de gestion et de direction de projets internationaux au sein d’Oracle Consulting, Pierre-Étienne PERNET a rejoint les équipes internes de développement d’Oracle Corporation. Il y a occupé un poste de Product Manager dans les équipes Supply Chain d’Oracle Cloud pendant près de 15 ans. Il a collaboré au développement du module Asset Lifecycle Management.
Aujourd’hui, il est Directeur Consulting Delivery chez CGI. Au sein de l’entité France Global Delivery Center, il a en charge des équipes de consultants dédiées à l’ERP Oracle. Il partage son activité entre la direction de TMA et la direction de projets.
Diplômé d’un Master en gestion de projet et d’affaires au sein de l’Institut International du Management, il a enseigné le management de projets en cycle d’ingénieur au sein du Conservatoire National des Arts et Métiers de Lille pendant 9 ans, en parallèle de son activité professionnelle.
Certifié SAFe, ITIL et PMP, il est membre du chapitre Nord de France du Project Management Institute et volontaire au sein du programme de mentorat. Il accompagne bénévolement les membres du PMI qui souhaitent profiter de ce programme mis gratuitement à leur disposition.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pour de nombreux professionnels de projet, la gestion d’un arriéré d‘histoires utilisateurs dans un projet agile peut se faire sans nécessiter de profonde réflexion. Mais qu’est-ce qui détermine la priorité et comment cela contribue-t-il à produire les bénéfices escomptés ?
Prioritisation in Agile: Focus on the Benefits par Quay Consulting
L’un des principes clés de la livraison de projet agile est la flexibilité de permettre une approche plus itérative et acceptant le changement en ce qui concerne le contenu, garantissant que les éléments les plus à valeur ajoutée sont livrés en premier.
Ce n’est pas une approche exempte de contraintes, loin s’en faut. Les équipes de projet agiles adoptent une vision stricte du temps et des coûts, appelée time-boxing, et reconnaissent que les limites de ressources et de temps permettent à l’équipe de se concentrer sur la répartition et la priorisation du contenu pour s’assurer qu’un bénéfice est livré.
Relisez ce billet
Le rôle du propriétaire du projet est essentiel à la réussite, compte tenu des responsabilités qu’il assume dans la définition, la hiérarchisation et l’approbation ou le rejet du travail fourni par l’équipe. Faire un « bon travail » est rarement suffisant pour garantir un bon résultat, et le rôle que joue le propriétaire du produit est très difficile à bien faire.
Lorsque les processus agiles sont bien suivis et selon des normes élevées et alignées, une approche agile peut maximiser le potentiel de retour sur investissement et offrir les bénéfices recherchés par un projet. Lorsque ces processus sont moins bien exécutés, le risque de ne fournir aucune valeur est très réel.
Alors, quels sont les défis qu’un propriétaire de projet peut rencontrer et comment mettent-ils les avantages en péril ?
Contraintes de priorisation
Le time-boxingest une technique qui permet à un projet de disposer de ressources limitées pour fournir la liste de la portée souhaitée. Il est courant de démarrer un projet avec plus de portée qu’il n’y a de financement pour la réaliser, et même si cela ne commence pas avec cela comme défi initial, l’opportunité créée en construisant de plus petits morceaux de contenus dans les itérations permet à l’équipe d’identifier de nouveaux éléments avec des bénéfices potentiellement plus importants.
Le diagramme illustre l’incidence des contraintes sur l’arriéré de produit lorsqu’une ligne est tracée entre ce qui est prioritaire et qui entre dans l’enveloppe de financement et ce qui n’est pas prioritaire ou pas financé.
Le propriétaire du produit est responsable de la priorisation, en pratique, de décider ce qui est au-dessus ou au-dessous de la ligne. La capacité de prendre les bonnes décisions en matière de priorisation nécessite une compréhension approfondie des besoins, des préférences et des points faibles des clients, ainsi que des buts et objectifs de l’entreprise. Cela nécessite également d’avoir une vision claire du produit.
Mais comment prennent-ils les décisions concernant ce qu’il faut promouvoir et ce qu’il faut dé-prioriser ?
Facteurs de priorisation
Qu’un projet utilise l’agilité ou non, de nombreux facteurs doivent être pris en compte lorsqu’un propriétaire de produit choisit ce qu’il faut prioriser et ce qu’il ne faut pas prioriser.
Par exemple :
Impact utilisateur : Réfléchissez à l’impact de l’histoire utilisateur sur l’expérience de l’utilisateur final. Cela améliorera-t-il leur expérience ou résoudra-t-il un problème important ?
Complexité : Tenez compte de la complexité de l’histoire utilisateur. Est-ce une tâche simple, ou cela nécessite-t-il beaucoup d’efforts et de ressources de développement ? Ce facteur est plus utile lorsqu’il est considéré en conjonction avec la valeur business.
Dépendances : Tenez compte des dépendances de cette histoire utilisateur vis-à-vis d’autres histoires ou fonctionnalités. Sera-t-il plus facile de terminer cette histoire avant ou après une autre ? Cette histoire est-elle nécessaire dans le cadre d’un ensemble pour offrir une expérience significative ?
Risque : Tenez compte du niveau de risque associé à l’histoire utilisateur. Implique-t-elle des risques techniques ou business qui pourraient avoir une incidence sur la réussite du projet ? Y a-t-il des risques de remaniement ou d’utilisation excessive de temps et de ressources qui, si cela se produisait, diminuerait la valeur de l’histoire ?
Temps et coût : Tenez compte du temps et du coût nécessaires pour compléter l’histoire utilisateur. Peut-elle être achevée dans les délais et le budget impartis, et offre-t-elle un retour sur investissement significatif ?
Valeur business : Tenez compte de la valeur commerciale de l’histoire utilisateur. Apporte-t-elle une valeur significative au client ou à l’utilisateur final ? Répond-elle à un besoin ou à un problème critique ? Est-ce que le fait de la terminer rapproche le projet de son objectif ?
Comme la portée est divisée en de nombreux petits éléments de contenu dans les projets agiles, il peut devenir très difficile de déterminer dans quelle mesure chaque élément contribue aux bénéfices globaux que le projet cherche finalement à produire.
Le processus de priorisation et le contexte
Il existe une théorie autour du changement qui sous-tend un projet, y compris les projets agiles. Les bénéfices sont un résultat positif obtenu en fournissant le contenu souhaité.
Il y a un peu plus…
Généralement, un projet commence par des buts et des objectifs, qui sont traduits en portée et livrables. La relation entre les facteurs et le contexte fourni par les buts et objectifs du projet sont des ingrédients importants dans le processus de priorisation car ils aident à donner plus de sens à chaque histoire utilisateur.
Considérons ce que chaque composant représente :
Objectifs : Décrivez les résultats ou les avantages de haut niveau que le projet vise à atteindre ou à impacter; par exemple, un projet vise à améliorer l’expérience client globale de 10 %.
Cibles : Cibles précises, mesurables et limitées dans le temps qui doivent être atteintes pour atteindre les buts du projet. Elles sont souvent décomposées en étapes plus petites et réalisables. Par exemple, si l’objectif du projet est d’améliorer l’expérience de 10%, une cible pourrait être d’améliorer la vitesse de traitement des commandes et leur précision afin de réduire les plaintes des clients de 25%.
Portée : Établit les limites de ce que le projet inclura ou exclura. Elle définit les caractéristiques, les fonctions et les tâches qui feront partie du projet. Par exemple, la portée d’un projet de développement de site Web pourrait inclure la conception et la construction d’un site Web, mais exclure la création de matériel de marketing.
Livrables : Livrables ou résultats tangibles et mesurables qui sont produits à la suite de l’achèvement des travaux du projet. Les livrables peuvent être des produits, des services, des documents ou des rapports. Par exemple, les produits livrables du projet de développement de sites Web pourraient inclure un site Web fonctionnel, des formulaires clients, des articles de connaissances connexes et des services de chat.
Il existe de nombreuses considérations qu’un propriétaire de projet doit prendre en compte lorsqu’il décide de l’arriéré de produit d’un projet agile et celles-ci doivent être faites dans le contexte des buts et de la définition objective du projet. Ceci devrait permettre au propriétaire du projet de peser le mérite de chaque facteur et de déterminer la valeur de chaque histoire utilisateur et comment elle contribue aux bénéfices.
Maintenir un focus laser sur les bénéfices et le retour sur investissement
Les Product Owners doivent solliciter les commentaires, les retours et la collaboration des parties prenantes pour mieux comprendre l’impact ou les conséquences potentiels de la façon dont ils priorisent les histoires utilisateur ou les groupes d’histoires. Cela peut également fournir une perspective sur la complexité ou le coût de leur mise en œuvre et donner un aperçu du point de vue ou de la compréhension des parties prenantes de ce qui est attendu en termes de retour sur investissement.
La nature interdépendante de ces éléments démontre qu’il n’y a jamais de processus linéaire ou simple dans la hiérarchisation des priorités; Les histoires utilisateur et la façon dont elles sont priorisées ne peuvent pas être prises isolément sans effet sur les résultats. Des composants à valeur ajoutée pourraient être livrés, mais pas fusionnés dans une solution cohérente.
Il est essentiel que les propriétaires de produits soient en mesure de se concentrer sur les bénéfices et le retour sur investissement dans la façon dont ils prennent des décisions sur comment ils décomposent le contenu et décident quelles histoires d’utilisateurs sont incluses ou dé-priorisées.
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vous propose de commencer par Scrum.Org avant de zoomer sur les valeurs de Scrum, le Sprint Planning et les Sprint Reviews.
Ces vidéos peuvent s’avérer très utile pour sensibiliser votre comité de projet, votre sponsor et autres parties prenantes à ce qu’est Scrum avec ses valeurs ainsi que certaines de ses « cérémonies » les plus utiles.
Dans cette vidéo de 2 minutes, apprenez-en davantage sur ce que Scrum.org est et fait.
Voici quelques exemples de comment appliquer les valeurs Scrum de courage, engagement, focus, ouverture et respect.
Comment faciliter le Sprint Planning ?
Dans cette vidéo introductive, comprenez comment et quand utiliser certaines techniques de facilitation comme le vote romain, la visualisation et le questionnement afin que votre équipe puisse quitter la session de planification du sprint avec un objectif de sprint en direction de l’objectif du produit et un plan initial pour le sprint.
Comment faciliter les primordiales sessions de Sprint Review ?
Voici au moins une technique de facilitation qui va vous aider à transformer la revue de sprint en une session plus engageante et collaborative. Vous pourrez alors y recueillir des commentaires précieux des parties prenantes pour déterminer les futures adaptations de votre approche et de votre produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Daily Scrum n’a qu’un seul but : Inspecter les progrès vers l’objectif de sprint en réfléchissant à l’apprentissage d’hier. Ensuite, si le besoin s’en fait sentir, les développeurs adaptent leur plan pour atteindre l’objectif de sprint. Bien que la théorie puisse être généralement acceptée, passer de l’idée à la pratique est plus difficile. L’un des problèmes récurrents est la popularité continue des « 3 questions du Daily Scrum» selon le Guide Scrum 2017.
Réfléchissons à la raison pour laquelle répondre à ces questions obsolètes influence négativement l’équipe Scrum.
Le but du Daily Scrum
Le but du Daily Scrum est clairement décrit dans le Guide Scrum, aucune supposition n’est nécessaire :
« Le but du Daily Scrum est d’inspecter les progrès vers l’objectif de sprint et d’adapter le backlog de sprint si nécessaire, en ajustant le travail prévu à venir.
Guide téléchargeable gratuitement
Le Daily Scrum est un événement de 15 minutes pour les développeurs de l’équipe Scrum. Pour réduire la complexité, il a lieu à la même heure et au même endroit chaque jour ouvrable du Sprint. Si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que développeurs. »
Par conséquent, le Daily Scrum est un événement important pour l’inspection et l’adaptation, géré par les développeurs, et les guidant pour les prochaines 24 heures sur leur chemin vers la réalisation de l’objectif de sprint. Le Daily Scrum est également l’horizon de planification le plus court dans Scrum et donc très efficace pour guider les efforts de l’équipe Scrum : se concentrer sur le résultat.
Le problème avec les 3 questions quotidiennes
Cependant, cette noble idée est entachée d’une habitude répandue : Centrer la réunion quotidienne autour de la réponse à trois questions
Qu’est-ce que j’ai fait hier ?
Que vais-je faire aujourd’hui ?
Y a-t-il un obstacle ?
Initialement, ces trois questions du Daily Scrum ont été ajoutées au Guide Scrum 2017 comme exemple de la façon dont les membres de l’équipe Scrum peuvent inspecter les progrès vers l’objectif de sprint. Cependant, ces trois questions sont rapidement devenues synonymes de Daily Scrum. Depuis lors, il s’agissait de répondre à ces trois questions, de transformer le Daily Scrum en une sorte de réunion de rapport d’état d’avancement, avec des développeurs faisant la queue pour « répondre à ces trois questions » au Scrum Master, au Product Owner, ou peut-être même à une partie prenante.
Malheureusement, les « trois questions du Daily Scrum» plaisent à de nombreux praticiens : Elles sont simples, efficaces et créent une routine réconfortante. Cependant, en tant qu’équipe Scrum, nous nous soucions moins de détailler notre travail précédent et de justifier pourquoi nous méritons un chèque de paie à la fin du mois.
Au lieu de cela, nous voulons comprendre si nous atteindrons l’objectif de sprint. Si les progrès de l’équipe Scrum sont douteux, compte tenu des développements récents et des apprentissages, nous voulons prendre des mesures pour nous remettre sur les rails. Toute forme de rapport de situation est une simple distraction et un gaspillage à cet égard.
Scrum en tant que pratique est axée sur les résultats
Il ne s’agit pas de maximiser le nombre de tickets obtenus pendant le Sprint. Au lieu de cela, en tant qu’équipe, nous sommes intéressés par atteindre l’objectif de sprint.
Il existe d’innombrables façons d’exécuter votre Daily Scrum sans tomber dans cette routine des 3 questions. Par exemple, parcourez le tableau et déterminez ce qui doit être fait pour déplacer les billets les plus proches de « terminés » sur la ligne d’arrivée.
Livre sur Amazon
Consultez les pratiques d’utilisation des liberating structures pour faciliter le Daily Scrum.
S’il vous plaît, faites-vous une faveur et évitez de transformer votre Daily Scrum en une session de reporting ennuyeuse.
Comment gérez-vous vos Daily Scrum ? S’il vous plaît, partagez vos conseils et astuces dans les commentaires.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Il existe plusieurs techniques différentes pour mener le processus d’estimation. Cet article décrit ces techniques, leur pertinence et leur praticité dans les projets Agiles.
Les estimations traditionnelles sont basées sur des unités de jours ou d’heures (dans de rares cas, je l’ai même vu utilisé pour estimer des histoires basées sur 20, 30 et 45 minutes), et l’équipe les utilise pour estimer leurs histoires et leurs tâches. À mon avis, c’est bien si cela aide l’équipe dans le processus de transition et même si elle veut l’adopter comme technique d’estimation. J’espère que vous ne tenez pas compte des récits selon lesquels les estimations traditionnelles ne conviennent pas à Agile car elles sont rarement exactes pour tous ceux d’entre vous qui pensent autrement.
Taille de T-shirt
La taille des t-shirts est une excellente technique d’estimation que j’utilise dans les organisations au début de la transformation. Vous ne pouvez pas utiliser de story points avec certaines équipes, car les membres de l’équipe alignent les story points sur des heures d’effort. Cela conduit à une confusion supplémentaire.
La taille du t-shirt permet aux équipes de surmonter ce problème car cette technique d’estimation n’est pas numérique. Cela permet aux équipes Agile de travailler avec quelque chose de plus facile à comprendre. Cela supprime la précision implicite d’une valeur numérique et libère l’équipe pour penser de manière abstraite à l’effort qu’elle doit investir dans chaque histoire.
Le processus de base de cette technique est relativement simple à utiliser
Un jeu de cartes représentant une taille spécifique est distribué horizontalement sur une table. Les tailles sont divisées en Extra Small (XS), Small (S), Medium (M), Large (L) et Extra Large (XL).
L’équipe ajoute chaque user story sous la carte de taille appropriée.
Une fois que toutes les histoires sont triées sur la base d’une discussion collaborative, l’équipe approuve leur sélection ou conduit un autre cycle de débat sur les histoires qui ont révélé une grande incertitude.
Vote par points (dot voting)
Le vote par points est une autre technique d’estimation relative. Il permet aux équipes Agile de voter leurs préférences parmi un ensemble d’éléments en plaçant simplement des points sur des éléments (par exemple, des fonctionnalités, des histoires, des obstacles, etc.) qui, selon elles, devraient avoir une priorité plus élevée que les autres éléments. Le nombre de points détermine le niveau de priorité. Plus il y a de points, plus la priorité de l’élément est élevée.
Le vote par points est une technique d’estimation très efficace car il permet à tous les membres de l’équipe d’affecter la priorité des éléments de manière égalitaire. Tous les membres de l’équipe ont un nombre égal de votes (représentés par des points), qu’ils peuvent répartir entre les éléments dans le cadre du processus d’estimation.
Par exemple, l’équipe a dressé une liste de huit points lors de la réunion rétrospective. Ils doivent maintenant restreindre la liste aux éléments de valeur la plus élevée. Pour ce faire, chaque membre de l’équipe reçoit un nombre égal de points (entre 3 et 5) pour voter sur les éléments.
Remarque: Ils peuvent mettre tous les points sur un élément ou les répartir entre différents éléments.
Le processus d’utilisation de haut niveau de cette technique d’estimation comprend les phases suivantes
Phase 1 : Facilitation, examen et vote
Tous les articles sont placés dans un endroit accessible pour permettre aux membres de l’équipe de voter.
Tous les éléments sont examinés et compris par toutes les parties prenantes.
Chaque membre de l’équipe reçoit un nombre égal de points (j’utilise généralement cinq points).
Chaque membre de l’équipe est invité à voter. Chacun des membres place des points sur les éléments en fonction de son jugement.
Une fois le processus d’estimation terminé, les articles sont classés du plus fort au plus faible nombre de points.
Approuvez avec l’équipe le résultat du vote.
Phase 2 : Ajustements et nouveau vote (facultatif)
Si l’équipe n’est pas complètement satisfaite du résultat (comme cela arrive souvent…), vous devez suivre les étapes suivantes pour optimiser le résultat :
Organisez les éléments en trois groupes pour représenter les priorités faibles, moyennes et élevées.
Passez en revue avec l’équipe les histoires de chaque groupe.
Lancez un nouveau cycle de vote pour tous les points de priorité la plus élevée.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Même si je ne suis pas personnellement un grand fan de SAFe, une nouvelle version recèle toujours son lot de nouveautés dont nous pouvons toutes et tous apprendre : Voici donc SAFe 6.0 !
Cette version représente une avancée significative dans la façon dont les entreprises intègrent les pratiques SAFe dans le travail quotidien, font perdurer le changement et obtiennent les avantages d’une véritable agilité business. SAFe 6.0 comprend de nombreuses nouvelles pratiques pour supporter les dernières tendances technologiques et business, y compris comment accélérer le flux de valeur et étendre SAFe à travers toute l’organisation à d’autres fonctions business.
Et, bien sûr, ces nouvelles directions se reflètent dans les mises à jour du didacticiel, de l’apprentissage en ligne et des ressources SAFe. Leading SAFe®, l’un des cours les plus populaires de Scaled Agile, est désormais disponible en français.
Pour tous les détails, lisez l’article What’s new in SAFe 6.0. Et n’oubliez pas de regarder les vidéos d’annonce de lancement de SAFe 6.0 pour en savoir plus sur SAFe Studio, SAFe 6.0 et d’autres nouveaux produits pour vous aider dans votre parcours SAFe.
Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles. La façon dont nous abordons les discussions difficiles peut faire la différence entre un moment de transformation et un déraillement. Heureusement, nous pouvons faire beaucoup pour nous préparer à ces moments où nous devons nous débattre d’une question épineuse. Examinons quelques stratégies pour faciliter les conversations difficiles de l’équipe Scrum.
Sujets sensibles et fort niveau émotionnel
Les conversations difficiles impliquent des niveaux élevés d’anxiété, d’inquiétude ou de doute. Peut-être devons-nous prendre une décision difficile ou trouver comment faire quelque chose que nous n’avons jamais réalisé auparavant. Peut-être qu’il y a un conflit entre les membres de l’équipe, ou qu’il y a eu un échec important ou bien un Sprint exceptionnellement difficile. Peut-être que les parties prenantes ne sont pas satisfaites des progrès ou ont des opinions divergentes sur l’orientation du produit ou sur la façon d’interpréter les changements sur le marché. Il existe une myriade d’exemples de circonstances à enjeux élevés auxquelles les équipes Scrum sont régulièrement confrontées et qui nécessiteront des conversations difficiles. Alors, comment pouvons-nous traverser ces périodes avec succès ?
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Respirez et préparez-vous
L’un des faux pas les plus courants que nous faisons face à une conversation difficile est d’être réactif et de sauter directement sur une tentative pour « résoudre » le problème.
Mais une facilitation réussie implique de prendre le temps de vous familiariser avec la situation et de décider comment vous allez l’aborder.
Idéalement, vous serez en mesure de prendre suffisamment de temps pour vous préparer en toute confiance. Mais même dans les situations où une situation difficile a émergé, vous pouvez souvent faire une brève pause pour vous recentrer. Laisser le temps à la conversation de se dérouler avant de vous lancer vous aidera à comprendre les problèmes. Vous pourriez avoir besoin de proposer une ou plusieurs sessions de travail pour permettre aux gens d’analyser des idées et des options avant de vous réunir.
Définissez l’intention
Le fait d’être clair sur l’objectif de la conversation apporte de la clarté au processus de facilitation. Tout le monde autour de la table devrait savoir pourquoi ils sont là et quelles sont les attentes.
Êtes-vous réunis pour chercher à comprendre le point de vue de chacun ? Allez-vous réfléchir ensemble à des solutions ou parvenir à un consensus sur les idées déjà sur la table ? Devez-vous en équipe réparer les relations interpersonnelles ou créer une identité d’équipe plus claire ? Avoir une idée claire de l’objectif de se réunir réduit l’anxiété et maintient la conversation centrée et productive.
Soyez inclusif
Familiarisez-vous avec la gamme de techniques et activités de facilitation adaptées à différentes personnalités et attitudes. Certaines personnes préfèrent faire un remue-méninge par elles-mêmes avant de partager des idées en groupe. D’autres préfèrent interagir en petits groupes ou partager leurs pensées par écrit plutôt que verbalement. Les techniques impliquant la visualisation, les métaphores et autres outils créatifs peuvent également mieux convenir à certaines équipes. Vous aurez probablement besoin de combiner ces techniques et outils.
Comprendre la dynamique de notre équipe et présenter les options aidera à faire en sorte que tout le monde se sente aussi à l’aise que possible pour s’engager.
Soyez présent
Soyez présent et appréciez pleinement cette opportunité.
Les facilitateurs efficaces sont à l’écoute de ce qui se passe pendant la conversation en :
Écoutant activement (vous vérifiez avec l’orateur pour vous assurer que vous avez compris ou pour clarifier).
Lisant les messages non exprimés, telles que « se déconnecter » en regardant son smartphone ou d’autres indices.
Remarquant des interactions entre les membres de l’équipe qui pourraient révéler une dynamique tacite en action.
Être conscient et présent vous permet de détecter la direction de la conversation et de faire des choix éclairés dans l’instant.
Soyez flexible
Bien que vous deviez être intentionnel et prêt à faciliter, vous devez également vous adapter à ce qui se passe devant vous. Comme tous les agilistes le savent, les choses ne se déroulent pas toujours comme prévu, il est donc préférable de ne pas trop vous attacher à votre agenda ou à des structures de facilitation spécifiques.
Ralentissez
Il est très facile dans les situations de forte émotion de passer en mode réactif, ce qui réduit votre capacité à rester ouvert, flexible et créatif. Vous voulez éviter une réaction instinctive à ce que vous entendez ou expérimentez pour diriger la situation de manière réfléchie. Vous pouvez en apprendre plus sur cette dynamique dans ce précédent article Staying Creative in a Reactive World.
Prendre conscience de la façon dont vous réagissez pendant les périodes stressantes peut vous aider à rester calme et à changer de cap si nécessaire. Une première étape utile consiste simplement à ralentir les choses lorsque le stress du moment vous incite à les accélérer. Ce n’est pas aussi facile qu’il n’y paraît. Les anglophones nord-américains deviennent typiquement mal à l’aise avec des pauses de plus de quelques secondes dans les conversations. Il faut de la pratique.
Faire des pauses régulières pour traiter l’information améliore la compréhension et vous permet de répondre avec curiosité et ouverture. Alors, respirez et encouragez les autres membres de votre équipe à faire de même. Prendre des pauses fréquentes permet également aux membres de votre équipe qui pourraient avoir besoin de plus de temps pour traiter les informations de s’engager plus facilement. Il permet à chacun de prendre de meilleures décisions, plus éclairées.
Reconnaissez également que certaines situations et décisions nécessitent plus de temps que d’autres. Nous avons tendance à avoir un faux sentiment d’urgence dans nos organisations, mais souvent nous pouvons retarder un peu les décisions quand nous devons prolonger la conversation ou recueillir plus d’informations. L’expression « Prenez des décisions au dernier moment raisonnable » me vient à l’esprit.
Notez que je ne préconise pas d’étendre les durées des événements Scrum. Si les problèmes que vous devez traiter nécessitent plus de temps, il est préférable de déplacer ces discussions en dehors de l’événement.
Cultivez un « espace courageux »
Faciliter une conversation difficile avec succès nécessite une sécurité psychologique pour les participants. Les membres de l’équipe doivent savoir qu’ils ne seront pas punis ni humiliés pour avoir dit ce qu’ils pensaient et suggéré des idées. Mais gardez à l’esprit qu’un espace « sûr » ne signifie pas nécessairement être parfaitement à l’aise. Les membres de l’équipe vont éprouver des sentiments inconfortables en discutant de questions épineuses.
Je promeut plutôt l’idée d’un « espace courageux ». Dans un espace courageux, nous sommes prêts à être vulnérables. Nous sommes ouverts aux commentaires difficiles de nos collègues. Nous nous engageons à apprendre.
Les compétences en animation sont pour tout le monde
L’amélioration des compétences en animation n’est pas réservée aux Scrum Masters. Tout membre de l’équipe Scrum peut animer des événements et des sessions de travail. Les compétences en facilitation sont précieuses pour de nombreux problèmes qui surviennent dans votre vie professionnelle quotidienne, et lorsque chaque membre de l’équipe Scrum se sent à l’aise avec la facilitation, toute l’équipe en bénéficie.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Conclusion
Il existe de nombreuses techniques de facilitation créatives et intéressantes disponibles en ligne. Mais il est essentiel que vous soyez intentionnel quant aux techniques que vous sélectionnez, comment vous les combinez et comment vous choisissez de répondre dans l’instant en ce qui concerne la direction de ce qui émerge au cours de nos conversations.
C’est pourquoi j’apprécie la formation Professional Scrum Facilitation Skills (PSFS). Tout comme « there are no best practices in Scrum”, il n’a pas de meilleures techniques de facilitation. Ce cours vise à vous aider à développer l’état d’esprit d’un facilitateur, en apprenant à sélectionner des techniques efficaces pour différentes situations dans votre contexte.
Petit rappel: Développez la productivité et l’innovation avec des groupes de toutes tailles grâce aux Liberating Structures !
Visitez le site en Français
Voici un pointeur fort utile vers des méthodes (et une app pour votre mobile) pour vous aider à impliquer tout le monde lors de vos sessions de travail de groupe.
Téléchargez l’app LISA sur votre smartphone IOS ou Android. C’est gratuit, très intéressant et fort utile !
partagez ce billet avec vos amis, collègues et relations professionnelles
Les rétrospectives présentent de belles opportunités pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.
Improving organizational culture through retrospective recognition par Kiron Bondale
Après avoir observé les acheteurs frénétiques en compétition les uns avec les autres lors des ventes du Black Friday à l’automne dernier, on pourrait être tenté d’oublier que Thanksgiving était à l’origine une expression de gratitude.
Guide téléchargeable gratuitement
Le Guide Scrum n’identifie pas spécifiquement l’expression d’appréciations comme un ingrédient clé des rétrospectives de sprint, mais il énumère les activités qui peuvent intégrer l’appréciation telles que l’inspection des interactions des membres de l’équipe et le rôle du Scrum Master pour encourager l’équipe non seulement à être plus efficace, mais aussi à passer un moment plus agréable ensemble au prochain sprint.
Les animateurs de rétrospectives encouragent souvent les participants à identifier ce qui s’est bien passé ou ce qu’ils ont aimé. C’est une bonne opportunité pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.
Remercier pour l’aide reçue pour franchir un obstacle signifie aussi que vous seriez prêt à aider à votre tour.
Tout comme l’identification des possibilités d’amélioration, les membres de l’équipe doivent non seulement reconnaître les grandes réalisations, mais aussi les petites qui peuvent s’additionner au fil du temps. Nous sommes prompts à reconnaître un membre de l’équipe qui a laissé tomber ce qu’il faisait pour nous aider pendant quelques heures sur une question vraiment délicate, mais qu’en est-il de ce membre de l’équipe qui nous a emmenés prendre un café parce qu’il a remarqué que nous semblions être particulièrement stressés ce jour-là ?
Tout comme pour fournir des commentaires constructifs, nous ne devrions pas attendre une prochaine rétrospective pour nous remercier, mais la cérémonie de rétrospective offre une bonne occasion de remercier tardivement ceux dont les efforts ont fait la différence au cours du sprint passé. Un Scrum Master peut introduire cette pratique dans une rétrospective en utilisant des chocolats ou tout autre petit cadeau à offrir par les membres de l’équipe à ceux qu’ils souhaitent reconnaître. Dans les rétrospectives ultérieures, l’équipe peut identifier de nouvelles façons de faire pour garder la pratique vivante.
Toute personne qui a participé ou initié une chaîne de « paiement en avance » serait probablement d’accord avec l’auteur de l’article. Lorsque quelqu’un apprécie de vive voix ce que nous faisons, nous ressentons le besoin de faire de même. Exprimer régulièrement vos sentiments positifs pourrait améliorer progressivement la culture au sein de vos équipes, de vos départements et, éventuellement, de votre organisation globale.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.
Voici des questions que vous pouvez utiliser pour développer vos propres critères de qualification pour Agile :
Pouvez-vous obtenir le bon personnel ?
Les membres appropriés de l’équipe technique et métier doivent être dédiés au projet. Cela signifie que vous devez gérer les compromis difficiles entre le travail de projet et les considérations opérationnelles. Les projets agiles produisent des résultats rapidement, ils prennent donc beaucoup de temps aux participants. De plus, les approches agiles nécessitent des membres essentiels des équipes business et technique qui sont critiques à vos activités opérationnelles. Il est important de prioriser leur temps sur le projet afin qu’ils puissent contribuer efficacement.
Les ressources ont-elles une profondeur de connaissances appropriée ?
Une connaissance approfondie des domaines business et techniques liés au projet est cruciale. L’approche agile repose sur des experts métier travaillant en étroite collaboration avec les experts de l’équipe technique. Ce qui rend les méthodologies agiles Agile, c’est la réactivité à l’évolution des besoins. Les techniciens et les personnes du business compétents doivent constamment réévaluer les livrables du projet, les besoins de l’entreprise aux niveaux macro et micro et la priorité des fonctionnalités requises par le client final.
Le Sponsor a-t-il un état d’esprit Agile ?
Le sponsor doit être disposé à participer à des revues fréquentes du produit en construction, qui sont fondamentales dans l’approche agile. La réactivité agile aux conditions changeantes de l’entreprise et son environnement évolutif sont très différentes des méthodes de projet traditionnelles. Si un sponsor veut un ensemble linéaire et méthodique d’objectifs livrés selon un calendrier prédéfini, il aura du mal avec les livrables du projet en approche agile. Les sponsors qui sont mal à l’aise avec la nature évolutive de l’agilité créent des difficultés qui peuvent couler le projet.
L’équipe peut-elle être co-localisée (physiquement ou virtuellement) ?
Agile implique un dialogue profond, interactif et parfois difficile. Pour tirer le meilleur parti de ce dialogue, vous devez créer l’environnement le plus riche possible. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la colocalisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir. Essayez de faciliter un dialogue agile avec des outils de communication médiocres, c’est comme essayer de remorquer une caravane avec une tondeuse à gazon.
Existe-t-il une synergie entre les membres de l’équipe business et technique ?
Une équipe agile doit bien s’entendre pour réussir. Les méthodologies agiles nécessitent le dévouement d’experts business et techniques qui sont ouverts à soutenir de nouvelles idées et à se soutenir les uns les autres en tant qu’individus. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations.
Le produit peut-il être construit (et livré) de manière itérative ?
Les meilleures qualités des approches Agile proviennent de la fourniture de solutions partielles tout en apprenant de chaque itération. En plus des livrables logiciels, d’autres produits peuvent également être construits de cette façon. Avec un peu de créativité, des déménagements, la mise en œuvre de nouveaux processus et même certains projets de construction dans le bâtiment peuvent utiliser des approches agiles.
Utilisez-vous d’autres critères pour déterminer si un projet est candidat à une approche agile ?
Si oui, partagez-les avec nous !
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Les signataires de ce Code sont multiculturels, multigénérationnels et affiliés à de nombreux groupes différents. Nous croyons que la puissance de ce mouvement est amplifiée lorsque nous mettons de côté les différences et que nous nous aidons les uns les autres à nous élever dans la poursuite d’une meilleure voie. Nous nous engageons à nous soutenir mutuellement dans les décisions difficiles et les conversations courageuses.
Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.
DantotsuPM.com 