Agile mène à l’honnêteté !

L’honnêteté se réfère à être honnête sur combien nous pouvons achever dans les délais impartis.

Https://agilechangemanagement.co.uk/2019/05/15/agile-leads-to-honesty/ par Melanie Franklin

J’aide une organisation à passer d’un management de projet prédictif Waterfall à Agile. Cela a mené à bien des discussions sur les bénéfices de Agile. En sus des bénéfices évidents de réponse plus rapide à des circonstances changeantes, la participation continue du client/business et un retour sur investissement accéléré, je veux ajouter l’honnêteté.

L’honnêteté se réfère à être honnête sur combien nous pouvons compléter dans les délais alloués. Je sais que ceux qui s’opposent à Agile se plaignent qu’il n’y ait aucune planification ou rapport mais ce n’est pas vrai et la planification qui est faite dans Agile nous donne une visibilité beaucoup plus claire de ce qui est créé, souvent à un niveau très granulaire. Cela fournit l’honnêteté sur ce que le business peut attendre suite au projet et donc l’honnêteté sur les bénéfices probables qui seront réalisés.

FDF est partenaire de DantotsuPM

Honnêteté du planning

La planification est centrée sur la production ou l’accomplissement, plus basée sur les activités. Cela mène à une honnêteté inhérente sur ce qui est créé, depuis les exigences au niveau epics aux user stories (histoires d’utilisateur) individuelles et exigences plus détaillées ensuite jusqu’aux activités spécifiques nécessaires pour livrer ces exigences.

Les équipes utilisent des techniques pour décomposer chaque livrable à réaliser en activités spécifiques, ce qui leur permet de vérifier entre elles qu’elles ont les ressources, compétences et information facilement accessibles pour leur permettre de produire le livrable. De nouveau, il y a de l’honnêteté pour savoir si vraiment tout le nécessaire est en place pour faire le travail.

Honnêteté du développement

Ce niveau granulaire de détail mène à une compréhension beaucoup plus claire du temps exigé pour développer chaque composant. Pour des produits petits, spécifiques, le temps dont on a besoin pour aller du projet initial à la revue, corriger et finir le produit peut être calculé.

Ceci est imposé par le travail en sprints souvent de seulement quelques semaines de durée. L’heureux effet collatéral de ces “décompositions de produit” est la clarté de savoir exactement ce qui va être créé avant que ce ne soit créé.

Les équipes peuvent plus facilement voir dès les premiers sprints combien de travail ils peuvent réaliser et ainsi il y a une plus grande honnêteté dans ce qu’ils promettent de livrer dans les sprints ultérieurs.

Honnêteté d’implication du business

Les propriétaires de produit (aussi connu comme des Ambassadeurs du Business) peuvent clairement voir ce que l’équipe prévoir de livrer. Cela rend plus facile pour eux de partager leurs propres idées sur les besoins devant être inclus et se projeter sur comment ils peuvent s’impliquer dans le design, le développement et les tests de chaque composant.

Cette honnêteté s’étend aussi au déploiement ou le travail de management des changements que le business devra réaliser pour se préparer à travailler de la nouvelle façon. Les pièces spécifiques de travail sont plus faciles à comprendre que les plus grands regroupements d’exigences. Il y a ainsi une meilleure compréhension de quels changements doivent être apportés “au travail comme d’habitude” (Busines as usual) pour adopter les livrables que l’équipe développe.

Melanie Franklin
Melanie Franklin (Co-Chair of the Change Management Institute UK Chapter)

Comme vous pouvez le constater, je suis fan d’utiliser Agile pour diriger une large variété d’initiatives et j’aide beaucoup d’organisations à développer leur transformation Agile.

Mélanie a dédié la dernière vingtaine d’années à aider ds organisations de toutes sortes à construire leur capacité de changement et d’adaptation.

CertYou est partenaire de DantotsuPM

les « burndown Charts » et Agile: Quoi et pour quoi faire ?

Le Scrum Trainer professionnel Ralph Jocham décrit les Burndown Charts et se concentre sur le travail dans un sprint puis dans une release.

Ralph explique comment et pourquoi ils sont utilisés et fournit des conseils sur les moyens de les exploiter au sein de vos équipes.

Voici aussi comment les Burndown Charts peuvent être utilisés dans la planification et les prévisions des releases.

CertYou est partenaire de DantotsuPM

Le guide de référence pour vos projets #Agile : « Choose Your WoW! » du PMI®

Livre – Choose Your WoW! Du PMI®

Livre sur Amazon

Ce manuel est un guide indispensable pour que les coachs et les agilistes puissent identifier les techniques (pratiques, stratégies et cycle de vie) les plus efficaces en fonction de leur situation et moins efficaces dans d’autres contextes. Ce recueil de conseils se base sur l’expérience de centaines d’organisations confrontées à des situations souvent similaires aux vôtres.

Il y a des centaines de livres qui ont été écrits sur #Agile et #Lean. Alors pourquoi un de plus?

La plupart de ces livres se concentrent sur un sous-ensemble de tout ce qui est nécessaire pour développer et délivrer de bout en bout des solutions d’une manière Agile. Il s’avère difficile d’élaborer une approche cohérente en croisant ou juxtaposant ces pratiques. De plus, il arrive que les conseils de certains de ces livres soient contradictoires et parfois peu documentés. Ils sont souvent fondés sur l’expérience et la réalité mais seulement à partir de quelques réussites et dans un contexte bien particulier probablement différent du votre.

Ce livre de 450 pages est téléchargeable gratuitement pour tous les membres du Project Management Institute®. Il est également possible d’acquérir une version papier sur Amazon.

“PMI,” the PMI logo and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Management proactif des dépendances avec les approches agiles

La planification est une activité récurrente dans les approches adaptatives et les dépendances entre User Stories doivent y être identifiées.

