5 manières pour le #ScrumMaster d’améliorer ses réunions quotidiennes « Daily Standups »

Les Daily Standups peuvent devenir des corvées superficielles, chacun passant simplement à travers les rubriques.

5 Ways ScrumMasters Can Enhance Daily Standups

https://www.agileconnection.com/article/5-ways-scrummasters-can-enhance-daily-standups par Ajeet Singh

Les Daily Standups peuvent devenir des corvées superficielles, chacun passant simplement à travers les rubriques. C’est le travail du ScrumMaster que de s’assurer que cela n’arrive pas et que ces réunions restent utiles pour chaque membre de l’équipe.

Épuisé par la corvée du Daily Standup ?

Avec ces 5 idées, le ScrumMaster peut activement aider les Daily Standups à rester efficaces et encourager la communication, la transparence et une livraison efficace de valeur.

Les Daily Standups sont principalement un outil de synchronisation pour des équipes de développement. Elles y discutent des progrès réalisés et planifient leur travail pour les vingt-quatre heures suivantes. Le ScrumMaster en est le facilitateur et d’autres parties prenantes du projet peuvent aussi venir écouter.

Les équipes sont libres de décider elles-mêmes de comment elles veulent utiliser ces réunions de quinze minutes, mais cela met une responsabilité complémentaire sur les épaules du ScrumMaster qui doit s’assurer que la réunion produit toujours deux résultats critiques :

  1. L’équipe se concentre sur les aspects cruciaux à la progression, y compris la façon de dynamiter les obstacles et elle est capable de mettre en place un plan de travail réaliste pour la journée.
  2. Le propriétaire de produit, le Product Owner, et les parties prenantes peuvent y puiser l’information essentielle sur les progrès réalisés vers la production de code utilisable qui apporte de la valeur aux utilisateurs.

Voici 5 façons pour le ScrumMaster de mieux faciliter les Daily Standups pour atteindre ces objectifs et encourager la communication, la transparence et la livraison efficace de valeur.

CertYou est partenaire de DantotsuPM

1. Contrôlez fermement le travail en cours

Scénario : Une développeuse indique au daily standup qu’elle prévoit de travailler sur une nouvelle histoire et ne voit pas d’obstacle immédiat. Le ScrumMaster demande si l’histoire sur laquelle elle travaillait hier est finie et elle répond que l’histoire a été mise en attente en raison d’une question d’architecture technique qu’un architecte doit examiner, donc elle planifie de travailler sur autre chose.

Les points de blocage ne sont pas toujours explicitement exprimés causant de longues périodes d’attente improductives.

C’est une bonne chose que le ScrumMaster ait posé une question pour découvrir le fait qu’une histoire est en attente et qu’il y a des obstacles qui n’ont pas été discutés ou adressés sur celle-ci. Maintenant, le ScrumMaster peut suggérer que lui et la développeuse rencontrent immédiatement un architecte pour accélérer l’élimination du point de blocage pour que le travail de priorité la plus élevée puisse continuer.

Faire ceci permet de contrôler le travail en cours (Work In Progress : WIP) en se focalisant sur achever le travail qui a été engagé avant de commencer quelque chose de nouveau. Cela rappelle aussi à l’équipe de tenir le compte de combien d’histoires sont engagées en même temps et à garder le WIP sous une certaine limite qui aura été agréée avec l’équipe.

2. Encouragez la collaboration sur des activités quotidiennes

Scénario : Un testeur au Daily Scrum dit qu’il continuera à tester l’histoire débutée hier et qu’il n’y a aucun obstacle. Le ScrumMaster demande si ce test peut être achevé avant la fin de la journée et si oui ce qu’il fera ensuite. Le testeur se rend compte qu’il a oublié de mentionner qu’il prendra probablement une nouvelle histoire à tester après le déjeuner, mais il n’en a pas encore discuté avec le développeur.

Sur quelle pièce de travail, le testeur va-t-il essayer d’éliminer les imperfections quand il en aura fini avec l’actuelle ?

Le ScrumMaster s’est assuré que cette collaboration critique prend place quand on passe d’une histoire à la suivante. Le bénéfice est que, parce que l’équipe entière sait ce qui arrive, quelqu’un qui connaît de cette nouvelle histoire peut fournir l’information.

Il est essentiel que le ScrumMaster s’assure que le développement et les tests collaborent chaque jour et discutent des histoires comme elles sont mises en œuvre et testées.

3. Identifiez tous les points de blocage ou blockers

Scénario : L’administratrice de la base de données dit qu’elle a fini une histoire hier et en a pris une autre qu’elle prévoit de continuer aujourd’hui et qu’il n’y a aucun obstacle. Mais le ScrumMaster se rappelle qu’il y avait eu quelques échanges d’email récents entre cette administratrice de base de données et l’expert du sujet chez le client pour clarifier certains points sur cette histoire, donc le ScrumMaster

Il faut trouver la personne qui saura dégager le chemin.

demande si ces questions ont été résolues. L’administratrice de base de données reconnaît qu’il reste des choses à clarifier pour cette histoire et qu’il y a en réalité des blockers sur lesquels le ScrumMaster ou quelqu’un d’autre pourraient aider.

Il est important pour le ScrumMaster de suivre à la trace toutes les questions non résolues et de s’assurer que l’équipe en discute ouvertement pour que la personne qui en a la capacité puisse aider à les éliminer rapidement.

L’avantage que cette facilitation amène est que l’équipe devient plus attentive aux questions en attente de réponses et se rappelle d’utiliser le ScrumMaster pour aider à déminer ces questions.

4. Aidez l’équipe à décider de la priorité des problèmes

Scénario : Une équipe travaille sur des problèmes de production et de développement de nouvelles fonctionnalités, ce qui les force à répartir leur travail entre ces deux domaines. Le ScrumMaster pose des questions sur les problèmes majeurs de production: Sont-ils bien priorisés ? Sont-ils répartis équitablement dans toute l’équipe, ou au moins planifiés correctement pour chacun ? Et impacteront-ils la finalisation des nouvelles fonctionnalités prévues ? L’équipe se rend compte qu’elle ne parviendra pas à compléter toutes les nouvelles fonctionnalités, donc les membres discutent de la priorisation avec le propriétaire de produit pour obtenir son avis.

Le ScrumMaster devrait continuellement aider l’équipe à manager les attentes avec le côté business et mieux négocier le contenu du développement pour les prochains sprints. Ainsi, le côté métier/business sait toujours où en sont les choses et n’est jamais pris par surprise à la fin d’un sprint.

5. Soutenez des formats alternatifs de Daily Standup

Scénario : Au lieu d’utiliser le format de Daily Standup classique et répondre à trois questions (Qu’avez-vous fait hier ? Que ferez-vous aujourd’hui ? Qu’est-ce qui bloque la progression ?), l’équipe décide de discuter chaque histoire une par une, en faisant parler ceux qui sont directement impliqués. Malheureusement, cela implique que ces réunions prennent plus de temps…

Pendant la rétrospective suivante, le ScrumMaster suggère que l’équipe regarde les façons de ramener leur Daily Standup à quinze minutes. Le ScrumMaster commence aussi à surveiller l’horloge pendant les Daily Standup, aidant l’équipe à apprendre comment communiquer leurs partages plus efficacement.

Les Daily Standups risquent fort de se muer en travail de ménage superficiel

Parce que c’est la réunion de l’équipe et qu’ils devraient auto-organiser pour décider ce qu’ils veulent, le ScrumMaster devrait soutenir des formats alternatifs de Daily Standup si l’équipe pense que c’est ce qui aura du sens pour ses membres. Mais il reste toujours que la priorité majeure du ScrumMaster est de s’assurer que les objectifs du standup sont aussi atteints.

Les Daily Standups peuvent se muer en travail de ménage superficiel, chacun survolant simplement les questions. C’est le travail du ScrumMaster de s’assurer que cela ne se produise pas et que les réunions restent utiles pour chacun. Avec ces 5 idées, le ScrumMaster peut activement aider les Daily Standups à être efficaces et atteindre leur but.

Incrémental ou itératif, est-ce la même chose dans les projets ? par Henny Portman

Pendant les formations qu’il délivre, Henny Portman a remarqué que souvent les élèves confondent les mots itératif et incrémental: il nous donne les clés pour les distinguer et les utiliser plus efficacement en fonction des projets.

Grâce à ces petites vidéos, Henny nous fait mieux comprendre la relation entre le développement progressif et itératif.

QRP est partenaire de DantotsuPM

Il commence par une comparaison entre une approche prédictive, en cascade / waterfall, et une approche agile pour construire une application de paiement en ligne

Dans un second temps, Henny positionne waterfall et agile dans une matrice incrémental versus itératif et montre ce qui se passe dans chaque quadrant.

Pour finir, Henny explique produit minimal viable (MVP) et produit minimal commercialisable (MMP) et montre comment ils s’inscrivent dans les différentes approches et cartographie.

Pour aller plus loin, lisez cet article en anglais sur PM World Journal : pmwj92-Apr2020-Portman-are-incremental-and-iterative-the-same

CertYou est partenaire de DantotsuPM

Comment surmonter 4 objections communes au « Daily Scrum » ?

Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Et pourtant, elles sont fort utiles si bien menées.

Overcoming Four Common Objections to the Daily Scrum

https://www.mountaingoatsoftware.com/blog/overcoming-four-common-objections-to-the-daily-scrum par Mike Cohn

Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Je n’aime pas non plus les réunions. Mais, certaines réunions sont utiles et justifient l’investissement de notre temps. Je mets les réunions Daily Scrum bien-dirigées dans cette catégorie.

Dans cet article, je partage avec vous comment je traite quatre objections fréquentes à la participation au Daily Scrum. Je partage ensuite quelques attributs d’un Daily Scrum bien-mené pour qu’il n’y ait plus aucune objection à participer.

4 objections fréquentes

1. Nous parlons déjà beaucoup

Pas de temps à « perdre » alors que nous discutons déjà énormément.

La première objection au Daily Scrum est qu’une personne insiste sur le fait que les membres d’équipe parlent déjà fréquemment l’un avec l’autre et donc le Daily Scrum est une surcharge inutile.

Quand j’entends cette objection, j’y résiste en reconnaissant que les membres de l’équipe parlent vraiment fréquemment en effet l’un avec l’autre. Mais rarement parlent-ils tous ensemble.

Le Daily Scrum fournit cette opportunité. Pour beaucoup d’équipes, c’est l‘unique fois chaque jour où chaque membre d’équipe est capable de parler à tous les autres membres de l’équipe.

2. Rien d’important n’est jamais discuté

Une deuxième objection commune au Daily Scrum vient de membres d’équipe qui estiment que des Daily Scrum sont inutiles parce que rien d’important n’y est jamais discuté.

Repositionnez les attentes
catching the big one
On ne priorise pas la discussion pour discuter des plus importants problèmes en premier.

La première chose je fais quand je suis face à cette objection, est de poser une attente appropriée sur ces réunions avec l’opposant. Je suis très clair sur le fait que je ne m’attends pas à ce que quelque chose d’important soit abordé chaque réunion. Certains Daily Scrum s’avèrent vraiment être assez inutiles, ceux où chacun a réalisé un progrès convenable mais sans quoi que ce soit de remarquable hier et personne n’a de question sur le travail du jour.

Mais, la plupart des Daily Scrum remontent vraiment quelque chose d’utile pour l’équipe. Et l’idée est que les nombreux Daily Scrum où des choses importantes sont discutées compensent les réunions moins fréquentes où rien d’important n’est discuté.

Déterminez si l’objection est valide

La deuxième et plus importante chose que je fais quand j’entends cette objection, est de considérer si elle est recevable. Elle peut l’être. S’il en est ainsi le Scrum Master devrait la prendre en compte comme un indicateur que les réunions pourraient être améliorées.

Prenons le temps de considérer objectivement si la question est pertinente.

Les erreurs fréquentes qui rendent cette objection valable incluent laisser des participants blablater hors sujet, laisser la réunion durer trop longtemps, ou avoir une bande d’individus qui ne sont pas vraiment une équipe. Cette dernière erreur arrive quand « une équipe » est composée d’individus travaillant sur des projets totalement sans rapport.

3. Ne pourrions-nous pas juste le faire par email ?

Certains membres d’équipe ne font pas d’objection au concept d’engager avec leurs coéquipiers quotidiennement, mais au lieu de cela, objectent à en faire une réunion. Ils demanderont souvent d’abandonner le Daily Scrum en faveur d’un email quotidien de chaque personne adressant les mêmes questions habituelles du Daily Scrum.

J’ai rarement vu ceci fonctionner. Le plus grand problème est que la plupart des personnes ne lisent pas les emails. Ou, si elles le font, c’est un jour ou deux plus tard. Cela rend l’équipe moins réactive aux problèmes.

De plus, mener un Daily Scrum par email perd tous les bénéfices de la discussion dans l’instant présent qui devrait faire partie des réunions.

Et avec des outils comme Slack et semblables ? Vous penseriez peut-être que ma réponse serait la même que pour l’email. Cependant, j’ai vu des équipes mener avec succès l’équivalent de réunions Daily Scrum en utilisant Slack.

Je ne sais pas si c’est la nouveauté de tels outils ou quelque chose de fondamentalement différent entre la messagerie instantanée et l’email. Je ne favorise toujours pas de remplacer l’interaction vivante d’un Daily Scrum avec un équivalent Slack pour la majorité des équipes. Mais pour certaines équipes, particulièrement celles qui sont fortement géographiquement distribuées, cela semblent vraiment marcher de manière adéquate.

4. Les réunions durent trop longtemps

Une quatrième et finale objection que vous  entendrez consiste en ce que les réunions durent trop longtemps. Naturellement, vous voudrez prendre cette plainte au sérieux si vos réunions prennent plus longtemps que la norme de quinze minutes prescrites par presque tous les partisans de Scrum.

Mais si vos réunions finissent bien dans la limite des quinze minutes, j’ai constaté que la meilleure réponse à cette plainte est de demander à tout opposant combien de temps il pense serait approprié.