Proactive dependency management with agile approaches

https://kbondale.wordpress.com/2019/04/07/proactive-dependency-management-with-agile-approaches/ par Kiron Bondale

Quand nous manageons des projets en une approche de livraison prédictive, l’identification des dépendances et leur suivi est fait lors de la grande planification amont en utilisant les activités après décomposition des tâches et la sagesse collective des membres de notre équipe et des principales parties prenantes. Si un changement majeur d’approche ou de portée de solution est identifié, on considère les impacts et nouvelles dépendances lors de l’analyse de la demande de changement.

Matchware est partenaire de DantotsuPM
scrum methodologie agile
Voici le diagramme du Modèle Scrum

Mais sur ces projets qui suivent un cycle de vie adaptatif, cela devient un peu plus compliqué. Étant donné la nature émergente des exigences et du design, nous sommes seulement capables de voir les dépendances dans la lumière « des phares » de notre équipe et ceux-ci pourraient seulement nous montrer les deux semaines à venir de travail. Une équipe pourrait avoir considéré “Toutes les dépendances ont-elles été identifiées et capturées ?” dans sa définition de Ready (prêt) mais cela ne signifie pas toujours qu’il est possible de satisfaire cette dépendance dans les temps.

CertYou est partenaire de DantotsuPM

Nous nous efforçons toujours de construire une équipe qui possède toutes les compétences et l’autorité nécessaire pour délivrer la pleine portée du produit ou du projet.

Mais parfois, nous avons besoin d’un expert du sujet pour un petit sous-ensemble des fonctionnalités du livrable et si nous n’identifions pas ce besoin assez tôt, nous ne serons pas capables de livrer ces fonctions au bon moment. De plus, construire une équipe complète dans de grandes organisations est souvent difficile car il y a des équipes en place avec lesquelles travailler pour construire et livrer des fonctionnalités spécifiques, mais elles ne seront pas nécessairement disponibles à la demande.

Une façon de réduire les risques associés aux dépendances qui seraient identifiées trop tard est une combinaison de revue des User Stories avec une planification avancée.

La revue des User Stories fournit une occasion de rassembler les partenaires clés de livraison et de contrôle pour considérer les histoires à un haut niveau avec le Product Owner et l’équipe de développement. Cette revue donne aux partenaires externes une chance d’indiquer quelles histoires les intéressent et aidera l’équipe à savoir avec qui elle doit se synchroniser pour compléter l’une de ces histoires. En fonction de combien ces histoires remontent dans la Story Map, ils comprendront comment elles pourraient devoir être engagées. Les membres de l’équipe peuvent aussi commencer à identifier et capturer les interdépendances entre plusieurs histoires individuelles pour aider le Product Owner dans la priorisation du Product Backlog.

Comme les histoires avec des dépendances commencent à remonter dans le product backlog priorisé, l’équipe peut activement entrer en contact avec les partenaires externes pour demander leur participation un sprint ou deux à l’avance.

La planification est une activité récurrente dans les approches adaptatives car sans cela, un partenaire externe dont votre équipe a besoin va probablement répondre par le vieux cliché : “un manque de planification de votre part ne constitue pas un cas d’urgence de ma part.

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.

PMI® dévoile la roadmap de certifications Disciplined Agile

Les niveaux de certification Disciplined Agile reflète l’adoption de la philosophie Shuhari

Les noms actuels des certifications Disciplined Agile

  1. Disciplined Agilist (DA)
  2. Certified Disciplined Agilist (CDA)
  3. Certified Disciplined Agile Practitioner (CDAP)
  4. Disciplined Agile Lean Scrum Master (DALSM)
  5. Certified Disciplined Agile Coach (CDAC)
  6. Certified Disciplined Agile Instructor (CDAI)

Voici comment elles s’enchainent logiquement en une roadmap Agile

Bien sûr, nous ne chercherons pas forcément à atteindre des rôles de coach ou instructeur, mais il est je pense utile de comprendre le cheminement (voir ce billet Octo sur le Shu-Ha-Ri)

Toutes les certifications, hormis la première (DA), font l’objet de tests avec des prérequis clairement établis.

Le PMI® met régulièrement à jour ces pages :

Ainsi que de nombreuses ressources gratuites sur Disciplined Agile – A Solid Foundation for Business Agility 

et le livre Choose your Wow est également téléchargeable gratuitement au format PDF pour les membres du PMI.

Où trouver des formations ? https://disciplinedagileconsortium.org/disciplined-agile-training

PMI is a registered mark of Project Management Institute, Inc.

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.

 

Agile SAFe peut-il s’interfacer avec « Waterfall » ?

Le manque de transparence cause des malentendus et des conflits. Générer de la transparence demandes des efforts spécifiques.

Can Agile (SAFe) Be Interfaced With Waterfall? – Transparency

https://tcagley.wordpress.com/2019/01/24/interfacing-agile-safe-be-interfaced-with-waterfall-transparency/ par Thomas Cagley

Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).

Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets

Le manque de transparence cause des malentendus et des conflits.

Cependant, générer de la transparence a un coût.

Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.

Plusieurs des techniques les plus communes pour générer de la transparence

#1 – Le Contrat

Spécifiez ce qui peut et doit être partagé dans le contrat.  Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre.  Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu).  Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.

#2 – Un Plan construit conjointement

Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres.  La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur  des risques et communiquer les dépendances en temps réel.

Matchware est partenaire de DantotsuPM

#3 – Des Cérémonies communes

Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies).  Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives.  Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.

#4 – Des Ateliers de mûrissement des exigences et de design

travail d'équipeCollecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.

#5 – Des Modèles de design

L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.

Facile ET difficile à la fois

une plus grande transparence comme base de relations et de travail

Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.

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.