Vous obtiendrez une réponse utile particulièrement si vous incluez quelques-uns des bénéfices de la réunion en posant la question. Par exemple, vous pourriez demander, “Combien de temps pensez-vous serait approprié chaque jour pour nous tenir tous synchronisés, éviter les problèmes de communication, fournir de la visibilité sur ce que fait chacun d’entre nous, identifier et corriger des erreurs, construire la confiance et fournir un sentiment d’accomplissement ?”

CertYou est partenaire de DantotsuPM

7 Attributs d’un Daily Scrum bien mené

Les conseils ci-dessus aideront à surmonter les objections les plus communes que des membres d’équipe peuvent avoir à participer au Daily Scrum. Encore mieux, serait de conduire ces réunions si bien que les membres d’équipe les valorisent. Voici sept attributs d’un Daily Scrum bien mené.

1. Tenez les réunions chaque jour au même horaire et endroit

Vous voulez rendre ces réunions aussi faciles que possible. Pour la plupart des équipes, cela signifient les tenir à la même heure et au même endroit à chaque fois.

2. Débutez la réunion à l’heure

Je suis plus à l’heure que qui que ce soit d’autre. J’ai une fois dû me raisonner d’appeler un docteur quand j’ai réalisé que j’aurais une minute de retard à son cabinet.

Mais je reconnais tout de même qu’arriver quelques minutes en retard à une réunion qui dure toute une journée n’est pas une bien grande affaire. Être cinq minutes en retard à une réunion de huit heures représente 1 % du temps de la rencontre.

Mais être en retard à un Daily Scrum est une affaire beaucoup plus importante. Si les réunions commencent 5 minutes en retard chaque jour, les membres d’équipe qui sont arrivés à l’heure auront perdu plus de 20 heures sur l’année à attendre que la réunion puisse commencer.

3. Respectez la limite de 15 minutes

Il y a une raison pour laquelle beaucoup d’équipes conduisent les Daily Scrum en se tenant debout : Cette position nous aide à rester conscient du temps et facilite les réunions brèves.

4. Identifiez les problèmes mais ne les résolvez pas pendant la réunion

Une bonne pratique commune est de discuter (et avec bon espoir résoudre) des problèmes immédiatement après la réunion. Idéalement cela peut être fait par le sous-ensemble de l’équipe nécessaire pour aborder ces problèmes; les autres membres d’équipe sont alors encouragés à retourner à leurs bureaux.

5. Gardez les participants sur le sujet

La plupart des équipes suivent l’approche d’avoir chaque personne exposer ce qu’ils ont accompli depuis la dernière réunion, ce qu’ils feront avant la réunion suivante et tout problème les ralentissant.

Toute discussion hors de ces sujets devrait être sévèrement limitée.

6. Les règles sont rappelées par l’équipe entière, pas seulement le Scrum Master

Quand le Scrum Master est le seul à imposer les règles de l’équipe lors des réunions, la réunion semble être tenue pour le Scrum Master. Cela ressemble à rapport d’activités où chaque participant fournit le statut seulement au bénéfice du Scrum Master.

7. L’équipe complète et seulement l’équipe participe

Chacun dans l’équipe devrait participer aux Daily Scrum. On devrait permettre à des externes à l’équipe d’observer la réunion. Ils devraient être découragés de contribuer à la discussion pendant la réunion à moins qu’un membre d’équipe ne lui pose une question courte.

Une fois que l’on conclut un Daily Scrum, mais avant que les participants ne se dispersent, beaucoup d’équipes demanderont aux observateurs s’ils ont des questions ou commentaires. Le Scrum Master ou un sous-ensemble de l’équipe peuvent rester et adresser ceux-ci. La clef est que ces commentaires d’observateur restent à l’écart du Daily Scrum.

Quelle est votre expérience ?

Les membres d’équipe peuvent sans aucun doute avoir des objections autres que les quatre les plus communes que j’ai adressées ici. Et il y a certainement des choses complémentaires importantes pour un Daily Scrum bien mené que les sept attributs essentiels que j’ai décrits.

Quelle est votre expérience ? Quelles objections avez-vous entendu et comment les avez-vous surmontées ? Partagez s’il vous plaît vos idées dans les commentaires.

Une équipe Agile ne devrait pas tout finir à chaque itération

On devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.

An Agile Team Shouldn’t Finish Everything Every Iteration

https://www.mountaingoatsoftware.com/blog/an-agile-team-shouldnt-finish-everything-every-iteration par Mike Cohn

Depuis tout jeune, on nous apprend à ne rien laisser dans notre assiette !

Une mesure fréquemment utilisée d’une équipe agile est si les membres d’équipe finissent tout ce qu’ils ont prévu dans l’itération.

Il n’y a rien mal à évaluer si une équipe est capable à la fin de terminer ce qu’elle pensait pouvoir faire. Mais on devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.

Ce serait peu réaliste et cela amènerait les équipes à moins s’engager pour pouvoir tout livrer sans prendre de risque.

Matchware est partenaire de DantotsuPM

Des attentes excessives peuvent entrainer des dysfonctionnements

Considérez une équipe dont le patron (le PDG) leur a dit que s’il leur arrivait d’échouer à tout finir, il “prendrait des actions correctives, jusqu’à et incluant probablement l’arrêt brutal du projet.”

Cette équipe ne va pas aller chercher une masse excessive de travail dans ses itérations. Les membres essayeront d’en choisir suffisamment pour ne pas être traités de paresseux, mais pas trop pour ne pas risquer de ne pas tout faire.

CertYou est partenaire de DantotsuPM

Une cible appropriée

Je trouve qu’un bon objectif pour une équipe est de finir tout ce qu’ils disent qu’ils feront environ 80% du temps. C’est un bon degré de prévisibilité pour le business sans être impossible à tenir par les équipes.

Pour être vraiment clair, une bonne équipe agile devrait finir 100% de ce qu’elle prévoit dans 8 itérations sur 10. Je ne dis pas qu’une équipe devrait finir 80% de son travail prévu à chaque itération. C’est très différent.

quelle est la cible à atteindre?
80% du temps dans la cible est déjà très bien.

Tout faire à chaque fois sera impossible pour des équipes fréquemment interrompues. Si une partie significative du travail de votre équipe est de répondre rapidement aux problèmes, vous pouvez vouloir vous donner une cible de pourcentage inférieur.

Ne le planifiez pas si vous ne pensez pas que vous le réaliserez

En essayant de finir 100% de son travail, 80% du temps, l’équipe devrait ressentir qu’ils vont réussir tout en comprenant, avec réalisme, qu’ils ne le feront pas à chaque fois.

J’aime y penser comme analogue au basketteur lançant le ballon. Le joueur ne devrait pas lancer le ballon à moins qu’il ne pense qu’il marquera le panier. Mais, même le meilleur basketteur comprend que tous ses lancers ne peuvent entrer dans le panier.

Un bon basketteur peut réussir 40 à 50% de ses lancers. Ce n’est pas suffisamment de prévisibilité pour la plupart des équipes, voici pourquoi je recommande de viser les 80%.

Quelle est votre expérience ?

Où en est votre équipe sur compléter ce qu’elle a dit qu’elle ferait ? Partagez s’il vous plaît vos idées dans les commentaires ci-dessous.

 

Le cône d’incertitude peut changer votre manière de parler et de présenter vos estimations de projet

Le cône d’incertitude est la forme géométrique que donne la représentation graphique de l’exactitude des estimations par rapport à l’avancement du projet.

Il incarne l’idée que les estimations faites au début d’un projet seront limitées dans leur exactitude et quand vous travaillez à réduire l’incertitude dans le projet, les estimations peuvent devenir plus précises au fil du projet. Au cours du projet, le concept, les exigences et la conception vont s’étoffer pour donner une bien meilleure idée de la faisabilité, des délais et des coûts du projet.

En observant le cône d’incertitude, vous pouvez aisément comprendre et montrer à vos clients pourquoi vos estimations initiales de projet ne seront pas exactes, et comment vous pouvez les améliorer avec eux.

Vous pouvez également utiliser le cône d’incertitude pour donner un pourcentage estimé de leur exactitude en fonction du temps et défendre vos estimations si elles sont remises en question à une date ultérieure.

En donnant une limite inférieure et supérieure à votre estimation, vous pouvez clairement communiquer l’incertitude inhérente à l’estimation. Si la personne qui reçoit l’estimation n’est pas satisfaite de la précision de la fourchette donnée, vous pouvez utiliser cela pour demander davantage de temps ou de ressources pour éliminer une partie de l’ambiguïté et fournir une fourchette d’estimations plus resserrée.

Matchware est partenaire de DantotsuPM

Selon ma propre expérience Agile/Scrum, quand l’histoire utilisateur, la User Story, devient éligible à entrer dans une session de sprint planning c’est qu’on l’a déjà suffisamment analysée pour pouvoir donner une estimation relativement fiable. Nous nous trouvons entre les exigences détaillées et le design détaillé du cône d’incertitude.

CertYou est partenaire de DantotsuPM

La planification Agile est différente et tout à fait primordiale.

Quelques astuces de planification tirées de la pratique des approches Agile dans la vraie vie.

Planning top tips

https://agilechangemanagement.co.uk/2019/10/23/planning-top-tips/ par Melanie Franklin

Les projets agiles sont basés sur le concept que livrer une solution imparfaite au business le jour promis est plus important que livrer une solution parfaite en retard.

Avec Agile, tenir vos promesses sur quand quelque chose sera disponible pour être utilisé en production est au cœur de la réalisation de bénéfices. Chaque élément fourni, même s’il a un nombre minimal de fonctionnalités peut résoudre un problème métier. Focalisez votre équipe sur faire utiliser leur livrable en production, en sachant qu’ils pourront ajouter davantage de fonctionnalités plus tard.

Il y a une fausse idée répandue qui est que ceux travaillant dans des équipes Agiles ne planifient rien.

Alors que les compétences de planification y sont plus importantes que dans l’approche prédictive « en cascade » (PRINCE2 ®) pour les projets parce que :

  • La planification est plus fréquente
  • La planification est faite en collaboration, impliquant chacun qui contribue au projet
  • Les plans y sont un mécanisme essentiel de suivi du progrès
QRP est partenaire de DantotsuPM
aux fausses croyances sur Agile

Pour ces raisons, les compétences de planification sont critiques au travail Agile efficace. La planification détaillée du projet de bout en bout au début ne fait pas partie Agile. Au lieu de cela, il y a la planification fréquente et la re-planification pendant tout le cycle de vie du projet. Quand un élément de la solution est livré au business, le focus se porte sur la planification de la livraison suivante.

Objectifs de la planification

Pour respecter l’importance de planification, j’encourage mes équipes à se mettre d’accord sur un jeu commun d’objectifs pour leurs sessions de planification.

Utilisez ceux-ci pour débuter avec votre équipe :

  • Assurons-nous que nous livrons une solution utilisable et de valeur
  • Assurons-nous que nous n’avons rien oublié
  • Donnons la priorité au travail le plus important en premier
  • Allouons le travail aux meilleurs de l’équipe pour le faire
  • Clarifions l’ordre/le séquencement pour réaliser des économies d’efforts
  • Créons un visuel qui permette aux autres de voir ce que nous faisons et quand afin qu’ils puissent aligner leur travail avec le nôtre
  • Utilisons ce visuel pour fournir un suivi facile de notre progression sans devoir écrire de rapport d’avancement
CertYou est partenaire de DantotsuPM

Ordre du jour de la planification

Supportez ces objectifs en définissant comment va se dérouler chaque session de planification.

J’encourage mes équipes à utiliser un ordre du jour standard pour tous les événements de planification.

Utilisez cet ordre du jour type pour encourager votre équipe à faire de même :

  • Examiner les résultats de notre session de brainstorming préparatoire.
  • Appliquer les critères de priorisation pour créer une liste agréée de travail pour ce sprint
  • Définir ensemble qui va construire et qui va tester le résultat.
  • Chaque personne crée son propre échéancier pour le sprint en s’assurant que les must have  ne dépasse pas les 60 % du travail.
  • Chacun effectue un contrôle croisé de son échéancier avec la personne testant son travail.
  • Réserver le temps nécessaire dans son agenda pour réaliser le travail
  • Se mettre d’accord sur comment vous partagerez le progrès avec l’autre
Matchware est partenaire de DantotsuPM

Pour plus d’astuces sur l’application des pratiques de travail Agile dans la vraie vie, abonnez-vous au bulletin de Melanie ou visitez son site Web.

Remplir le réservoir à ras bord pour affirmer sa supériorité sur les automates ou pour avoir un sentiment de contrôle ?

Remplir le réservoir à ras bord

Topping off the tank

https://seths.blog/2018/12/topping-off-the-tank/ par Seth Godin

Comme l’ère du carburant fossile approche de sa fin, les pompistes (le peu qu’il en reste, ainsi que les pompistes bénévoles qui remplissent eux-mêmes leurs propres réservoirs) persistent à vouloir remplir le réservoir à ras bord.

Après que le déclencheur automatique ait détecté que le réservoir est plein, ils ajoutent dix ou vingt centimes de plus de carburant pour atteindre un chiffre rond.

Pourquoi ?

Ce n’est pas plus rapide. Cela demande du temps pour le faire manuellement.

Ce n’est pas plus profitable. Dix centimes supplémentaires sur un réservoir de 60€ ne justifient pas le temps.

Ce n’est pas plus efficace. Le nombre de kilomètres de plus d’ici au prochain plein est minuscule.

Ce n’est même pas plus facile. La plupart des personnes paient avec une carte de crédit, donc l’arrondi n’aide en rien.

Et…

Cela risque plus probablement d’endommager le véhicule (l’essence sur la carrosserie) et d’endommager la santé du pompiste (avec les vapeurs).

Alors, pourquoi le font-ils ?

Trois raisons

  1. Tradition.
  2. Montrer au chef et au client que vous bossez dur.
  3. Une apparence de contrôle.
Trop déléguer nous fait ressembler à des automates.

C’est la troisième qui est la vraie. Les gens échangent d’énormes quantités de décisions en échange de convenance personnelle, mais pas trop de décisions.

Trop déléguer nous fait ressembler à des automates. Même (ou particulièrement) en travaillant sur des automobiles qui sont des symboles de liberté et de contrôle.

Quelles autres choses cherchons-nous à remplir à ras bord ?


Dans le monde du management de projet, n’en va-t-il pas de même ?

N’essayons-nous pas trop souvent de surcharger le contenu de nos livrables de bien plus de fonctionnalités qu’il n’est raisonnable d’en embarquer ?

Ce n’est pas plus rapide. Cela demande plus de temps pour produire la version de notre livrable qui réponde à tous ces besoins dont certains sont probablement moins critiques que d’autres.

Ce n’est pas plus profitable. Comme nous le constatons avec les méthodes Agiles de type Scrum, il vaut mieux limiter le contenu à la durée et à la capacité de production pour obtenir rapidement un produit qui apporte déjà des bénéfices.

Ce n’est pas plus efficace. Produire et tester un livrable beaucoup plus complexe coûte plus de temps et de moyens que plusieurs plus simples.

Ce n’est même pas plus facile. Le suivi des développements et des tests, ou la formation des futurs utilisateurs sont bien plus compliqués.

Et…

Cela risque plus probablement d’endommager le produit (le surplus de fonctionnalités pas toujours critiques ralentit l’adoption par les utilisateurs et accroit les risques de dérapage des délais) et d’endommager la santé des membres de l’équipe projet (en surchargeant leurs plannings et leur mental de choses non critiques).

CertYou est partenaire de DantotsuPM

Alors, pourquoi le faisons-nous encore très fréquemment ?

Une vidéo avec une grande affiche gratuite pour bien expliquer les principes fondamentaux de Scrum à votre client et organisation

Vous souhaitez recevoir une aide visuelle mais aussi le bon discours pour interpréter le guide Scrum?

https://www.scrum.org/resources/blog/scrum-poster-visual-guideaid

Demandez votre copie gratuite de ce très sympathique et complet poster Scrum et montrez-le à vos collègues et amis.

Cette affiche peut être un outil d’apprentissage (par exemple lors de la lecture du guide Scrum) et un outil permettant à un ScrumMaster d’expliquer Scrum à l’organisation, au responsable produit ou à l’équipe de développement.

https://www.incrementor.com/agile-poster-series

Une seule demande par personne est acceptée. Expédition aux États-Unis et en Europe uniquement. Vous serez informés par e-mail une fois le poster expédié.

Et voici la bande son en anglais dans cette vidéo

CertYou est partenaire de DantotsuPM

Biais Cognitifs : Effet IKEA et aversion à la dépossession

Nous plaçons une valeur disproportionnée dans les choses que nous avons créés (ou pour lesquelles nous avons travaillés dur) ! Puis, poursuivons avec notre peur de les perdre une fois que nous les possédons.

Effet IKEA

Nous plaçons une valeur disproportionnée dans les choses que nous avons créés (ou pour lesquelles nous avons travaillés dur). Des créations amateuristes peuvent ainsi paraitre aussi parfaites que celles d’experts à cause de notre investissement personnel dans leur réalisation.

En quoi suis-je concerné dans mes projets ?

Le bureau de projet ou PMO doit être particulièrement attentif à ce biais. Il s’exprime souvent dans les cas d’affaires surtout si ceux-ci sont présentés par des personnes qui ont énormément investi dans le projet, ce qui est quasiment toujours le cas. Leurs avis sont forcément biaisés car ils ont transpiré et se sont démenés pour préparer un business case qui tienne la route.

Comment éviter le plus possible l’effet IKEA ?

Il peut être intéressant de demander à ce que le cas d’affaire soit présenté par une personne un peu moins directement investie dans sa construction comme le sponsor ou le manager de projet, ou bien par plusieurs membres de l’équipe qui l’a construit pour avoir des ressentis différents sur le projet.

Peut-il vous être utile ?

Énormément ! Laissez les futurs utilisateurs de votre produit en construire une partie même minime. Par exemple contribuer au développement du processus de formation des utilisateurs et aux métriques d’adoption du nouveau livrable. Ainsi ils peuvent devenir parties prenantes actives du projet, produit et livrables, se les approprier et les défendre par la suite. Leur investissement personnel va décupler leur perception de la valeur du produit.

Aversion à la dépossession ou à la perte

Une fois que nous possédons quelque chose, nous la valorisation davantage que nous le faisions avant de la posséder.

En conséquence, nous allons plus probablement conserver un objet que nous possédons qu’acquérir ce même objet si nous ne le possédons pas encore.

Nous allons le protéger envers et contre tout.

En quoi suis-je concerné dans mes projets ?

démonstrationUn livrable qui arrive en bout de chaine sans appropriation au préalable des utilisateurs a moins de chance d’être apprécié et adopté. Les approches Agiles permettent souvent de palier à cet inconvénient majeur des approches prédictives (cycle en V) car elles permettent aux utilisateurs finaux de toucher du doigt les livrables bien avant qu’ils ne soient finalisés. En effet, à chaque revue de livrables en bout de Sprint, des démonstrations aux commanditaires et parfois aux utilisateurs finaux sont de formidables opportunités. Elles permettent de juger de la pertinence du produit et de récolter des remarques mais aussi de réaliser une première appropriation du produit par celles et ceux qui vont plus tard en bénéficier.

CertYou est partenaire de DantotsuPM

Comment éviter le plus possible cette aversion ?

C’est justement en offrant la possibilité aux utilisateurs de commencer rapidement à posséder une partie du produit même infime qu’ils se l’approprient et le valorisent. Une fois que les utilisateurs accèdent à un livrable et commencent à y investir de leur temps (par exemple en construisant leur profil utilisateur), il est plus difficile pour eux de laisser tomber et de ne pas franchir les étapes suivantes d’utilisation opérationnelle quand le produit final est livré.

Cette aversion à la dépossession peut-elle vous être utile ?

Que sommes-nous réellement prêts à risquer de perdre ?

Si un client ou un utilisateur menace de vous quitter, fournissez les exemples de toutes les bonnes choses qu’il a déjà pu expérimenter avec votre projet ou produit et qu’il va perdre. Nous sommes toutes et tous bien plus conservateurs que nous ne le pensons.

Nous sommes très souvent profondément conservateurs.

Nous disons que nous sommes innovateurs, nous aimons essayer de nouvelles technologies mais, quand nos instincts fondamentaux et notre processus de décision rapide se mettent en route, nous aspirons à réduire au minimum les risques et inconvénients avec les choses auxquelles nous sommes déjà familiers.

Biais Cognitifs – Les apparences sont primordiales : Valeur perçue, supériorité des images, effet Von Restorff

3 Biais Cognitifs  de plus cette semaine : Valeur perçue, supériorité des images et effet Von Restorff

1 – Biais de Valeur Perçue

cadeauxNous percevons la valeur d’un produit ou d’un service en fonction de son apparence et de comment il est servi ou livré. Tout est dans l’emballage !

En quoi suis-je concerné dans mes projets ?

Le design et l’interface utilisateur sont beaucoup plus importants qu’il n’y parait. En fait, ils sont même souvent plus critiques à la réussite que la richesse de fonctionnalités de votre produit. Construire un produit complet et de valeur pour le business de votre client est inutile si le produit n’est pas utilisé parce que jugé trop complexe, peu attirant, de mauvaise ergonomie ou peu pratique.

Comment éviter le plus possible ce travers ?

Toutes les activités autour du design centré sur les utilisateurs et leurs futurs usages du produit sont à valoriser dans vos projets. Le parcours utilisateur doit être soigné de même que les documents servant à présenter le produit, les maquettes, les démonstrations de fin de sprint en approche Agile comme Scrum, la facilité de mise en service, le support à l’installation et au démarrage…

CertYou est partenaire de DantotsuPM

Ce biais peut-il vous être utile ?

La maquette de votre interface utilisateur doit donner envie de voir le produit fini.

Une belle maquette votre futur livrable avec un design soigné, un choix de couleurs et de présentation soignés, va déjà faire beaucoup pour donner envie à l’utilisateur de posséder votre produit. Même si au départ les fonctionnalités sont très limitées, la qualité visuelle de celles qui sont présentées doit être irréprochable. Une maquette ou un prototype n’est pas un brouillon réalisé à la va vite sur un coin de table.

2 – Effet de Supériorité des images

Ma référence pour préparer des présentations mémorables (sur Amazon)

Les images et photos, films ou autres supports visuellement riches vont davantage marquer les esprits que de grandes déclarations et documents textuels. Cet effet a été démontré dans de nombreuses expériences et avec différentes méthodes. Il se base sur la notion que la mémoire humaine est plus sensible à la symbolique de présentation des informations qu’aux détails de celles-ci.

En quoi suis-je concerné dans mes projets ?

Le métier du management de projet est à 80% centré sur la communication. Même si la plus forte partie de la communication n’est ni écrite ni verbale mais plutôt gestuelle et relationnelle, il y a de grandes chances que les écrits sur le projet soient regardés par un grand nombre de personnes. Certaines seront familières du projet, d’autres plus éloignées survoleront votre document et les images capteront bien plus leur attention que les longs laïus.

Comment éviter le plus possible cet effet ?

Donc, tout document de projet, présentation au comité de projet, description de livrable, état d’avancement, doit être soigné au niveau visuel et le plus possible illustré d’images pertinentes pour donner un aspect à la fois professionnel et positif du projet. Incluez toujours des images dans votre contenu.

La supériorité des images peut-elle vous être utile ?

En choisissant de bons visuels, vous donnez déjà un sentiment positif au lecteur.

Et vous lui donnez aussi envie d’en savoir davantage voire de participer à votre projet quels que soient la qualité et les bienfaits de votre produit final.

Ce désir, ces attentes, ces espoirs, ces rêves vont motiver vos partie prenantes.

3. Effet Von Restorff (Effet d’Isolement)

L’effet Von Restorff, nommé d’après la psychiatre Hedwig von Restorff, ou effet d’isolation, dit qu’un objet qui se détache des autres est plus susceptible d’être retenu. Cet objet suscite ainsi un biais cognitif qui est de percevoir instantanément et sans réfléchir ce qui est inhabituel, distinctif. Quand des objets homogènes multiples sont présentés ensemble, l’objet qui diffère du reste sort du lot et l’on va plus probablement s’en rappeler.

En quoi suis-je concerné dans mes projets ?

L’homogénéité est intéressante mais pas la monotonie.

Si toute votre présentation du projet est sur la même tonalité, dans la même police de caractère, dans le même format, que pensez-vous que votre audience va retenir ? En fait, pas grand-chose car rien de saillant auquel se raccrocher ne facilite la mémorisation.

Comment éviter le plus possible ce travers ?

reconstructionLors de présentations, utiliser des images comme vu plus haut, des polices de caractères et effets ou couleurs différentes. Dans une interface utilisateur si votre projet livre une application, mettez le bouton principal sur lequel vous voulez que les utilisateurs appuient dans une couleur et taille distinctives, faites appel à des ergonomes pour améliorer vos design, utilisez des panels de futurs utilisateurs pour avoir leurs retours sur leur usage de votre produit en cours de construction et ajustez vos livrables en conséquence.

Ce biais peut-il vous être utile ?

Sans devenir machiavélique, apprenez dans vos présentations à mettre visuellement en emphase les sujets dont vous voulez parler et que vous souhaitez que les gens retiennent.

Biais Cognitifs – Supériorité illusoire et effet Dunning-Kruger

Nous faisons souvent preuve d’une incapacité à reconnaître notre manque de capacité à reconnaître notre incapacité !

Nous sommes incapables de reconnaître notre manque de capacité.

Supériorité Illusoire: Illusion de savoir, parallèle ou extrapolation un peu trop rapide avec des expériences précédentes, avec d’autres secteurs, d’autres projets…

Nous sommes tout aussi incapables de reconnaitre nos réelles capacités !

Dunning Kruger effect : Les moins compétents dans un domaine ont souvent tendance à se surestimer. Leur incompétence les empêche de se rendre compte de ce qu’ils ne savent pas ni qu’ils prennent une mauvaise décision. Alors qu’à l’opposé du spectre, les plus compétents sous estiment leurs compétences car ils sont conscients de tout ce qu’ils ne savent pas mais réalisent moins de tout ce qu’ils savent.

En quoi suis-je concerné par ceci dans mes projets ?

changement planningPour le chef de projet, ce biais de supériorité illusoire se manifeste tout particulièrement lors de l’élaboration des estimations d’efforts pour la planification les tâches du projet.

D’autre part, pendant le projet, vous allez rencontrer certains sponsors et experts qui ont déjà beaucoup d’expérience. Utilisez leur expertise tout en restant circonspect car ils et elles risquent fort de faire des comparaisons ou extrapolations quelque peu hasardeuses.

FDF est partenaire de DantotsuPM

Comment l’éviter le plus possible ?

Quand vous rejoignez un nouveau projet, une nouvelle équipe, une nouvelle société, ou un nouveau domaine, rappelez-vous qu’il y a beaucoup de choses vous ne savez pas et beaucoup de choses que vous ne savez même pas que vous ne savez pas

silenceCommencez par faire profil bas. Familiarisez-vous  avec les personnes impliquées et les spécificités des sujets à traiter. Parlez moins et observez davantage. Adoptez une attitude discrète jusqu’à ce que vous ne soyez plus un novice.

Diverses techniques peuvent être utilisées pour réduire ce risque lors de l’estimation d’effort du projet comme Monte-Carlo analysis. Ou bien, si le sujet est peu mature ou volatile, une approche basée sur Agile avec des itérations de développement brèves sur les sujets maitrisés et porteurs du plus de valeur va aider avec le planning poker par exemple. En confrontant les estimations les plus faibles avec les plus fortes, vous en découvrez davantage sur le travail à réaliser et qui saurait le faire.

CertYou est partenaire de DantotsuPM

Peut-il vous être utile ?

Les manifestations de ce biais naturel dans l’équipe peuvent vous aider à déceler les réels experts d’un sujet ou domaine sur lesquels vous appuyer pour  limiter les risques de dérapage.

pour en apprendre davantage sur Disciplined Agile Delivery (#dad) !

Cette brève vidéo donne un aperçu du cycle de vie agile de base avec Disciplined Agile Delivery qui est l’application la plus courante de DA.

Relisez le billet « Voici pourquoi le PMI a acquis DA« 

CertYou est partenaire de DantotsuPM

 

Commençons bien l’année, faisons un peu de ménage dans notre « product backlog » !

Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…

Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.

Qu’en pensez-vous et comment traitez-vous ce problème ?

Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?

Est-ce périodiquement lors de grands « ménages » saisonniers ?

Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?

CertYou est partenaire de DantotsuPM

1,2,3… Professional Scrum Product Owner / PSPO

1,2,3… Scrum.org ajoute un nouveau niveau de test d’évaluation de certification de propriétaire de produit Scrum professionnel : Professional Scrum Product Owner

 

PMGS est partenaire de DantotsuPM

La semaine dernière, Scrum.org a annoncé des changements aux évaluations de certification PSPO.

Une nouvelle évaluation de PSPO II et des modifications sur le PSPO II actuel pour qu’elle devienne PSPO III.

Cela complète la famille d’évaluations et de certifications du PSPO en ajoutant un niveau distinguished en plus des niveaux fondamentaux et avancés fournis par le PSPO I et le PSPO II.

En restructurant ses évaluations et certifications Professional Scrum Product Owner (PSPO), et en ajoutant un niveau supplémentaire, Scrum.org permet aux professionnels de démontrer leur compréhension, leur connaissance et leur pratique du rôle du propriétaire de produit Product Owner avec Scrum.

Ces certifications attestent de leur capacité à maximiser la valeur offerte par le produit.

Pour en savoir davantage (en Anglais)

CertYou est partenaire de DantotsuPM

Les billets DantotsuPM.com les plus lus à la rentrée 2019

Comment éviter de stresser tout en utilisant les avantages de l’agilité, telle était la ligne directrice de Septembre.

Déstressez votre équipe projet ainsi que vous-même : 8 choses simples à faire

Ne soyez pas un manager de projet passif face au stress des membres du projet et de ses parties prenantes.

Il y a des actions de prévention simples que vous pouvez initier et mettre en œuvre pour contrer les facteurs de stress.

FDF est partenaire de DantotsuPM

Déstressez votre équipe projet : Clarifiez les rôles et responsabilités de chacun

Ne pas savoir ce qui est attendu de nous est stressant. Ceci est d’autant plus vrai que nous évoluons de plus en plus souvent dans des équipes transverses et multi disciplinaires. Il n’est pas rare que les membres de l’équipe projet aient peu d’occasions de se rencontrer en face à face pour faire connaissance. Voici une source de stress que la ou le manager de projet peut attaquer de front.

CSP est partenaire de DantotsuPM

Comment vous protéger d’énergies négatives en 6 façons puissantes ?

Il n’est jamais facile d’être confronté au négativisme. Mais en plus, cela peut être carrément toxique et nuisible, favorisant une mentalité de cynisme, de fatalisme et même de défaitisme.

Si vous êtes entourés d’énergie négative qui provienne d’un collègue, associé, ami, ou membre de votre famille, vous devez apprendre à vous protéger et à ne pas vous y laisser emporter.

Voici six stratégies que vous pouvez utiliser pour vous protéger !

Comment garder les pieds sur terre en ces  temps agités : 12 habitudes simples et réalisables à tester et adopter ?

Commencez dès aujourd’hui à développer les habitudes et les stratégies qui vous maintiendront bien campé sur vos deux pieds quand  tout autour de vous chavire. Nous travaillons tous toujours plus longtemps et stressons davantage, plus occupés que jamais. Mais il est vraiment possible de manager tout ce qui arrive, de rester les deux pieds sur terre même quand tout autour de nous semble échapper à tout contrôle.

CertYou est partenaire de DantotsuPM

MVE et MVP et MMF : Quelle est la différence ?

Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !

Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.

Vous avez toujours voulu savoir ce qu’est et n’est pas un Scrum Master, voici une vidéo faite pour vous.

Avec l’essor massif de l’Agilité dans les organisations et plus particulièrement de la méthode Scrum, un nouveau rôle est apparu : Scrum Master.

Et avec ce rôle de nombreuses questions:

  • Peut-il développer ?
  • Est-il chef de projet ?
  • Est-il le responsable des développeurs ?
  • Comment s’interface-t-il avec les utilisateurs et le Product Owner ?
  • Quelles sont ses missions ?

Cette vidéo devrait vous permettre de faire le tri entre les mythes et les réalités qui entourent ce rôle.

En bonus vous repartez avec quelques outils bien pratiques dans votre rôle quotidien de Scrum Master si vous l’êtes et vous comprendrez mieux ce rôle si vous ne l’êtes pas !

CertYou est partenaire de DantotsuPM

 

Biais Cognitifs – Le biais de confirmation est omniprésent

Nous recherchons et privilégions toute information qui confirme notre à priori initial ou hypothèse.


Le biais de confirmation consiste à ne pas voir ni chercher d’arguments qui vont à l’encontre de nos croyances ou de nos hypothèses, mais à se focaliser sur ceux qui confirment ce que l’on pense déjà ou ce que l’on cherche à prouver.

Nous cherchons à cocher rapidement une case toute prête dans notre cerveau…

Par exemple, pour s’informer sur un sujet controversé au sein de l’équipe, le/la manager de projet pourra préférer aller voir des personnes ou sources d’information qui confirment ou affirment son point de vue. Toutes les preuves ambigües risqueront fort d’être interprétées en faveur de sa position actuelle. Des extrapolations, même questionnables, avec d’autres projets « similaires » seront considérées comme des faits…

Une expérience appelée « tâche de sélection de Wason » met en évidence ce biais. Le sujet y cherche des éléments de confirmation qu’une règle est vraie alors qu’il vaudrait bien mieux pour lui vérifier qu’il n’existe pas d’éléments prouvant que la règle est erronée !

Attention, ce biais peut venir tromper votre jugement en de nombreuses et très différentes occasions.

Posez-vous davantage de questions sur vos propres réactions.

Vous êtes-vous jamais senti si proche d’un candidat pendant un entretien d’embauche  que vous avez ignoré certains signaux faibles qui auraient dû vous alarmer ?

Avez-vous jamais minimisé un risque parce que vous l’aviez déjà traité avec succès sur un projet précédent ?

Avez-vous rayé de votre esprit une remarque d’un testeur parce qu’elle causerait une refonte de votre approche ou des délais supplémentaires ?

Comment l’éviter le plus possible ?

  1. Pourquoi votre idée pourrait-elle être mauvaise ?

    Adoptez l’attitude de l’avocat du diable en recherchant les conséquences que vous observeriez si votre hypothèse et votre ressenti étaient erronés.

  2. Apprenez à reconnaitre votre incompétence dans certains domaines et faites confiance aux experts et sachants.
  3. Identifiez puis questionnez vos propres a priori pour éviter de poser des questions dirigées dont les réponses ne sauraient que vous conforter dans votre idée.

De plus, son corolaire est tout aussi dangereux !

On ne peut sortir de l’ignorance sans tout considérer.

Son corolaire que nous pourrions appeler le biais de dé-confirmation ou d’ignorance volontaire est tout aussi dangereux. Nous avons tendance à écarter inconsciemment la preuve qui réfute nos croyances. Ainsi, il arrive souvent que certaines croyances persistent alors que leurs preuves initiales ont été éliminées et que l’on nous a prouvé par A+B qu’elles étaient fausses. Il peut arriver que nous n’ayons pas envie de reconnaitre nos erreurs et persistions dans celles-ci malgré tous les signaux d’alerte que nous recevons…

FDF est partenaire de DantotsuPM

Peut-il vous être utile ?

Bien sûr ! Dans le contexte du management de projets, le biais de confirmation peut par exemple se manifester par un soutien d’approches ou priorités sans preuves suffisantes. Donc, mieux vaut le détecter et le contrer rapidement.

Par exemple, en Agile le Product Owner représente les clients (ou en waterfall la maitrise d’ouvrage) mais dans quelle mesure son avis et expérience personnels ne masquent-il pas les besoins des vrais futurs utilisateurs de votre solution ? Mettre en place des panels utilisateurs en complément et en soutien au product owner est souvent bénéfique. D’ailleurs les plus expérimentés vont le réclamer d’eux-mêmes.

Dotez-vous d’un important panel d’utilisateurs.

Autre cas : De premiers tests utilisateurs mettent à risque le passage d’un prochain jalon et entrent en conflit avec les attentes de votre sponsor de projet. Ne les rejetez pas trop vite en les classifiant comme non fiables ou peu significatifs ou « mineurs ». Prenez le temps de bien en comprendre la teneur et la portée. Rien ne sert de sortir un produit dans les temps qui ne répond pas aux attentes.

Qui veut d’une solution inutile ou inutilisable ?

Pour combattre cette tendance, la formation scientifique enseigne des moyens d’éviter ou limiter ce biais.

La conception de protocoles comme les plans de tests implique la préparation à l’avance des critères d’acceptation et de rejet des livrables de votre projet qu’il vous faudra respecter.

Se confronter le plus tôt possible au jugement de ses clients

Ainsi, la cérémonie de démonstration de Scrum permet d’atténuer l’effet des préjugés individuels de toute l’équipe projet, en la confrontant directement aux retours des utilisateurs clients.

CertYou est partenaire de DantotsuPM

Déstressez votre équipe projet : Donnez davantage de prévisibilité

Septième item stressant pour l’équipe projet (et les parties prenantes) : Ne pas savoir ce qui l’attend.

Relisez le billet d’introduction.

La peur de l’échec est humaine, surtout sur des projets qui présentent toujours des choses qui n’ont jamais été réalisées auparavant.

Saurais-je faire ? Aurais-je assez de temps ? Quelle est ma latitude décisionnelle ?

Autant de questions stressantes que certains membres de l’équipe ne manqueront pas de se poser.

Le manager de projet est celui vers lequel les regards se tournent naturellement pour trouver des réponses. En sa qualité de planificateur et de par sa vision transverse de tous les éléments, il lui incombe d’anticiper pour niveler les besoins en ressources à un niveau supportable par l’équipe projet dans le court comme dans le moyen terme.

En donnant de la visibilité sur la charge de travail actuelle et à venir, il peut réduire considérablement cette source d’anxiété.

De plus, les approches Agile comme l’estimation et l’allocation des tâches par les personnes qui devront les réaliser (« Scrum Poker » et Scrum Planning) permettent aux équipes de mieux comprendre ce qui est attendu et les efforts nécessaires. Ils vont aussi mieux s’approprier les travaux à accomplir pour réaliser les livrables du projet.

CertYou est partenaire de DantotsuPM

Guide Kanban pour les équipes Scrum par Scrum.org

Un tout nouveau guide disponible gratuitement et traduit en français.

 

à télécharger en ligne

L’approche Kanban, orientée flux, peut améliorer et compléter le cadre de travail (Framework) Scrum ainsi que sa mise en œuvre. Les équipes peuvent ajouter des pratiques Kanban complémentaires, qu’elles débutent avec Scrum ou l’utilisent déjà.

Le Guide Kanban pour les équipes Scrum est le résultat d’une collaboration entre des membres de la communauté Scrum.org et des leaders de la communauté Kanban.

Ensemble, ils supportent Le Guide Kanban pour les équipes Scrum. Ils partagent la conviction que les professionnels du développement de produits peuvent bénéficier de l’application de Kanban couplée à celle de Scrum.

CertYou est partenaire de DantotsuPM

Déstressez votre équipe projet : Mettez les moyens en adéquation avec les besoins et inversement !

Cinquième item très stressant pour tout membre de l’équipe projet : Ne pas avoir les moyens de répondre aux attentes, ambition et objectifs du projet.

Relisez le billet d’introduction qui présente cette brève série de billets sur ce sujet.

Personne n’aime faire un mauvais travail.

Aussi, on préfèrera souvent prendre sur soi, s’investir plus que de raison, voire s’épuiser, à ne pas parvenir à accomplir nos tâches projet comme opérationnelles.

De plus, dans nombre de projets, les personnes ne soient pas dédiées à 100% au projet. Ceci n’est pas nécessairement nuisible et peut même être bénéfique car le projet va se nourrir de l’opérationnel et vice versa. Le travail de la personne sur le projet facilitera le déploiement du changement qu’elle va introduire dans les organisations cibles. Le problème est celui de la charge globale de travail pour ces membres de l’équipe. Et ceci est amplifié par la distance qui gomme certains des ressentis que l’on peut avoir en rencontrant la personne en face à face.

CSP est partenaire de DantotsuPM
Relisez ce billet sur comment éviter de se voir imposer des dates irréalistes.

En sus de l’optimisation de la charge de travail, il est aussi du devoir du manager de projet de protéger ses équipes de dates irréalistes qui seraient poussées par le management sans avoir été validées au préalable. Ou encore d’accroissements intempestifs et non contrôlés de périmètre du projet sous le prétexte : « on est Agiles ou pas ? ».

Cela arrive hélas bien plus souvent qu’on ne le souhaite…

Il convient alors de négocier sur le contenu (mettre les objectifs/besoins/délais en concordance avec les moyens). Il faudra en particulier être très clair sur ce que l’on ne pourra pas faire si une date est imposée qui ne permette plus de livrer le produit dans son intégralité.

Produit Viable Minimum (MVP)

Les approches Agile par MVP comme Scrum sont particulièrement utiles pour prioriser le contenu des livrables en fonction des délais et ressources disponibles.

CertYou est partenaire de DantotsuPM